[DasMööp]

Hallo zusammen,

ich bin am überlegen welche Struktur am besten ist bin da etwas
unentschlossen.

Templates einzeln:

Es gibt ein Main Template (dieses enthält) :

- HTML Header und Grundstruktur

Es gibt für verschiedene Themen Templates Vorlagen.

- Für den body Bereich (zb. Artikel, Forum, Kalender was auch immer)
zb. Thread einzeln (schleife dann im Code), oder im Tpl festlegen besser !?
- Für einzellnen Einträge (zb. Foren Thread, Artikel Listing usw.)
- Für Modulboxen (seiten navigation zb)

Diese werden dann alle gesetzt und dann zusammengefügt.
Unterschieden wird anhand von Ebenen, zb. Grundstruktur Ebene 0,
Body Bereich Ebene 1 usw.

Layout angedacht:

<- Head ->
<- Body -><- Nav Boxen ->


Komplett:

Bei den Kompletten, gefunden bei vielen grossen Portalen, die jedes
Template komplett gestallten. Also die ganze Seite in dem einem Template
vorhanden ist.
Aber warum ? Denn wenn ich etwas am HTML Header ändern möchte oder
sonst etwas muss ich jedes Template ändern.




Wie habt Ihr das bei Euren Frameworks, oder Projekten umgesetzt ?

Ich Favorisiere ersteres auch wenn es mehr Dateien sind. Wie seht Ihr das ?

Und gab es nicht mal einen Thread hier, in dem besprochen wurde wie
weit eine Template Classe Schleifen und anderes umsetzten sollte ...
bzw in wie weit es Sinnvoll ist das die Classe oder dies im Template
umzusetzten ...

Grüsse

[Artemis]

Ich favorisiere auch die Methode mit einer Layout-Datei und mehreren Templates.

Bei meinem Framework wird das dann so funktionieren:

PHP-Code:

class Controller_Bla extends Controller
{
  function index()
  {
    //...
    $this->loadView('layout-datei', VIEW_LAYOUT);
    $this->view->addView('main-datei', 'body');
    $this->view->addView('sidebar-datei', 'sidebar');
    //...
  }
} 


Das lädt zuerst das Layout 'layout-datei' und benutzt für die beiden Platzhalter 'body' und 'sidebar' im Layout die Templates 'main-datei' und 'sidebar-datei'.

EDIT: Wobei ich mir noch nicht sicher bin, ob ich dann nicht noch eine Klasse "Layout" mache, sodass man das layout per $this->loadLayout lädt, was eine striktere Trennung von Templates und Layouts gestattet.

[Ben]

Ich nutze auch die Struktur, dass nicht in jeder Templatedatei die ganzen Informationen aus z.B. dem Header, Footer oder einer Seitenleiste vorhanden sind. Bei den Seitennleisten habe ich allerdings mehr als eine, da ja die Struktur einer solchen Leiste auch von Seite zu Seite unterschiedlich sein kann!


Bzgl.:

Zitat von DasMööp

Und gab es nicht mal einen Thread hier, in dem besprochen wurde wie
weit eine Template Classe Schleifen und anderes umsetzten sollte ...
bzw in wie weit es Sinnvoll ist das die Classe oder dies im Template
umzusetzten ...

Schleifen in einem Template verarbeiten
Templatesystem - Foreach-Schleifen

?

[DasMööp]

Fein, das hilft mir schonmal ein Stückchen weiter. Auch wenn ich mich
gewundert hatte das einige Portale das anders machen.

Es wird jetzt die einzeln Methode.

Basierend auf ...

1. Layoutschicht (Grundstyle)
2. Layoutschichten (das jeweilige Style Tpl)
3. Tpl Inhaltsschichten (das jeweilige Tpl zum Inhalt)

... Je nach vorhandenem Request.

---

zum Link, jain, aber letzterer ist ja schon in die Richtung.
Evtl. ist er es ja ... ich gugg mal, Danke.

[Artemis]

Noch etwas, was zum Thema passt:

Ich überlege mir gerade das Design für so einen Aufbau.

Generell habe ich dann eine abstrakte Klasse namens View, von der die Klasse Layout und eben die Klasse für Views/Templates, welches entweder selbstständig sein können, oder von einem Layout benutzt werden, abgeleitet sind.
Mir fällt aber momentan kein vernünftiger Name für eben diese Klasse ein.

Für ein kleines UML-Diagramm siehe Anhang.

[MrNiceGuy]

Es gab auch mal eine grundsätzliche Debatte über die Funktionen, die ein Template-System bieten sollte:

Tamplates - Was sie bieten sollten!?

Ansonsten mal zu meinem Template-System:

Ich benutze z.B. ein Template für das Layout (bzw. mehrere, denn: Für jedes Layout ein Template) und dann für jedes Script eine eigene Template-Datei. Es entstehen zwar viele Dateien, dafür werden die einzelnen Templates jedoch kleiner und somit auhc übersichtlicher. Wenn ich etwas ändern muss, brauche ich immer nur eine Datei anpassen. Zusätzlich zum Punkt "Jedes Layout = eine Datei" und "jedes Script = eine Datei" gibt es natürlich auch noch kleinere Implementierungen anderer Art, die man in einzelne Templates auslagern kann (und auch sollte), so z.B. die Seiten-Navigation (Seitenzahlen) oder das Hauptmenü.

[Artemis]

Keiner ne Idee?

View kann ich ja nicht benutzen, da die Oberklasse so heißt. Ist ja auch zu allgemein.

Template ist mir auch zu allgemein, denn ein Layout (ebendiese Klasse) ist ja auch ein Template.

Mehr fällt mir nicht ein.

[Bleistift]

(View|Layout)Renderer?

[Artemis]

Ich habs mir jetzt anders überlegt.
View ist jetzt keine abstrakte Klasse mehr, sondern die Klasse für die Views (selbstständig, oder als Teil von Layout). Layout ist dann davon abgeleitet.

So scheint es mir am sinnvollsten.

[dr.e.]

Hallo DasMööp,

Wie habt Ihr das bei Euren Frameworks, oder Projekten umgesetzt ?

Ich gehe zunächst von einer generischen GUI-Struktur aus. Das bedeutet, dass ich eigentlich zunächst nur einen Typ von Baum-Knoten kenne: das Document. Des weiteren kenne ich von Document abgeleitete Typen, die jeses für sich eine bestimmte Funktion ausführen / inne haben können. Jedes dieser Knoten formt am Ende eine von dir bestimmte Struktur der GUI: einen DOM-Baum. Jedes dieser Knoten ist eine eigene MVC-Einheit und besitzt einen Controller, ein Template und ein Model (falls gewünscht, kann auch eine gemeinsame Business-Schicht sein).

Am konkreten Beispiel:
- Du erstellst ein Haupt-Template, mit dem Grundgerüst deiner Seite
- Darin siehst du HTML-mäßig Bereiche vor, in die du dein Menü, News-Bereich, whatever einbinden möchtest
- In die HTML-Bereiche bindest du mit XML-Tags (hier <core:importdesign />) deine weiteren Views wie Menü oder News ein.
- In den Templates des Menüs oder der News kannst du genauso nochmal weitere Templates einbinden oder einfach statische Inhalte eintragen
- Möchtest du nun einen View mit dynamischen Inhalten füllen, gibst du am Anfang des Templates bekannt, welchen Controller du nutzen möchtest und dieser wird dann beim Transformieren des Objektbaums auf den Knoten ausgeführt und generiert dir deine dynamischen Inhalte wie du sie brauchst.
- Da jeder Knoten, der per <core:importdesign /> eingebunden wird wieder eine Template-Datei (View) ist, kannst du dort auch weitere HTML-Skelette definieren (<html:template />), die du zur Gestaltung der dynamischen Inhalte verwenden kannst.
- Wenn dir die XML-Tags nicht reichen, die du zur Verfügung hast, kannst du diese auf Basis der Klasse Document auch erweitern, sprich deine eigene TagLib schreiben, die dir z.B. eine bestimmte Formatierung erzeugt, oder weitere Inhalte (z.B. aus Sprachdateien) dynamisch einbindet

Ich Favorisiere ersteres auch wenn es mehr Dateien sind. Wie seht Ihr das ?

Mehrere Dateien sind zwar irgendwann eine echte Verwaltungsaufgabe, wenn diese jedoch gut strukturiert sind, ist es sicher immer einfacher zu verstehen, wozu welche gehört. In meinem Fall wird im Template auch noch der Controller definiert, so dass über den Ordner, in dem die Datei liegt und den Controller immer eine eindeutige Zuordnung möglich ist.


Du fragtest nach Links:
- http://www.adventure-php-framework.org/
- http://www.adventure-php-framework.org/Seite/Templates
- http://www.adventure-php-framework.org/Seite/TagLibTags
- http://www.adventure-php-framework.org/Seite/Controller
- http://www.adventure-php-framework.o...ontaktFormular

[DasMööp]

"Jedes Layout = eine Datei" und "jedes Script = eine Datei"

Also ich bin jetzt soweit das ich für jedes Layout eine kleine Tpl-Page habe
für den Body Bereich.

Was mir grad nicht so passt aber ich nicht drum herum komme ist:

Ich Initalisiere das System in einer Mainklasse.
In dieser sind alle Grundsätzlich nötigen Klassen Included und deklariert.

In einer davon fange ich die Requests auf und anhand dieser
(z.b. page=index) Lade ich eine Classe page_index extends page_abstract

So nun stehe ich vor dem das ich jeweils eine Tpl-Datei habe, aber auch
eben eine Classe. Somit sind das aber später sehr viele Dateien wenn ich
jedesmal eine Tpl und die Klasse dazu mache pro action !?

Ist da sozusagen dann mein "Dokument-Controller", und die page_abstract
mein page_manager. Grundsätzliche Definitionen und Methoden sind ja im Modul
dann drin.

Beispiel (news
index.php5?page=news
index.php5?page=news_detail&id=1
index.php5?form=news_new
index.php5?form=news_edit&id=1
index.php5?action=news_save&id=1
index.php5?action=news_delete&id=1


Oder ist das schon in der Art der Richtige Weg ?
*verwirrung*

[Basti]

Was spricht denn dafür, die Anzahl der Dateien möglichst gering zu halten? Ist für mich irgendwie kein Kriterium - wichtig halt, dass diese gut organisiert sind. Ich hab gerade mal gezählt: hab in meinem "lib"-Verzeichnis neben ein paar Verzeichnissen 78 Dateien mit je einer Klasse, Templates sind es 45 - auch alle in einem Verzeichnis. Das ist natürlich Käse und ich werde das bei Zeiten umbauen. Aber eben dahingehend, dass ich die Dateien gruppiere und in Verzeichnisse stecke. Ich würde da jetzt nicht mehrere Dateien zusammen in eine Datei packen.

Was ich zum Teil mache ist, dass z.B. ein Formular zum Anlegen eines Datensatzes (etc.) und das zum bearbeiten zusammen in einem Template beschrieben wird, wenn es sich nur in Details unterscheidet.

Und was die Controller/Actions angeht, so besitzt bei mir momentan jedes Modul genau einen Controller und die "Actions" werden durch Methoden repräsentiert. Ich werde die andere Option (eine Klasse je Action) aber noch einbauen. Bei vielen Modulen ist das übertrieben, aber z.B. der Controller, der die Seiten verwaltet, ist in knapp 900 Zeilen Code (ohne Kommentare) beschrieben … und das ist natürlich auch ein wenig … ähm … zugeballert.

Basti

[DasMööp]

Also bin ich ca. schon auf dem richtigen wege, ...

Habe in meinem lib 15 Dateien bis dato ... sind aber auch nur die
internen + module (werden wohl mehr als bislang index und test)

/system
/system/class/ (hier sind die Page Controller, werden ja Auto init)
/system/style/ (Grundstyles des Systems / Layout-html / css)
/system/tpl/ (page/,form/,action/ ... templates)
/system/lib/modul/ (jeweis das Modul für zB. User, News,...)
/system/lib/ -> und ebens dann ornder mit den jeweiligen Klassen die das
Sytem braucht ... exception,mysql,template,parse usw usw.


Das mit den template möchte ich auch so wie Du angeschnitten hast etwas
verfeindern. Dh. zb. bei den tpl/form/ gibt es ein tpl nur mit dem Std. Textfeld.

Welches ich ja über die Template Classe, im Page Controller jederzeit einer
Variablen zuordnen kann. (Das Feld kann ja immer gleich lauten in den Tpls)

In dem Autogeladenen Template integrieren kann. (Bedingt da sich das in dem
Controller noch eigens definieren/änern lässt)

/system/tpl/page/page_index.tpl
/system/tpl/form/form_news_new.tpl
/system/tpl/global/textarea.tpl

Im (form_news_new.tpl) setze ich nur {tpl$textarea.tpl}

Oder über eben die jeweilige Page Controller Klasse einfach einer Var per
setTpl im Template zuordnen.

Im (form_news_new.tpl) setze ich nur {$textarea}
Und im news_new.class.php5 (Controller) dann :
....->setTpl('textarea',getFile('./global/textarea.tpl'));

Fazit / pro tpl das per Automatischen Aufruf geladen wird eine Controller Klasse.

Gut, dann werde ich das Ding jetzt noch bischen überarbeiten ...