root/branches/Plan_fuer_Jlog_2.0.txt

Revision 1696, 5.0 kB (checked in by driehle, 9 months ago)

cleanup

Line 
1 Plan fÃŒr Jlog 2.0
2 =================
3
4
5 UnabhÀngigkeit von einer MySQL Datenbank
6 ----------------------------------------
7
8 Es sollen verschiedene Datenbanksysteme durch eine Datenbank Abstraktion unterstÃŒtzt
9 werden. FÃŒr jede DB soll es eine Datei geben, die die Kommunikation zwischen DB
10 und Jlog ÃŒbernimmt.
11
12 DarÃŒber hinaus sollen nicht nur Datenbanken, sondern auch Flatfiles und XML-Files
13 unterstÃŒtzt werden. Das wird wohl daraus hinauslaufen, dass man die DB Abstraktionsebene
14 noch einmal abstrachieren muss und fÃŒr die einzelnen Bereiche auch extra wieder
15 konkrete implementierungen macht.
16
17 Beim normalen Download wird die MySQL Datei mitgeschickt und jeder der eine andere
18 Speichermöglichkeit wÀhlt wird diese Datei durch die dazugehörige Ìberschreiben können.
19
20 Ich könnte mir die Umsetzung so vorstellen wie es jetzt schon bei den Jlog Plugins implementiert
21 ist. Man macht eine Vaterklasse die fÌr alle verschiedenen Kommunikationsmöglichkeiten
22 einzelne Methoden zur VerfÃŒgung stellt davon werden dann die einzelnen Kindsklassen,
23 fÃŒr jede Speichermethode (XML, MySQL, Flatfile, SQLite, etc.) von der Vaterklasse
24 abgeleitet.
25
26 Das schwierigste fÃŒr mich ist aber die Methoden so allgemein zu halten, dass auch
27 Pluginentwickler diese sinnvoll nutzen können und sich dann nicht unnötigerweise auf
28 nur ein System beschrÀnken, da sie eine andere FunktionalitÀt beim Lesen und speichern
29 benötigen. Da brÀuchte ich noch ein paar VorschlÀge wie man das sinvoll umsetzt.
30
31
32 Globale Blog-Informationen
33 --------------------------
34
35 Bisher werden alle Informationen ÃŒber das jeweilige Blog in der Datei /personal/settings.inc.php
36 als Konstanten definiert. Konstanten haben sich aber als sehr unhandlich erwiesen,
37 da man sie vor allem wÀrend der Laufzeit nicht Àndern kann, was schon einige Probleme
38 bereitet hat. Außerdem kann man sie nicht schön gruppieren und schon gar nicht Infos
39 von Plugins so speichern.
40
41 Viel besser wÀre daher hier auch unabhÀngig zu werden. Es gibt hier genau so wie beim
42 allgemeinen speichern der Daten weiter oben beschrieben mehrere möglichkeiten, also
43 XML-Datei, Flatfile, eine PHP Datei mit einem Array (wird wohl auch das schnellste sein,
44 da man das bei jedem Aufruf einer Seite alles braucht) oder sogar in der Datenbank.
45
46 Ich tendiere hier zur PHP Datei mit Array, möchte aber das ganze dennoch davon unabhÀngig
47 machen und lieber methoden zum Àndern und auslesen der Informationen. Alle Informationen
48 sollen in einem global erreichbaren Objekt verfÃŒgbar sein, genau so wie die Methoden
49 zum Àndern und auslesen derer.
50
51
52 Plugin Behandlung
53 -----------------
54
55 Bisher ist die Pluginschnittstelle noch ziemlich unkontroliert. In Zukunft möchte
56 ich das ganze besser strukturieren und mehr Angrifspunkte bieten. Aber auch die Verwaltung
57 der Plugins muss besser werden, es muss zum Beispiel die Möglichkeit geben Ìber ein
58 Webinterface Plugins ein- und auszuschalten, Informationen ÃŒber das Plugin einzublenden
59 wie Version, Autor, Beschreibung, etc.
60
61 Die Art und Weise, wie Plugins Code die XHTML-Ausgabe erweitern, ist IMHO deutlich verbesserungswÃŒrdig:
62 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.
63
64 Weitere Überlegungen gibt es von mir und Dennis auf
65 <http://jeenaparadies.net/webdesign/jlog/demo/2005/12/problem2#c61> und auf
66 <http://jeenaparadies.net/bugs/task/111> sowie <http://jeenaparadies.net/bugs/task/114>
67
68
69 Smarty als Templatesystem
70 -------------------------
71
72 Ich habe mich bisher noch nie wirklich mit Smarty befasst, es scheint mir aber ein gutes
73 System zu sein. Es gab mittlerweile schon mindestens fÃŒnf Anfragen ob Jlog damit
74 zusammenarbeiten kann, bzw. können wird. Zu anderen Templatesystemen gab es gar keine
75 Anfragen.
76
77 Der große Vorteil dabei ist, dass sich schon sehr viele Entwickler mit dieser Templateengine
78 gut auskennen und schnell eigene Templates damit erstellen können.
79
80 Das bisherige Konzept von Jlog mit <jlog:variablenname /> ist zwar einfacher, aber dafÃŒr
81 absolut unflexibel. Es sollen komplett alle HTML ausgaben an Smarty ÃŒbergeben werden,
82 auch die aus dem Admincenter. Dabei soll das ganze aber so funktionieren wie bisher,
83 dass das Admincenter auf jeden Fall im Design der Seite erscheint und nicht wie bei vielen
84 anderen Systemen mit einem völlig eigenen Design daherkommt.
85
86
87 File- bzw. Mediaupload
88 ----------------------
89
90 Außer Bilder sollen auch andere Dateien hochgeladen werden können. Dabei ist zu ÃŒberlegen,
91 ob man einen allgemeinen Media-Uploader baut, oder das mit den Bilern so belÀsst wie
92 bisher und noch einen anderen Uploader fÃŒr andere Dateien wie PDF, Word Dokumente, Flashfilme,
93 mp3s usw. einbaut.
94
95
96 BBCode Alternativen
97 -------------------
98
99 Nicht jeder ist so begeistert vom BBCode wie ich, deshalb wÃŒrde ich zwar als defaulteinstellung
100 weiterhin Christian Seilers BBCode Klasse zum Parsen von Texteingaben behalten, aber auch
101 die Möglichkeit geben andere Sachen wie reines HTML, einen RichText Editor, restructured Text, etc.
Note: See TracBrowser for help on using the browser.