dr.e.

Hallo DER_Brain,

Ich kann hier RaZoR nur zustimmen, Smarty ist einfach nicht dafür ausgelegt so genutzt zu werden. Smarty ist für den Bereich gut, in dem es nur um einfaches Templating geht. Kommen Themen wie PageController, MVC und Verschachtelungen, die nicht mal in der Komplexität und Tiefe beschränkt sind hinzu, scheidet Smarty eindeutig aus.


Ich hab dir zwar schon per PN geantwortet, allerdings will ich das Beispiel der Welt nicht vorenthalten. Auf diesem Konzept ist übrigens das APF aufgesetzt, beinhaltet jedoch noch einige Feinheiten mehr, die das Leben und Arbeiten einfacher und Effizienter machen. Die Grundzüge werden aber sicher schnell klar. Hier nochmal mein Text der PN in gekürzter Form:

Das Beispiel-ZIP unter http://adventure-php-framework.org/p...parser_dom.zip heruntergeladen werden. In der enthaltenen Datei findet sich die notwendigen Klassen und drunter ein Beispiel. Der Code ist nicht komplett dokumentiert, ist ja auch nur Pseudocode, damit klar wird, wie das eigentlich funktioniert. Wer ausformulierten Code möchte, einfach mal auf der Webseite des APF vorbei schauen und das adventure-codepack-*-Paket runter laden. In der Datei core/pagecontroller/pagecontroller.php befindet sich ein komplett dokumentiertes und ausformuliertes Beispiel. Die Features, die man damit realisiert werden können, sind unter http://adventure-php-framework.org/Seite/047-Templates und http://adventure-php-framework.org/Seite/006-Controller bzw. http://adventure-php-framework.org/S...eite-erstellen beschrieben.

Nicht ganz zum Thema aber interessant, für den, der das mal ausprobieren möchte:
Wer sich an der bisherigen (initialen) Konfiguration stört, das ist bereits in der Entwicklungsversion gelöst - sprich entfernt. Wenn jemand also ein Test-Release haben möchte, das mit der einfacheren Variante läuft, einfach unter http://adventure-php-framework.org/f...-php4_php5.zip das neue Package runterladen. Das Paket enthält gleichzeitig eine Beispielwebseite, das die ersten Schritte dokumentiert.

Solltest du noch Fragen haben, einfach fragen.

@RaZoR:
Nein! Eine Template-Sprache hat den entscheidenden Vorteil, dass DU für die Implementierung zuständig bist und der Anwender nicht jeden Mist in PHP in sein Template frickeln kann und hinterher der Code ächzend langsam ist. Zudem kannst du den Code formalisieren und damit die Möglichkeit der Abstraktion schaffen. Erst wenn du weg vom PHP-Code bist, sprich selbst von der PHP-Engine geparst wirst, hast du die Möglichkeit in das Template-Geschehen von aussen steuernd einzugreifen und generisch Module oder TagLibs oder was auch immer zu laden. PHP-Templates mögen zwar schnell sein, aber man muss wieder mit ob_start() & Co. arbeiten, dass der Output nicht direkt gesendet wird, was höchst unsauber ist. Dann schon lieber den DOM-Baum sauber im Speicher aufbauen, denn dann kann ein Knoten die Informationen eines anderen Knoten für seine Verarbeitung nutzen (siehe Formulare). Anders ist das ein wildes Gebastel und entbehrt jedweder Allgemeingültigkeit.

Genau da sind fangen wir dann an zu basteln und zu frickeln, weil jeder mal eben schnell was in das Template einbaut, was niemals wieder weiterverwednet werden kann, da man in einem anderen Template die gleiche Funktion nochmal basteln muss. Das hat dann definitiv nichts mehr mit gutem Softwaredesign zu tun. Sorry, aber gutes Software-Design ist nicht nur Performance!

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mister Ad

dr.e.

Nachtrag: unter http://www.phpfriend.de/forum/ftopic64004-s10.html wurde das Thema bereits diskutiert, hier kann sich der geneigte Leser sicher einige Informationen ziehen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Flor1an

Wenn du externe Templateentwickler mitwirken lässt denen man nicht vertrauen kann ist eine eigene Templatesyntax sicher von Vorteil und man kann nur bestimmte Funktionen zu Verfügung stellen.

In den meisten Projekt arbeiten allerdings Designer und Entwickler Hand in Hand und es ist möglich PHP in Templates zu erlauben bzw. generell damit zu arbeiten.

Rein auf PHP basierende Templates lassen sich auch durchaus auch ohne ob_start() etc. realisieren indem der Aufbau und das Laden der Templates geschickt und in richtiger Reihenfolge gemacht wird.

Hierbei meinte ich eigentlich das Entwickeln von bestimmten Helpern die dann überall eingesetzt werden. Diese Helper werden natürlich nicht IM Template sondern separat entwickelt und nur im Template aufgerufen. Dies würde dann TagLibs oder Modulen gleich kommen.


Über Templatesysteme lässt sich ja bekanntlich viel diskutieren. Im Endeffekt entscheidet die Anwendung bzw. die Anforderungen an die Software. Ich denke dass sich unsere Ansätze nicht Grundlegen unterscheiden sondern du nur gerne eine eigene Syntax die PHP & Template trennt nutzt. Sicherlich interessant für ein Framework dass auf mehrere Anwendungen abzielt.

phpdummi

Ohne mich in diese Diskussion unbedingt einmischen zu wollen:

Ich finde es einfach schöner bei einer Sprache/Syntax zu bleiben. Außerdem <core:import="tpl/subtpl.html" /> ist schnell mal eben hingeschrieben...

Das Document Object Model bietet viele hervorragende Möglichkeiten. Gerade bei Menüs oder anderen verschachtelten Elementen.

DER_Brain

Wiederum ein Danke an euch alle!

Werd ma jetzt die Links von dr. e ansehen und auch das DOM Model genauer betrachten.

lg
Andi

PS: Kann man closen!