// E: Siehe Beitrag 5

Nagut, ich denke ich muss das etwas detailierter erklären. Zurzeit habe ich schon einen gewissen Aufbau geplant, aber dieser ist bei weitem nicht perfekt, aber wäre lauffähig.
Bisher habe ich ja auch erst Frameworks genutzt, aktiv dann auch nur Codeigniter. Ein Framework selbstgeschrieben habe ich auch noch nie, also habe ich ne Menge Fragen wie ich es am besten machen könnte.
Ein Framework schreiben ist ja nicht schwer, ein gutes Framework zu schreiben dagegen sehr

Also zu meinem bisherigen Planungsstand:

Ordnerstruktur

system | Dateien des Frameworks, sollten vom Entwickler nie verändert werden
- libraries | Die nativen Bibliotheken, z.B File-Library, Cache-Library, Log-Library, Database-Library etc
- exceptions | Die nativen Exceptions des Frameworks, wie alles andere im system-Ordner auch sollten diese weder verändert noch gelöscht werden
- core | Die Core-Dateien des Frameworks. Klassen und andere Dateien die für den Betrieb unbedingt nötig sind, aber auf keinen Fall erweitert, verändert, gelöscht, oder von Hand aufgerufen werden sollen. Deshalb passen sie auch nicht zu den Libraries
- cache | Der Cache-Ordner des Frameworks. Ist nur im System-Ordner da ich noch keinen besseren Platz gefunden habe...
- logs | Der Logs-Ordner, gleiches Problem wie bei Cache
- database | Hier stecken die Datenbank-Treiber für z.B mysqli, mysql, etc drin
app | Hier kommen alle Dateien der Anwendung hinein
- controllers | Controller-Ordner eben. Die Controller können in Unterordner sortiert werden
- libraries | Die eigenen Bibliotheken. Durch ein kleines System soll es so ganz einfach möglich sein eigene Libraries zu schreiben, und die nativen bestehenden zu erweitern ohne deren Dateien oder Klassen im system-Ordner ändern zu müssen
- views | Die Views der Anwendung, Unterteilung in Unterordner soll auch hier möglich sein
- resources | Hier kommen die Resourcen der Anwendung hinein, wie z.B...
-- stylesheets | ...Stylesheets
-- images | ...Bilder
-- javascripts | ...Javascripts
- config | Hier lagern alle Konfigurationsdateien. Jede Library hat ihre eigene Konfigurationsdatei, mehr soll es nicht geben
- exceptions | Die Exceptions der Anwendung. Sie können die nativen Exceptions genauso wie es bei den Libraries möglich ist erweitern
- models | Die Models. Unterteilung in ordner soll möglich sein...

Klassen

Zurzeit sieht der Klassenaufbau so aus, aber dieser muss denke ich komplett überarbeitet werden, da aber noch nichts vom Framework geschrieben ist sollte das ja kein Problem sein:

Base | Singleton-Funktionen // Muss unbedingt geändert werden!
- Die Klassen des "Kerns" des Frameworks
- Core | Implementierung von Overloading (Magic setter & getter)
-- Library | Basis-Klasse aller Libraries
--- Log-Library
--- Cache-Library
--- etc.
-- Controller | Basisklasse aller Controller
--- Welcome-Controller
--- etc.
-- Model | Basisklasse aller Models
--- User-Model
--- etc.
Exception | Basis-Klasse aller Exceptions // Wird nicht vom Framework deklariert, sondern ist ja bei PHP schon "dabei"
- WasAuchImmerException

Hoffe ich habe da nichts vergessen...
Zurzeit ist alles ausser Exceptions Singleton. Nur: Braucht man da mehr? Controllers, Models, etc muss ja alles nicht mehrfach instanziert werden. Bei den Libraries könnte man darüber streiten, aber schliesslich fungieren auch diese nur als eine Art Kategorie für Funktionen die miteinander arbeiten.

Restliches

Nun zu meinen Fragen/Problemen/weiteren Erläuterungen:
Die index.php legt einige Konstanten fest und ruft dann die system/core/init.php auf, welche alles initialisiert. Die Core-Klassen werden da geladen (Loader, Pinboard, Categories) und mit dem Loader dann die anfags erforderlichen Libraries (URL, Router, Request, File, Cache, Log etc).
In meinem Framework wird eine Library oder ein Model geladen sobald es benötigt wird. Das ist jetzt recht kompliziert zu erklären:
Alle Objekte der Libraries etc die die Loader-Klasse erzeugt, werden auf dem sogenannten Pinboard abgelegt. Dieses ist wiederum in Kategorien (eigentlich Objekte der Klasse Category, eine Klasse für "leere" Objekte bzw um eben DInge darauf abzulegen) eingeteilt.
Es gibt als Kategorien libraries, models, controllers, views (Jede View bekommt ein eigenes Objekt über welches man Daten zur View hinzufügen kann). So werden die Objekte der Libraries etc also nicht direkt auf dem Pinboard abgelegt sondern in einem Category-Objekt vonwelchem ein Objekt in einer Instanzvariable der Pinboard-Klasse abgelegt ist. Die Category-Klasse stellt nun eben magische setter und getter zur Verfügung welche eine Klasse automatisch von der Loader-Klasse laden lassen, wenn von dieser Klasse noch kein Objekt existiert.
Nagut: Weil die Pinboard-Klasse singleton wie eigentlich jede Klasse im Framework ist, kann man einfach von überall auf alle geladenen Libraries etc zugreifen. Durch eine kleine "Umleitung" über magische setter und getter in der Core-Klasse, welchen ja allen Basis-Klassen von Libraries etc. zu Grunde liegt , wird die Instanzvariable mit dem Objekt des Pinboards umgangen: Angenommen wir sind jetzt in einem Controller oder eine anderen Klasse welche mit der Core-Klasse verwandt ist, können wir auf eine Library oder ähnlich so zugreifen: $this->libraries->cache->write(); statt, ohne Umleitung, $this->ff_pinboard->libraries->cache->write();

Das war gerade warscheinlich zu kompliziert und ihr habt mindestens 90% nicht verstanden denke ich, aber fragt einfach wenn ihr Fragen habt

Wenn ihrs verstanden habt: Was kann man besser machen? (man kann garantiert viel besser machen...)
Soll die Loader-Klasse eine Library sein? Da ich ja auch Haupt-Klassen für jede Klassen-Art (Controller, Libraries, Models...) anbieten will die der Entwickler bearbeiten kann: Soll ich einfach in den jeweils entsprechenden Ordner eine z.B main.library.php tun, von deren beinhaltenden Klasse dann alle Libraries abstammen? Wäre meiner Meinung nach die beste Lösung...

greez

bitsnack

Nein.
Das Pinboard ist einfach ein Objekt in dem 4 weitere Objekte der Klasse Category lagern. In diesen Category-Objekten werden dann die Objekte der geladenen Libraries oder für welche Kategorie von Klasse das Category-Objekt auch zuständig ist.
Falls ein Objekt vom Category-Objekt angefordert wird welches nicht existiert wird die Loader-Klasse bemüht um die Klasse zu laden.
Das Pinboard ist dann wieder als Instanz-Variable in jeder Library, in jedem Model und Controller (wird von der Basisklasse diese beim instanzieren erstellt). Das Pinboard ist deshalb auch Singleton, da ja immer das gleiche Objekt vom Pinboard in den Klassen sein soll.
PS: Das ganze ist also eher Lazy-Loading...

Hmm, keiner eine Idee?
Wie würdet ihr denn ein PHP5-MVC-Framework mit Lazy-Loading und erweiterbaren System-Libraries aufbauen?

Aber wie kann ich sonst Kategorien machen? Also dass eine Bibliothek (nur) so aufrufbar ist: $this->libraries->foo->bar();
Ich kann ja nicht einfach für jede Kategorie das Pinboard/Dashboard/wie mans auch nennen will laden. Dann wärs ja kein Singleton mehr.
Klar wäre es möglich zu schauen ob die Kategorie schon existiert und diese bei bedarf zu laden. Aber eine Library soll man auch eine art bookmarken können, damit sie direkt über $this->foo->bar(); zugänglich ist.
Zwischen $this-> und foo->... ist ja theoretisch noch die Instanzvariable mit dem Objekt des Pinboards, aber diese wird mit _get und _set übergangen.
$this->var leitet also immer auf das Pinboard weiter.

Die wichtigste Frage für mich ist bisher einfach welche Klassen ich als Library laufen lasse und welche nicht.

Eine Frage am Rande hab ich dann noch: Models.
Welche Variante ist besser:

$usermodel->createUser($username, $password, $email, ...);
$usermodel->deleteUser($username);

oder

$user = new User($username, $password, $email);
$user->save();
$user = new User($username);
$user->delete();

Was ist in einem Framework besser? Welches ist verbreiteter und wie kann man das verbessern?

In CodeIgniter ist ein Model auch Singleton und wird auch mit $this->user_model->createUser(); verwendet. Denke ich werde das bei meinem Framework auch machen.
Klar könnte man ein Objekt pro Benutzer erstellen, aber ich denke da könnte man den Überblick über die Objekte verlieren.

Zum Dashboard: Es soll als Zentrale Ablage für Objekte dienen. Und zu den Categories: Diese sollen eben als Kategorien für die Objekte dienen. Anders kann man genau das ja nicht realisieren!?

Der Loader (die Factory) wird also zu den Libraries gehen, Das Pinboard und Categories nicht. Evtl finde ich eine Möglichkeit Kategorien auch ohne eine extra Klasse so zu erzeugen, dass sie auch andere Methoden als das Pinboard haben.

Model, Library und Controller werden Abstrakte Klassen sein, welche sich im jeweiligen Ordner in app/ befinden.
So kann man Sie leicht erweitern und ich benötige da kein weiteres System.
In den Klassen steht ja ohnehin nichts, ausser man passt sie eben an.

Damit wäre das Thema eigentlich geklärt, ausser ihr hättet noch Tipps welche ich beachten sollte oder irgendwelche Design Patterns welche ich verwenden/unterbringen könnte.

Vielen Dank schonmal!