[Ben]

Hi,
das ist jetzt eigentlich kein wirkliches "Programmier"-Problem, aber da wir kein Forum für "Modellierung" oder so haben schreibe ich es mal hier rein.

Ich schreibe eine Template-Klasse, welche Blöcke und Variablen kennt. Ich frage mich nun, ob es sinnvoll ist die Blöcke zu unterscheiden.
Eine Unterscheidung ist in meiner Implementierung wichtig, nämlich zwischen Blöcken mit weiteren Template-Variablen oder -Blöcken und Blöcken, die nur statischen Inhalt enthalten.
Das ist für mich sinnvoll, da ich so durch eine if-Abfrage erkennen kann, ob ich preg_replace() auf den Template-Code loslassen muss oder ob eine simple Zuweisung genügt.

Gut. Jetzt zum eigentlichen Punkt.
Ich mache es derzeit so, dass man solche "content blocks" explizit via setContentBlock($blockName) angeben muss. Das hat den Vorteil, dass die Template-Engine sogenannte "unused blocks" erkennt und aus dem Template herausstreicht.
Sind keine Daten für den Block vorhanden und ist es kein "content block", so wird der Block während dem "parsen" nicht beachtet.

Frage ist nun, ob das überhaupt nötig ist.
Ich sehe den Vorteil darin, dass man im Template Kommentare schreiben kann, die dann letztlich aber nicht im Quelltext angezeigt werden. Man könnte das einfach so machen

<!-- BEGIN DOC_foobar -->
Kommentare, Doku, ... whatever
<!-- END DOC_foobar -->
<!-- BEGIN foobar -->
...
<!-- END foobar --> 

Alternativ lässt man die Methode setContentBlock() weg und sieht jeden Block ohne Template-Variablen oder -Blöcke als "content block" an und verwendet diesen dann auch so.

Was sagt ihr dazu?
Danke.

Grüße, Ben.


Randinfo (vielleicht ist das nützlich zu wissen?) .. :
Ich suche die Blöcke aus dem Template und ersetze sie in der Template-Datei durch eine Variable. Heißt der Block

<!-- BEGIN foobar -->

<!-- END foobar --> 

so heißt die Variable danach

{foobar}

[Ben]

Noch ein Beispiel, vielleicht ein etwas besseres.

Man hat eine Template-Datei, in der ein Loginformular dargetellt wird. Wenn man aber schon eingeloggt ist, braucht man das Formular natürlich nicht mehr. Anstatt jetzt für das Formular eine extra Datei zu verwenden schreibt man den Block einfach mit in die "normale" Template-Datei. Ist man eingeloggt wird der Block ignoriert "unused block", ist man nicht angemeldet so wird der Block mittels setContentBlock() als "anzuzeigen" deklariert ...
Wenn in dem "Login-Block" sowieso Variablen eingeparsed werden sollen, wenn man nicht eingeloggt ist, ist das setContentBlock() ja hinfällig, weil der Block ja nicht als "unused" angesehen wird.

Meinungen?

[Basti]

Meine Frage hierzu wäre, wer (Template-Designer/Programmierer) welche Möglichkeiten erhalten soll. Ich würde die Steuerung der Sichtbarkeit von Komponenten weitgehend dem Template überlassen, weil es mmer billiger ist, daran was zu ändern, als die Controller umzuschreiben.

Die Methode, Blöcke in einer Datei separat zu definieren finde ich fein (wenn ich dich da richtig verstanden hab). Aber das Einbinden würde ich dennoch immer über konditionale Abfragen im Template machen. Allein schon, um transparent zu machen, was da passiert. Beispiel wäre:

<div class="margin_col">
    <t:if cond="!User.loggedIn()">
        <t:include component="login_form" />
    </t:if>
</div>

<t:component id="login_form">
    <form>...</form>
</t:component>

...wobei es in dem Fall auch wiederum ziemlich unsinnig äre, eine extra Komponente (Block, ...) zu definieren, anstatt das Formular direkt in die Bedingung zu schreiben.

Hab neulich ein FUDForum aufgesetzt. Dort gibt es auch je mehrere Sektionen in einem Template.

Basti

[Ben]

Interessant, passt nur halt genau kein bisschen zum Thema.
das Template hat keine Macht über die Logik. Daran wird eine Diskussion nichts ändern.

[Basti]

Was ist denn dann genau das Thema?

Und, deine Aussage stimmt so nicht. Darstellungslogik gehört natürlich ins Template. Die Frage ist eben, wo man die Grenze zieht.

Basti

[Ben]

Ich will hier aber keine Grundsatzdiskussion führen.

Habe ich denn meine Frage nicht ausreichend genug gestellt?
Ich würde gerne Meinungen hören, ob man eine Unterscheidung zwischen reinen "content blocks" und "unused blocks" braucht.

Alles andere gehört hier nicht rein.

[Basti]

Zitat von Ben

Ich will hier aber keine Grundsatzdiskussion führen.

?

Habe ich denn meine Frage nicht ausreichend genug gestellt?
Ich würde gerne Meinungen hören, ob man eine Unterscheidung zwischen reinen "content blocks" und "unused blocks" braucht.

Wer soll dir beantworten, was "man" braucht? Wenn es dir um die Performance geht, dann nimm einfach mal ein paar typische und ein paar extreme Anwendungsfälle und mess beide Lösungen durch.

Bei mir werden Templates nur einmal via Skript geparsed und später wird einfach nicht ausgeführt, was "unused" ist. Drum komm ich anscheinend auch nicht in deine Problematik rein. Aber vielleicht gehts anderen hier ja anders.


Oder: Mach doch mal Werbung für deine "unused Blocks": Warum die so toll sind und warum sie deine Template Engine verbessert haben. Vielleicht versteh ichs dann.

Basti

PS:
Und, ich will dich nicht mit grundsätzlichem Zublubbern, versteh eben nur einfach nicht, was konkret du von uns bzw. was du da umsetzen willst…

[Ben]

Zitat von Basti

Wenn es dir um die Performance geht, dann nimm einfach mal ein paar typische und ein paar extreme Anwendungsfälle und mess beide Lösungen durch.

Den Ratschlag habe ich nunmal befolgt bzw. hoffe, dass das in nächster Zeit mal austesten kann.

Zitat von Basti

Oder: Mach doch mal Werbung für deine "unused Blocks": Warum die so toll sind und warum sie deine Template Engine verbessert haben.

Hm.
Ob die irgendwas verbessern weiß ich nicht.

Ich erklär das nun auch nicht, wie ich darauf kam. War eben eher aus einem speziellen Anwendungsfall heraus. Ich überdenke das nochmal in Ruhe und würde dann eventuell nochmal darauf zurückkommen, mit einer etwas intensiveren Erklärung, was ich eigentlich machen will.

Danke bis hierhin.


[PS]
Mir gefällt die Struktur, die du da dargestellt hast.