Plan für Jlog 2.0 ================= Unabhängigkeit von einer MySQL Datenbank ---------------------------------------- Es sollen verschiedene Datenbanksysteme durch eine Datenbank Abstraktion unterstützt werden. Für jede DB soll es eine Datei geben, die die Kommunikation zwischen DB und Jlog übernimmt. Darüber hinaus sollen nicht nur Datenbanken, sondern auch Flatfiles und XML-Files unterstützt werden. Das wird wohl daraus hinauslaufen, dass man die DB Abstraktionsebene noch einmal abstrachieren muss und für die einzelnen Bereiche auch extra wieder konkrete implementierungen macht. Beim normalen Download wird die MySQL Datei mitgeschickt und jeder der eine andere Speichermöglichkeit wählt wird diese Datei durch die dazugehörige überschreiben können. Ich könnte mir die Umsetzung so vorstellen wie es jetzt schon bei den Jlog Plugins implementiert ist. Man macht eine Vaterklasse die für alle verschiedenen Kommunikationsmöglichkeiten einzelne Methoden zur Verfügung stellt davon werden dann die einzelnen Kindsklassen, für jede Speichermethode (XML, MySQL, Flatfile, SQLite, etc.) von der Vaterklasse abgeleitet. Das schwierigste für mich ist aber die Methoden so allgemein zu halten, dass auch Pluginentwickler diese sinnvoll nutzen können und sich dann nicht unnötigerweise auf nur ein System beschränken, da sie eine andere Funktionalität beim Lesen und speichern benötigen. Da bräuchte ich noch ein paar Vorschläge wie man das sinvoll umsetzt. Globale Blog-Informationen -------------------------- Bisher werden alle Informationen über das jeweilige Blog in der Datei /personal/settings.inc.php als Konstanten definiert. Konstanten haben sich aber als sehr unhandlich erwiesen, da man sie vor allem wärend der Laufzeit nicht ändern kann, was schon einige Probleme bereitet hat. Außerdem kann man sie nicht schön gruppieren und schon gar nicht Infos von Plugins so speichern. Viel besser wäre daher hier auch unabhängig zu werden. Es gibt hier genau so wie beim allgemeinen speichern der Daten weiter oben beschrieben mehrere möglichkeiten, also XML-Datei, Flatfile, eine PHP Datei mit einem Array (wird wohl auch das schnellste sein, da man das bei jedem Aufruf einer Seite alles braucht) oder sogar in der Datenbank. Ich tendiere hier zur PHP Datei mit Array, möchte aber das ganze dennoch davon unabhängig machen und lieber methoden zum ändern und auslesen der Informationen. Alle Informationen sollen in einem global erreichbaren Objekt verfügbar sein, genau so wie die Methoden zum ändern und auslesen derer. Plugin Behandlung ----------------- Bisher ist die Pluginschnittstelle noch ziemlich unkontroliert. In Zukunft möchte ich das ganze besser strukturieren und mehr Angrifspunkte bieten. Aber auch die Verwaltung der Plugins muss besser werden, es muss zum Beispiel die Möglichkeit geben über ein Webinterface Plugins ein- und auszuschalten, Informationen über das Plugin einzublenden wie Version, Autor, Beschreibung, etc. Die Art und Weise, wie Plugins Code die XHTML-Ausgabe erweitern, ist IMHO deutlich verbesserungswürdig: Anstatt den kompletten Code durchzuschleifen und das abschließende div oder form durch den eigenen Code zu ersetzen, wäre ein richtiger "Einhängpunkt" sehr von Vorteil. Weitere Überlegungen gibt es von mir und Dennis auf und auf sowie Smarty als Templatesystem ------------------------- Ich habe mich bisher noch nie wirklich mit Smarty befasst, es scheint mir aber ein gutes System zu sein. Es gab mittlerweile schon mindestens fünf Anfragen ob Jlog damit zusammenarbeiten kann, bzw. können wird. Zu anderen Templatesystemen gab es gar keine Anfragen. Der große Vorteil dabei ist, dass sich schon sehr viele Entwickler mit dieser Templateengine gut auskennen und schnell eigene Templates damit erstellen können. Das bisherige Konzept von Jlog mit ist zwar einfacher, aber dafür absolut unflexibel. Es sollen komplett alle HTML ausgaben an Smarty übergeben werden, auch die aus dem Admincenter. Dabei soll das ganze aber so funktionieren wie bisher, dass das Admincenter auf jeden Fall im Design der Seite erscheint und nicht wie bei vielen anderen Systemen mit einem völlig eigenen Design daherkommt. File- bzw. Mediaupload ---------------------- Außer Bilder sollen auch andere Dateien hochgeladen werden können. Dabei ist zu überlegen, ob man einen allgemeinen Media-Uploader baut, oder das mit den Bilern so belässt wie bisher und noch einen anderen Uploader für andere Dateien wie PDF, Word Dokumente, Flashfilme, mp3s usw. einbaut. BBCode Alternativen ------------------- Nicht jeder ist so begeistert vom BBCode wie ich, deshalb würde ich zwar als defaulteinstellung weiterhin Christian Seilers BBCode Klasse zum Parsen von Texteingaben behalten, aber auch die Möglichkeit geben andere Sachen wie reines HTML, einen RichText Editor, restructured Text, etc.