source: branches/Plan_fuer_Jlog_2.0.txt @ 1696

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
<http://jeenaparadies.net/webdesign/jlog/demo/2005/12/problem2#c61> und auf
<http://jeenaparadies.net/bugs/task/111> sowie <http://jeenaparadies.net/bugs/task/114>


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 <jlog:variablenname /> 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.