Notizen zu Duplex von apollo13
- Templateengine: An wenn ist sie gerichtet? Wahrscheinlich an einen Designer, aber kann man von ihm erwarten PHP zu können? Nein, bzw. sollte man nicht müssen, hier bietet sich eine Templatesprache wie von Django an: http://www.djangoproject.com/documentation/templates/ (Einfach und flexibel :)). Leider gehen dadurch die Vorteile eines Templatesystems, das PHP verwendet, verloren, siehe: http://www.sitepoint.com/print/beyond-template-engine Hier muss nun überlegt werden, an wen das System gerichtet ist...
- i18n: Am angenehmsten wäre hier gettext, ich weiß allerdings nicht wie es mit PHP Unterstüzung aussieht, aber sicher etwas was schon von Anfang an feststehen muss!
- Pluginarchitektur: Wie das ist hier die Frage
- Dokumentation: Alles dokumentieren ;)
- Coding Style: Auch etwas, worauf man sich von Anfang an einigen sollte...
- Datenbankbackend: Unterstüzung für mehrere Datenbanken (Mysql, Sqlite etc...)?
Weitere Ideen ruhig reinschreiben, vielleicht wird ja was daraus :)
Notizen von black_caeser und lupus
- Templateengine: bekommt vom System die Inhalte der einzelnen Plugins in XML übermittelt (Inhalte in Rohformat, ohne jegliche Formatierung, _kein_ HTML erlaubt), liest aus Templatedateien Formatierungsbefehle und formatiert die Elemente entsprechend. Vorteile: kein PHP in Templatedateien nötig, komplette Formatierung per Template möglich. Nachteil: größere Mengen Templatedateien. Verfügt ein Template über keine Formatierungsanweisung zu bestimmten Element wird Fallback-Template des Systems genutzt. (So wie dieses hübsche Win95-Fensterdesign z.b. unter XP :D)
> apollo13: Wie schaut es mit Templatesyntax aus?
> lupus: Das überlege ich mir gerade. Es wird vom System aus natürlich einen gewissen Stamm an Elementen geben, z.b. <menu target=irgendwas title=Titel><submenu ...>...</submenu></menu> und als Templatedateien dann entsprechend menu und submenu vom Stil: <div ...><a href={target}>{title}</a>{elements}</div> etc.
> apollo13:*Jedihandbewegung* du willst <ul> und <li><a> verwenden anstatt divs :)...
> lupus:omg. das ist Sache des Designers, wie er sein Menü gestaltet. nicht meine. Ergo ist es mir ziemlich Jacke, ob da nun divs oder uls rumlungern.
> apollo13: Gut war nen kleines Missverständnis, ich dachte die Templateklasse macht aus menu nen div etc Baum, so ist es natürlich besser :)
> lupus: Kann sie ja machen ;) Nur tut sie es nach Anweisung der Templatedatei, also nach Anweisung des Designers. Die Engine an sich ist dumm :D sie packt nur den Inhalt in die bereitgestellten Templatedateien und gibt am Schluss die Seite aus. In der ganzen Engine wird hoffentlich nicht eine html-klammer vorkommen :D
- Datenbankbackend: Initialisierung der Datenbank-Verbindung wird durch Backend vorgenommen, nicht durch Hauptsystem, Anfragen an Backend via mysql-query, in Backend Interpretation, wahlweise Rückgabe der Daten Zeilenweise oder in Array aus Bank oder Zwischenspeicher (für häufig benötigte, selten geänderte Dateien), Wahl der Speichermethode (MySQL, PostgreSQL, Textdateien) bleibt Backend überlassen)
> apollo13: auf Textdateien verzichten, und eine Datenbankklasse bauen, die in Richtung {$type}_connect etc. arbeitet. Beispiele gibt es genug :)
> lupus: Naja. Das ist ja der Verbindungsklasse überlassen, wie sie was speichert, und der restlichen Programmierung ziemlich egal :) Hauptsache ist, dass auf einem Query die richtigen Daten kommen.
> apollo13: Nicht ganz, du willst sicher nicht eine Klasse schreiben die ein SQL-Select extra für Textdateien aufbereitet... Oder kommt ein ORM zum Einsatz (sprich gar kein raw sql mehr schreiben?)
> lupus: um die Verbindungsklasse kümmert sich black_caeser z.zt. Ist ja imho auch ziemlich egal, ob nun txt unterstützt wird oder nicht. Es wird ja ohnehin hauptsächlich auf mysql laufen und fertig. Also ist die einzige Aufgabe z.zt., ein db-prefix einzubauen und evtl. Daten zwischenzuspeichern. Alles andere ist ja später optional.
> apollo13: Achja: Es sollte eine Basisklasse geben, die die Funktionen allgemein definiert und dann für jede Datenbank eine neue Klasse die von der ersten erbt und die Funktionen überschreibt (jeweils in eigenen Datein)...
> lupus: Egal, da erstmal eh nur MySQL unterstützt wird.
- Pluginarchitektur: Plugins werden von System automatisch erkannt, eingebunden, auf Befehl installiert. Möglichkeit bei Installation: eigene Formatierungsbefehle dem Fallback-Template hinzuzufügen.
- i18n: Speicherung der verschiedenen Texte zentral, damit einheitliche Übersetzung möglich ist, für jedes Plugin ist intern Standardsprache (Fallback-Sprache) definiert, für die auf jeden Fall eine Datei vorhanden ist.
Notizen von js
- Vielleicht sollte man mal ne Richtlinie entwickeln, inwieweit z.B. Symbole verwendet werden sollen. Beim Menü habe ich jetzt z.B. ziemlich viele....
