nicht angemeldet
Alternativen zu Smarty?
Hi
Ich habe mir vorhin (und vor einigen Monaten mal) die Smarty-Enginge angeschaut. Sie leistet sicherlich viel, jedoch ist sie mir zu gross... das wäre wie mit kanonen auf Spatzen schiessen wenn ich sie integrieren würde.
Gibt es schlankere Engines? Oder gibt es gar simple prinzipien nach denen ich mir selber eine kleine engine bauen kann?
bye
-
Moin,
Das ganze Problem fängt damit an, dass Du beschreiben mußt was Du erreichen willst.
Das simpleste System wäre sicherlich eine Kopf und eine Fuss Datei die jeweils includiert werden.
Also 1. Frage was willst Du erreichen.
TomIRL-
Im Grunde kann ich was ich will ganz genau beschreiben, was lediglich machbar ist (und ich deswegen nur realisieren kann) ist etwas anderes.
Ich möchte eine Seite die ich mit CSS, Layern Tabellen etc. aufbauen kann um am ende sagen zu können: "Hier soll immer das hin... hier immer das... und jenes immer dort".
Ich vergleiche Templateengines immer gerne mit einer Verteilerkappe: Ich habe ein Gerät das flexible Kabel hat die ich auf ein Design stecken kann... und bei belieben wieder abziehen und auf ein neues Design stecken kann.Das PRoblem das ich sehe/erkenne ist eben wirklich die Technik des includes. Es kommt mir zu plump vor einfach Dokumente in PHP zu includen. Ich gehe dennoch meist dazu über eine Mainpage zu zimmern die menues und footer included und ein variables include besitzt in das er diverse contents läd.
Mein Problem ist (seit Wochen schon in denen ich Bus und Zug fahre und drüber nachdenke) wie muss eine kluge Template-Engine aufgebaut sein um schlank zu sein und dennoch nur eine Centerpage zu besitzen anhand der ich alles ändern kann?
Und nun kommst du.
bye
-
Hallo,
wie muss eine kluge Template-Engine aufgebaut sein um schlank zu sein und dennoch nur eine Centerpage zu besitzen anhand der ich alles ändern kann?
Das wird wohl sinnvoll nicht gehen. Ich würde das schon auf mehrere Dateien aufteilen. Bei eine Weblogsoftware, die ich schreibe habe ich es so vor zu lösen:
- Hauptseite mit Design
- Sidebar
- Kommentare
- Kommentareingabefeld
- Zusammenfassungen (für Suche, Archiv, etc.)Wenn man nun ein Neues Design haben will kann man erst einmal nur die Hauptseite mit Design ändern und die anderen Sachen als Standardtemplate lassen, bei denen macht es ja nichts, wenn sie sich wiederholen.
Falls mann doch irgendetwas ändern möchte kann man es aber dennoch tun. Dabei bleiben die einzelnen Teil-Templates übersichtlich.
Hier eine Beispieldatei von meinem Jlog Template:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title><jlog:title /> - <jlog:website /></title> <jlog:aditional-header /> <link rel="stylesheet" href="<jlog:homelink />/personal/css/print.css" type="text/css" media="print" /> <link rel="stylesheet" href="<jlog:homelink />/personal/css/screen.css" type="text/css" media="screen, projection" /> </head> <body> <p class="skip"><a href="#main"><jlog:skipcontent /></a></p> <h1><a title="<jlog:home />" href="<jlog:homelink />/index.php"><span></span><jlog:website /></a></h1> <jlog:menu activeclass="active" /> <div id="subnav"> <jlog:submenu class="submenu" activeclass="active" /> <h3>Search this page:</h3> <form action="<jlog:homelink />/search.php"> <p><input class="userdata" type="text" name="q" size="15" value="<jlog:searchstring />" /> <input class="send" type="submit" value="<jlog:search />" /></p> </form> <h3><jlog:current-h /></h3> <jlog:subcurrent /> <p><jlog:archive-more /> <a href="<jlog:archivelink />"><jlog:archive /></a>.</p> <h3><jlog:sub-info /></h3> <p><jlog:copyright /></p> <p><jlog:powered /></p> </div> <div id="main"> <jlog:descriptiononindex class="descriptiononindex" /> <jlog:content /> </div> </div> </body> </html>Das einzige was mir hier noch nicht so richtig gefallen möchte ist das <jlog:homelink /> welches immer innerhalb eines Attributes erscheint wie bei den Links. So wird das nie richtiges XML ;-). Aber ich habe noch keine sinnvolle Alternative gefunden, wenn jemand was vernünftiges weiß immer her damit.
Grüße
Jeena Paradies-
Hallo Freunde des gehobenen Forumsgenusses,
Das einzige was mir hier noch nicht so richtig gefallen möchte ist das <jlog:homelink /> welches immer innerhalb eines Attributes erscheint wie bei den Links. So wird das nie richtiges XML ;-). Aber ich habe noch keine sinnvolle Alternative gefunden, wenn jemand was vernünftiges weiß immer her damit.
Ich würde der Template-Engine beibringen zwei Varianten zu verstehen:
Erstens die existierende Variante (jlog:xyz/) und zweitens eine Variante,
die in Attributwerten vorkommen darf ([[[jlog:xyz]]]),
dann kann man in Attributwerten die zweite verwenden
und hat trotzdem noch einen eigenen XML-Dialekt,
den man ganz normal durch einen XML-Parser jagen kann.Gruß
Alexander Brock--
SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) rl:( n4:? ss:| de:> js:( ch:| sh:( mo:} zu:}
http://againsttcpa.com
-
-
Hallo Sudo!
Ich vergleiche Templateengines immer gerne mit einer Verteilerkappe: Ich habe ein Gerät das flexible Kabel hat die ich auf ein Design stecken kann... und bei belieben wieder abziehen und auf ein neues Design stecken kann.
Ja, Template-Engines sollen eben die Präsentation von der Programmlogik/Geschäftslogik trennen. Daher sollte eine Template-Engine/-Klasse meiner Meinung nach auch so schlank wie möglich sein, und nur die nötigsten Funktionalitäten bieten - so dass man rein technisch schon gar keine Geschäftslogik in die Templates packen kann.
Das PRoblem das ich sehe/erkenne ist eben wirklich die Technik des includes. Es kommt mir zu plump vor einfach Dokumente in PHP zu includen.
Warum? Jede Template-Engine erzeugt einen zusätzlichen Overhead bei der Entwicklung, da muss man abwägen ob der Einsatz einer Template-Engine sinnvoll ist, oder ob ein paar einfache include(), readfile() für die simple Anwendung nicht ausreichen.
Übrigens solltest Du HTML-Dateien, die keinen PHP-Bereich enthalten mit readfile() einlesen, aber das nur nebenbei.Ich gehe dennoch meist dazu über eine Mainpage zu zimmern die menues und footer included und ein variables include besitzt in das er diverse contents läd.
Was ist daran so schlecht? Musst halt lediglich sicherstellen, dass Dein "variables include" wirklich nur die Dateien laden kann, die Du dafür vorsiehst, und nicht z.B. "/etc/password" oder eine Datei mit Datenbank-Zugangsdaten. Das hat aber nicht wirklich etwas mit Template-Enginges zu tun.
Template-Engines werden vor allem aus 2 Gründen eingesetzt:
1. um wie bereits erwähnt die saubere Trennung zwischen Präsentation und Logik zu garantieren
2. um das schreiben und verändern der HTML-Oberflächen zu vereinfachen (durch einfachere Syntax und Hilfsfunktionen, z.B. für Formulare und Trennung des HTML-Codes von komplexer Programmlogik...)
Mein Problem ist (seit Wochen schon in denen ich Bus und Zug fahre und drüber nachdenke) wie muss eine kluge Template-Engine aufgebaut sein um schlank zu sein und dennoch nur eine Centerpage zu besitzen anhand der ich alles ändern kann?
Es gibt 2 große Lager bzgl. Template-Engines in der PHP-Community. Die einen sagen, PHP ist selber als Template-Engine für C-Anwendungen entwickelt worden, bringt dem entsprechend schon alles mit was man für eine Template-Engine braucht. Man benötigt keine neuen Tags/Sprachkonstrukte oder sonstwas, das ist nur zusätzlicher Aufwand zum erlernen und macht die Anwendungen langsamer. Die Syntax von PHP selbst ist ja eine Template-Sprache, die sich in HTML-Templates einbetten lässt - wozu also noch eine neue Syntax?
Um trotzdem die Präsentation von der Logik zu trennen, kann man entweder eine eigene, simple Template-Klasse schreiben, in der die Templates dann später in einfachem PHP geschrieben werden. Die vielversprechenste Engine die diesen Ansatz verfolgt ist in meinen Augen Savant.Auf der anderen Seite stehen die Template-Engines mit eigenen Tags oder kompletter, eigener Syntax, wie eben Smarty. Hiervon sagt man IMHO zu Recht, dass die Syntax zwar anders ist, aber auch einfacher. Abgesehen davon verfügt vermutliche keine andere Template-Engine über so viele Hilfsfunktionen für HTML-Ausgabe wie Smarty. In meinen Augen ist das allerdings viel zu viel. 90% der Sachen die man mit Smarty machen kann finde ich wirklich schwachsinnig - und hebelt zum Teil auch die Trennung von Präsentation und Logik aus. Und es gibt auch viele Hilfsfunktionen die einfachste HTML-Tags ersetzen - kann ich nicht wirklich nachvollziehen wozu das gut sein soll.
Smarty hat aber 3 entscheidende Vorteile gegenüber den meisten anderen Template-Engines:
1. Smarty ist sehr modular aufgebaut, so dass wirklich nur die Funktionalität geladen wird, die tatsächlich benötigt wird
2. der aus den Smarty-Templates erstellte PHP-Code wird gecached - solange man die Templates nicht verändert, müssen die nicht neu geparst werden.
3. Smarty ist wohl mit Abstand am weitesten verbreitet und schon seit Jahren sehr stabil/robust
Bis vor einiger Zeit war ich mir immer relativ sicher, dass Smarty allein wegen der Größe und den vielen Funktionalitäten viel langsamer sein _muss_ als die ganzen (schlankeren) Engines mit PHP-Templates - "kompilierte Templates" hin oder her. Vor ein paar Monaten hatten wir dann mal ein handfestes Performance-Problem in einer Anwendung, und mussten mit einem Profiler (xdebug) die Ursache finden. Ich war mir eigentlich ziemlich sicher, dass Smarty einer der Gründe sein würde. Also habe ich es mit mehreren anderen Template-Engines verglichen, und musste zu meinem Erstaunen feststellen, dass Smarty sogar vergleichsweise schnell ist - zumindest wenn man nicht zu viele Template-Funktionen verwendet (da dies oft PHP-Funktionen sind, die im Userspace als Smarty Modul implementiert sind...). Das galt vor allem wenn man einen Opcode-Cache wie APC verwendet, aber auch ohne lief es erstaunlich gut. Natürlich nur mit Caching der "kompilierten Templates", sonst war es deutlich langsamer. Entsprechend würde ich auch dringend von jeder Template-Engine abraten, die eigene Tags/Syntax verwendet, aber die erzeugten PHP-Scripte nicht cached!
Und was die vielen Template-Funktionen oder eingebetteten PHP-Code... angeht - es zwingt Dich ja niemand diese Funktionalitäten zu verwenden, oder? Und um ein paar der Hilfsfunktionen wirst Du früher oder später nicht drum herum kommen. Wenn Du dann Deine eigene Lösung gebastelt hast, musst Du das dann später implementieren, immer mit dem Risiko dass Du Fehler einbaust, die sich erst viel später bemerkbar machen...
Viele Grüße
Andreas--
SELFHTML Linkverzeichnis: http://aktuell.de.selfhtml.org/links/
-
-