Templates: DB/Files, +/-, ...

[mahe]

Wie machen wir das nun mit den TPLs?
Ich bin noch immer dafür die in die DB zu packen.
Nicht nur weil man sie einfacher editieren, updaten usw. kann.
Man kann dann TPLs die (fast) immer gebraucht werden mit einem Schlag (Query) aus der DB holen.
Und ein Query ist schneller als x-Files einzulesen.
Des weiteren finde ich sollten die TPLs \"komplett\" sein.
Sprich nicht nur zB eine Tabellenzeile enthalten oder gar nur einen img-Tag.
Ich parse lieber ein bereits geparstes TPL in ein nächstes anstatt die Seite einzeln zusammezustückeln.
Dadurch könnte man die TPLs noch unterteilen in \"Daten-TPLs\" und \"Struktur-TPLs\".
In die \"Daten-TPLs\" werden Posts, Panels oder was auch immer reingeparst, die bilden sozusagen jeweils einen Block für sich.
In die \"Struktur-TPLs\" werden dann die bereits geparsten \"Daten-TPLs\" einfach reingeparst.
So bleibt zum Schluss eigentlich nur ein Block übrig (der ganze Inhalt) welchen man dann einfach ausgeben kann (zB zwischen header.php und footer.php),
oder diesen einfach nochmal in das TPL der gesamten Seite parst.
Ich denke mir so wäre der ganze Seitenaufbau sehr flexibel zu gestalten, da der Anwender in den \"Struktur-TPLs\" selbst bestimmen kann wo welcher Inhalt (Block) angezeigt wird.
Und wie dieser Block aussieht kann er im \"Daten-TPL\" bestimmen.
Ich hoffe ich habe verständlich rübergebracht was ich meine, ansonsten versuch ich es anhand eines simplen Codebeispiels zu erklären /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />
 - Editiert von mahe am 22.10.2005, 11:44 -

[Powie]

dafür!

Hallo,
für das Einspeichern in eine Datenbank wäre ich nicht. Es würde die Datenbank nur unnötig belasten. Wie ich es schon angesprochen habe (aber ohne Feedback bis jetzt) würde ich gerne eine Templatevariante im Stil von Mambo/Joomla! einsetzen.
Ich gehe jetzt mal davon aus mahe, du meinst die .tpl-Dateien, welche bestimmte Tags (bspw.: {imag=XXX}...) enthalten und welche dann geparst werden. (Ähnlich von Smarty?) Das Problem denke ich mal wird dann sein, das der User dies schwer anpassen kann, da er mit vielen Dateien umgehen muss. Zudem scheint mir dies allgemein etwas sehr unübersichtlich und schwer durch schaubar [ich bitte um eine genauere Erklärung inklusives Codebeispiels /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />. Bitte]

Ich würde es wie folgt angehen:
Man gibt jedem Modul einen eigenen Ordner, wo es Bilder, PHP-Dateien etc. ablegen kann. Dort fügen wir ebenfalls noch einen Templateordner pro Modul hinzu, welcher mehrere Templates enthalten kann. Diese Templates werden per Ordner voneinander abgegrenzt.
Jedes Template hat eine index.php, welche das Zentrum darstellt. Hier kann der User seine eigenen Aufbau gestalten. Wie er möchte; Tabellen, Links etc.
 
Soweit mitgekommen? Ich hoffe /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" /> Also, in die index.php kann man nun aber noch Funktionen einfügen, welche wiederrum bestimmte Dinge auf der Stelle darstellen, wo sie eingefügt wurden.
Ein Beispiel:
 

index.php:
 

 
 
Etwas banal, aber ich hoffe euch zeigen zu können, was ich meine. Durch diesen Funktionsaufruf würd dann an dieser Stelle des Quellcodes dann eine kleine Übersicht über die Leute gegeben, die Online sind. (siehe bspw. im Forum) Das war es schon.
Dadurch kann der User ganz einfach seine Seite modular aufbauen: einfach die Funktionen einfügen, fertig.
Das Problem ist nun, wie man dies nun vernünftig einbinden sollte? Nehmen wir mal an, dass das Modul im Ordner
 

 
.../pDev/Module/MeinModul/templates/MeinTesttemplate

 
 
liegt. Im Ordner \"MeinTesttemplate\" liegt nun die index.php, welche die Funktionen enthält (Show_Who_is_Online).
Möchte man das eigentliche Modul nun einbinden, dann includiert man einfach die index.php des Modulhauptordners.
1

.../pDev/Module/MeinModul 

 
 
Diese index.php des Modulhauptordners macht nichts anderes, als das jeweilige *Standarttemplate* sowie die verfügbaren Funktionen des Moduls zusammenzuführen. Sie selbst includiert einfach die index.php des jeweiligen Standarttemplates in sich selbst per include (...); Zudem includiert sie die Dateien, welche die eigentlichen Funktionen zur Verfügung stellen bzw. die Klassen.
Bei dieser Variante wird nichts geparst oder sonst irgendetwas. Es werden keine tpl-Dateien verwendet.
Nun kommt aber noch etwas wichtiges hinzu, damit das ganze auch gut funktioniert, wenn es in ein bestehendes Portal mit tausenden Seiten und unterschiedlichen Ordnerstrukturen, noch funktioniert.
Man geht weg von einer Mehr-Dateien Variante hin zu einer Ein-Datei Variante. Was diese Begriffe bedeuten sollen? Ganz einfach, derzeitig klickt man sich bspw. im Forum von Datei zu Datei, im wahrsten Sinne des Wortes. Bei der Ein-Datei Variante gibt es nur eine index.php (die aus 1) Die index.php bekommt nun einen Schwung Variablen übergeben, mit dem ihr mitgeteilt wird, was sie zu tun und lassen hat. Diese Variante bedeutet nicht, dass es nun nur noch eine [!] Datei gibt. Es bedeutet nur, dass alles über eine läuft, aber es können weiterhin die Klassen ausgelagert werden oder die CSS außerhalb definiert werden. Was ja auch Sinn macht /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />
Wenn ihr schonmal mit den Templates von Mambo/Joomla! gearbeitet habt, dann kommt euch mein Vorschlag sicher bekannt vor. Ich finde dieses System nämlich sehr einfach und extrem anpassungsfähig. Dabei nicht nur für den Entwickler, sondern auch für den (ahnungslosen) User.

Mein Problem wäre nur noch zu klären, wie man es bei mehreren Modulen realisiert. Wenn man beispielsweise ein Portal aufbauen möchte kommt nun bei dieser Variante das Problem auf einen zu, wo denn nun die zentrale index.php liegt, die alle Modul-index.php \'s includiert.
Ich hoffe auf Feedback /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />
 
kOOni

[mahe]

für das Einspeichern in eine Datenbank wäre ich nicht. Es würde die Datenbank nur unnötig belasten.[/quote] also ich lese lieber 10 Datensätze aus der DB als 10 Files von der HD des Servers.Zumal ich immer prüfen müsste ob es das File gibt und dann erst lesen.
Bei der DB schick ich meine Query hin (1, egal wieviel Datensätze) und seh dann (zB mit empty() oder isset()) obs den Datensatz gibt.
10 einzelne Queries und danach das Ergebnis prüfen geht überigens schneller als prüfen ob es 10 Files gibt und diese dann einzulesen.

Ich gehe jetzt mal davon aus mahe, du meinst die .tpl-Dateien, welche bestimmte Tags (bspw.: {imag=XXX}...) enthalten und welche dann geparst werden.[/quote]nein, genau das ist das was ich nicht will ...zig Dateien und nochmal soviel Verzeichnisse ...
Es gibt für einen Anwender der keine Ahnung von der Materie hat nichts schlimmeres als so einen Haufen.
Um das zu verstehn was ich meine musst du beim gesamten Ergebnis der Scripte anfangen.
Das Ergebnis ist eine Webseite (hier ohne Navi):

blub
 
Inhalte

 
 
Diese setzt sich nun aus mehreren Teilen zusammen:
a) header.php - Inhalte - footer.php
b) das Haupttemplate (also das gesamte Design und Layout der Seite) in welches die bereits zusammengefügten Inhalte geparst werden:
Die Inhalte werden entsprechend dem \"Struktur-TPL\" zu einem Inhalt vereint.
Das TPL kann zB so aussehen:

    
       {$panel_login}
       {$panel_headnews}
 
       {$panel_newthreads}

 
Jedes dieser \"Panels\" hat noch ein eigenens TPL in welches die Daten geparst werden.
Das ganze könnte man (wenn man will) über zig Stufen spielen.
Das einfügen passiert über ein str_replace() und das braucht nicht wirklich Performance /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />
Was mir an deinem Vorschlag nicht gefällt:
PHP-Code im html, auch wenn es nur wenig ist.
zig (Unter-)Verzeichnisse
Des weiteren frage ich mich wie es zB bei Listen aussieht?
Also wenn man zB ein Logfile hat wie das beim pForum, ein einfaches show_logfile() wirds da wohl nicht tun, oder kommen dann die einzelnen Zeilen von der Funktion?

also ich lese lieber 10 Datensätze aus der DB als 10 Files von der HD des Servers.[/quote]
Du hättest bei meiner Version eigentlich nur 3 Dateien. (Standartmäßig gesehen)
> index.php im Modulhauptordner
> index.php im Templateordner (des jeweiligen Standarttemplates)
> css File, welche in die index.php des Templateordners eingefügt wird
[und dann vielleicht noch ein paar Bilder]
So musst du garnicht prüfen, ob irgendwelche Dateien exsistieren, denn sie werden immer da sein, wenn man es richtig installiert hat /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />
Bei deinen Panels reden wir glaub ich vom Gleichen: Du schreibst {$panel_login}, ich hingegen . Das ist im Endeffekt egal /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />

Was mir an deinem Vorschlag nicht gefällt:PHP-Code im html, auch wenn es nur wenig ist.
zig (Unter-)Verzeichnisse
[/quote] Was gefällt dir denn daran nicht? Gibt es da Sicherheitsbedenken oder Performanceprobleme ?
Das mit den Zig-Unterverzeichnissen kann man auch minimieren. Aber mal davon abgesehen, bekommt der User davon ja nichts mit. Denn er braucht nur die index.php des Templates ändern und schon läuft es. (Theoretisch nichts weiter!)

Des weiteren frage ich mich wie es zB bei Listen aussieht?[/quote] Listen ?

Also wenn man zB ein Logfile hat wie das beim pForum, ein einfaches show_logfile() wirds da wohl nicht tun, oder kommen dann die einzelnen Zeilen von der Funktion?[/quote] Wenn ich das jetzt richtig verstehe, ja. Die Ausgabe des HTML bzw. XHTML Codes wird über die Funktionen abgewickelt. Wie man das technisch realisiert ist erstmal Rille. Aber durch eure *Panels* bzw. durch meine *Funktionen* kann der User dies gut einstellen, wie ers braucht.
 
kOOni

[mahe]

Du hättest bei meiner Version eigentlich nur 3 Dateien. (Standartmäßig gesehen)
> index.php im Modulhauptordner
> index.php im Templateordner (des jeweiligen Standarttemplates)
> css File, welche in die index.php des Templateordners eingefügt wird
[und dann vielleicht noch ein paar Bilder]
So musst du garnicht prüfen, ob irgendwelche Dateien exsistieren, denn sie werden immer da sein, wenn man es richtig installiert hat [Zwinkern]
[/quote]Es werden nie nur 3 Dateien sein sondern eher > 10.Zumal ich mich frage was passiert wenn ich nun so eine index.php includen will die es nicht gibt, das muss man doch vorher prüfen.
Und meiner Meinung nach sollte man schon prüfen ob es das Template gibt oder nicht, egal ob auf File- oder DB-Basis.

Was gefällt dir denn daran nicht? Gibt es da Sicherheitsbedenken oder Performanceprobleme ?
Das mit den Zig-Unterverzeichnissen kann man auch minimieren. Aber mal davon abgesehen, bekommt der User davon ja nichts mit. Denn er braucht nur die index.php des Templates ändern und schon läuft es. (Theoretisch nichts weiter!)
[/quote]Es geht mir dabei nicht um Performance geschweige denn um Sicherheitsbedenken.Lediglich um die Usability für den Anwender bzw. dem Webmaster.
Und mit zunehmender Scriptanzahl werden die Verzeichnisse immer mehr durch die dieser dann switchen muss.

Wenn ich das jetzt richtig verstehe, ja. Die Ausgabe des HTML bzw. XHTML Codes wird über die Funktionen abgewickelt. Wie man das technisch realisiert ist erstmal Rille. Aber durch eure *Panels* bzw. durch meine *Funktionen* kann der User dies gut einstellen, wie ers braucht.[/quote] nein, das ist nicht Rille ...zumal ich da die Verwendung von \"Templates\" in Frage stelle.
Wenn der Großteil des html-Outputs erst wieder von einer PHP-Datei kommt (im Beispiel mit der Liste wäre das: 1foobar) dann brauch ich keine Templates ... weil ein normalsterblicher Anwender nunmal keinen Schimmer davon hat wo in welcher PHP Datei er was änderen muss.
Hinzu kommt dann noch das Problem mit den \" bzw. \' welche er dann gegebenfalls escapen muss.
Da ändert sich nicht wirklich was im Vergleich dazu wie es jetzt ist. Mit Ausnahme der Verwendung von Funktionen.
Der Anwender kann da nicht wirklich was am Design ändern ohne in den Source eingreifen zu müssen.

[mahe]

ajo:

Bei deinen Panels reden wir glaub ich vom Gleichen: Du schreibst {$panel_login}, ich hingegen . Das ist im Endeffekt egal [smile] [/quote] ist es auch nicht ... hinter {$panel_login} steht bei mir ein bereits geparstes Template.Bei dir ist  eine Funktion welche auch den HTML-Output liefert.
Bei mir ändert der Anwender das Aussehen des Loginpanels in einem Template mit ein wenig html-Kenntnissen und dem Wissen das {$foobar} für einen Text steht.
Bei dir muss er in die Funktion, die irgendwo in irgendeiner PHP-Datei steht.
Das hat mit Templates nichtmehr wirklich viel zu tun ...

Es werden nie nur 3 Dateien sein sondern eher > 10.[/quote] Nein. Denn wie ich es schon geschrieben habe, es gibt nur im Hauptsächlichen diese 3 Dateien. Wenn der User noch neue einfügt, dann ist das sein Problem, aber dieses Templatesystem würde mit diesen 3 Dateien stehen und auch gut funktionieren.

Zumal ich mich frage was passiert wenn ich nun so eine index.php includen will die es nicht gibt, das muss man doch vorher prüfen.Und meiner Meinung nach sollte man schon prüfen ob es das Template gibt oder nicht, egal ob auf File- oder DB-Basis.
[/quote] Ich liebe es immer bei Diskussionen, wenn man mit Szenarien kommt, die konstruiert sind und keinen Ausweg bieten. Es kann dir auch passieren, dass dir einer die Klassenbibliotheken löscht, was machst du dann? Ständig prüfen, ob alle Dateien da sind? => Schwachsinn. [Aber das steht hier auch nicht zur Diskussion.]
Man könnte es so regeln, dass das Template, was als Standart festgelegt ist, seinen Pfad in der Db speichert und fertig.
Ich glaube auch nicht, dass die User ständig irgendwelche Dateien löschen, nur um mal zu testen, wie das Skript auf Grundeis geht /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />

Bei dir muss er in die Funktion, die irgendwo in irgendeiner PHP-Datei steht.[/quote] Auch nein. Denn er muss die Funktion nur einfügen, dann ist alles ok. Vielleicht noch ein paar Optionen mitgeben, aber das wars auch schon. Dies kann man ja in der Doku beschreiben, welche Funktion, was bewirkt.
Er muss nichts programmieren. Er braucht nur die index.php und ändert dort sein Aussehen bspw. mit HTML und fügt bei Bedarf die Funktionen ein, welche ihm wiederrum das Menu, die Forenübersicht oder ein Kommentarfeld einfügen.
Ich glaube fast, wir reden aneinander vorbei /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />
 
kOOni

[legato]

Was spricht gegen Smarty? Geschwindigkeit? Naja... das kann man vielleicht an anderer Stelle rausholen /uploads/emoticons/icon_e_wink.gif.fcb053ab2c91cb6224c03a16c6332abf.gif\" alt=\";)\" />
Ich finde auch eher, dass Templates Dateien sind. Der Gedanke die alle in einer DB zu haben ist irgendwie komisch.
Da ich hoffe, dass im Endeffekt alles über eine CSS Datei zu regeln ist ist das sowieso so eine Sache. Man kann auch Dateien schön im Browser bearbeiten. Dokuwiki macht es vor, das läuft super und soweit ich das beurteilen kann auch sehr schnell.
Das PHP Code da nirgends was zu suchen hat ist mal klar. Mahes letzter Post verdeutlicht das.
Wie schon an anderer Stelle gesagt finde ich das Konzept von serendipity ganz gut.
- style.css regelt eigentlich aller
- Template Files für alles mögliche (Einträge, Kategorie, blabla - quasi jedes Plugin bringt seine Template Datei mit)
- Fallback auf default Template wenn Datei nicht vorhanden - da eh alles über CSS gesteuert wird machts kaum nen Unterschied
Ich glaube, was mich aber meisten stört ist, dass ich solche Sachen lieber in einem richtigen Editor mit Highlightung usw mache. Wenn es in der Datenbank läuft, dann geht das höchstens über copy n paste.
Unschön.
soweit mein Senf dazu /uploads/emoticons/icon_e_wink.gif.fcb053ab2c91cb6224c03a16c6332abf.gif\" alt=\";)\" />

Was spricht gegen Smarty? Geschwindigkeit?[/quote]
Mir wäre auch ein fremdes Template-System recht. Smarty soll ja hingegen sehr schnell sein, da es die Dateien nochmals \"kompiliert\".
Wenn ich mir das jetzt so recht überlege, werde ich mich aus der Template-Sache raushalten, da ich zur Zeit keine Zeit und ehrlich gesagt keine Lust habe, mich noch mit Dingen, wie CSS, XHTML und JavaScript auseinander zu setzen. Das liegt einfach daran, dass man irre wird, wenn man einerseits PHP, dann CSS und HTML, dann SQL und dann noch C#.NET bzw. Delphi macht. Aber das ist mein Problem... btT.
Ich gehe einfach von meinen (guten) Erfahrungen mit dem Joomla / Mambo CMS aus. Dort hat mich die Einfachheit dieses Templatesystems faziniert, weshalb ich es hier auch gerne umgesetzt haben möchte. Aber das ist ja nur ein Vorschlag und gehört nochmal ordentlich durchdiskutiert.
Ich gebe dann mal ab an die Grafikschnauzen (ist ein lieb gemeinter Ausdruck eines Arbeitskollegen meiner Mutter). Kümmert ihr euch um das Template-Zeugs, ich schaue mir da lieber den *harten* Code an.
 
kOOni

[mahe]

Nein. Denn wie ich es schon geschrieben habe, es gibt nur im Hauptsächlichen diese 3 Dateien. Wenn der User noch neue einfügt, dann ist das sein Problem, aber dieses Templatesystem würde mit diesen 3 Dateien stehen und auch gut funktionieren.[/quote] das glaub ich so nicht.Wenn man als Beispiel powie.de nimmt, wie willst du das mit 3 Dateien machen?
Alles durch echo show_panel1(); dann echo show_panel2; ... und dass dann für jede Seite extra machen?
Ich will jetzt dass zB bei \"neue Foren Themen\" das Thread-Icon nicht angezeit wird.
Schau in das \"Template\" und seh da nur \"\"
Weil ich mich bissl auskenne finde ich diese Funktion und darin steht dann der html-Output für das Panel, da denk ich mir als erstes: \"keine Templates\".
Das hat einfach nichtsmehr mit Templates (Code vom Design trennen) zu tun ...
Und wenn es dem User sein Problem ist wird es früher oder später zu unserem Problem -> Support.
Man baut nicht erst alles auf TPLs auf um dann erst einen großen Teil des html-Codes in PHP stehen zu haben ...

Ich liebe es immer bei Diskussionen, wenn man mit Szenarien kommt, die konstruiert sind und keinen Ausweg bieten. Es kann dir auch passieren, dass dir einer die Klassenbibliotheken löscht, was machst du dann? Ständig prüfen, ob alle Dateien da sind? => Schwachsinn.[/quote] ja richtig, Schwachsinn.Der Unterschied besteht nur darin dass der Anwender TPLs angreift und was damit macht (sie eben ändert, anpasst).
Irgendwelche Dateien mit Funktionen oder Klassen hingegen wird wohl nur ein kleiner Prozentsatz ändern und der weiß meistens was er macht.
Es ist nunmal so dass Dateien die ein Anwender angreift auf unerklärliche Weise \"verschwinden\".

Auch nein. Denn er muss die Funktion nur einfügen, dann ist alles ok. Vielleicht noch ein paar Optionen mitgeben, aber das wars auch schon. Dies kann man ja in der Doku beschreiben, welche Funktion, was bewirkt.[/quote] Das ändert nichts daran dass er das Panel selbst nicht anpassen kann.Beispiel: Liste -> Spalten

[dec]

weiteres templatesystem, mit welchem ich meine seiten schreibe. ist von pear - aber pear mögen hier bekanntlich nicht alle /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />
http://pear.php.net/package/HTML_Template_IT\" rel=\"external nofollow\">http://pear.php.net/package/HTML_Template_IT
es ist ohne probleme möglich, bei diesem system eine fall-back-funktion für einzelne dateien bei mehreren styles einzubauen (ähnlich phpkit). was aber definitiv besser ist als bei anderen systemen ist die möglichkeit, blocks zu erstellen. so hat man unter umständen nur zwei bis drei dateien, aus welchen die hauptseite zusammengesetzt wird, da die blocks nested subfiles ersetzen (der graus von mahe...).
 - Editiert von DEC am 23.10.2005, 01:09 -