Temapltes aus der DB oder aus dem FS?

Durch eine unterhaltung im IRC bin ich mal neugierig nutzt ich bei euch Teamplates wenn ja wo liegen die in der datenbank oder dierekt auf festplatte?

Und worin seht ihr den Vorteil eurer lösung?

Dateisystem rockt ;-)

Im Deiteisytem - was sonst? =)

genau was sonst als das dateisystem

ich habe aber von leuten gehört dei templates echt in der DB halten.

aberwie gesagt $dateisystem++

Noch benutze ich keine Templates, ich ärgere mich ständig darüber...
Aber ich will bald ein neues Design entwickeln, dort werde ich dann auf Files zurückgreifen

templates in der DB? dann bräuchte ich ja nochmal ein extra CMS wenn ich die mal ändern will...nene meine liegen brav im templates-Ordner...damit ich sie schön und einfach mit meinem Traumweber verändern kann

Also meine derzeitige Templateengine verwendet auch (noch?) ein Dateisystem für die Cachefiles.

Für Dateisystem spricht der geringe Ressourcenverbrauch bzw. auch die Geschwindigkeit.
Für Datenbank spricht die flexibilität. Man kann die Caches Usern und/oder anderen Werten zuordnen und so flexibel Caches laden. Problem ist nur die zusätzliche Datenbankbelastung.
SQLite halte ich ehr wenig. Bei 1000 Usern und vielleicht 15 Templates dürfte SQLite leicht überfordert sein.

Was bzw. wofür ich ich die Caches in meiner neuen Templateengine verwenden weiss ich noch nicht ganz.. statt die komplett geparseten Ausgabeseiten zu speichern und die Seite (bei dynamischen Inhalten) dann vielleicht 1-2 anzuzeigen, würde ich ehr die Parselemente die ich zum verarbeiten verwende zwischenspeichern und somit dann vielleicht statt ner ganzen Seite nur ein paar Variablen parsen.

Ganz klar Dateisystem, aus Performancegründen. E-Accellator kann die notwenigen Includes cachen, was um vieles performanter ist, als die DB zu belästigen.

http://sourceforge.net/projects/php-templates
sau schnell da php-erweiterung

http://www.phpsavant.com/ in Zukunft. :-)

Unlike other template systems, Savant by default does not compile your templates into PHP; instead, it uses PHP itself as its template language so you don't need to learn a new markup system.

Und das erklär mal nem Designer, der grade so HTML gebacken kriegt

Ich finde Savant ist bei weitem das nutzloseste Template system, das ich bisher gesehen hab.

reg4rds
chojin

ich sag nur php-templates. Da gibt es nur Varaibeln, Schleifen und null Logik in den Templates. Damit kommt jeder Designer klar. :wink:

Was haltet Ihr eigentlich von Javascript Templates bei Ajax lastigen Spielen?
Sprich Templete wird einmal an den Browser geschickt, danach nur noch Daten und das Zusammenfügen und Rendering geschieht beim Spieler.

Original von Kampfhoernchen

Unlike other template systems, Savant by default does not compile your templates into PHP; instead, it uses PHP itself as its template language so you don't need to learn a new markup system.

Und das erklär mal nem Designer, der grade so HTML gebacken kriegt

Wieso soll ich so jemanden anstellen wollen? PHP Basics kann jeder Idiot in 2 Tagen lernen, wenn ein Designer das nicht hinbekommt, ist er einfach nicht qualifiziert.

Ich finde Savant absolut optimal.

Naja, jedem das seine, ich persönlich finde Savant auch nicht schlecht. Es wurde nur das Prinzip von ASP.Net kopiert.

Allerdings müsste es einfache Möglichkeiten zur Datenbindung geben.

Allerdings sehe ich dort ein Sicherheitsproblem, da meiner Meinung nach Templates nicht die Möglichkeit haben sollten andere Funktionen außer Ausgabe-Funktionen auszurufen.

Für reine Designer ist dieses Verfahren meiner Meinung nach nicht geeignet. Ich schließe mich Kampfhoernchen an. Allerdings gebe ich Chojin Recht: Dieses System würde ich nicht Template-System nennen ;-)

Original von TheUndeadable
Naja, jedem das seine, ich persönlich finde Savant auch nicht schlecht. Es wurde nur das Prinzip von ASP.Net kopiert.

Allerdings müsste es einfache Möglichkeiten zur Datenbindung geben.

Allerdings sehe ich dort ein Sicherheitsproblem, da meiner Meinung nach Templates nicht die Möglichkeit haben sollten andere Funktionen außer Ausgabe-Funktionen auszurufen.

Für reine Designer ist dieses Verfahren meiner Meinung nach nicht geeignet. Ich schließe mich Kampfhoernchen an. Allerdings gebe ich Chojin Recht: Dieses System würde ich nicht Template-System nennen ;-)

Ich glaube mit Kopieren hat das wenig zu tun. Er hat einen lightweight Ersatz fuer Smarty gesucht und ihn sich geschrieben. Ohne all den unnoetigen Overhead.

Sicherheit: Wer es - bei mir - schafft die Templates zu aendern, kann auch direkt die verarbeitenden Scripts aendern. Wenn man seinem Designer Zugriff gibt, aber ihm nicht vertraut ist das natuerlich ein anderes Problem. Aber nicht direkt ein technisches.

Also if, else, foreach und while sollte eigentlich noch jeder Designer hinbekommen. Ob der nun die Smarty interne Sprache lernt oder ein wenig php ist doch vollkommen egal. Lernen muss er es sowieso, nur mit HTML kommt er nirgends weit. Und wenn dein Designer "gerade so mit HTML zurecht kommt", ist er wohl absolut fehlbesetzt oder sollte auch nur Zugriff auf die CSS Dateien haben.

Imho ist das durchaus ein faehiges Template System.

Ich kenn die Engine nun nicht und weiss auch nicht wie das wirklich in den Templates drinsteht doch wenn man sein Script da eh direkt reinschreibt wiso muss man das Ding dann überhaupt verwenden?

Dann kann man sein HTML-Code auch gleich in die Scripts schreiben und dort per echo ausgeben lassen. Templates sind zur direkten Trennung zwischen PHP(oder anderen Sprachen) und HTML-Code gedacht. Das man ne klare Trennung hat und das Design mal eben ändern kann ohne die ganzen Scripts zu durchsuchen und umzustellen.


Und wo wir grade diskutieren aber welche Templatefunktionen nutzt Ihr eigentlich bzw. was müssten die Engines Eurer Meinung nach können?

Zu Savant ein Beispiel: http://www.phpsavant.com/yawiki/index.php?area=Savant2&page=StartExample

> Und wo wir grade diskutieren aber welche Templatefunktionen nutzt Ihr eigentlich bzw. was müssten die Engines Eurer Meinung nach können?

- Variableneinsetzung und formatieren dieser
- Dynamisches Aufrufen von Funktionen
- Einbinden von anderen Templates/Modulen (WebControls)
- Validierung von Eingaben aus anderen Modulen
- Ablaufstrukturen, wie if, while, for, foreach
- OOP-Strukturen sollten schnell eingeladen werden
- Übergabe der Variablen als Hashtables, Objektstrukturen, SQL-Queries oder Xml-Dateien
- Automatische Verarbeitung der Eingaben von Inputfeldern, so dass ich diese nicht von Hand füllen muss. Beispiel: Ich habe ein Eingabefeld und ein Submitbutton. Ich erwarte, dass ich ohne weiteren Code auf den Button klicken kann und die Seite sich neulädt, ohne dass der Inhalt des Eingabefeldes verschwunden ist.

Es geht nicht um die Trennung von PHP und HTML, sondern um die Trennung von Business Logic und Presentation Logic.

Eine Template Engine BRAUCHT nun einmal Kontrollstrukturen, Bedingungen und Schleifen und da reicht HTML einfach nicht. Und wieso soll man dann nicht das einfache PHP nutzen, was gut dokumentiert ist und was jeder kennt sondern noch einmal das Rad neu erfinden und eine Sprache entwickeln, womit man den Overhead erzeugt, dass diese dann noch zusaetzlich geparst werden muss.

Das ist mir auch klar.. und deswegen sollte ne Templateengine auch Kontrollstrukturen wie mindestens if/elseif/else und Schleifen kennen. Bloss Savant empfinde ich irgendwo nur als Semi-Engine. Ok es trennt das ganze zwar ein wenig doch nun im Script Variablen zu übergeben und dann in den Templates trotzdem mit PHP-Code rumzuschreiben finde ich als doppelt gemoppelt.. da kannst am Scriptende auch gleich ne "Template-Datei" laden und per eval durchspielen wo dann einfach die Variablen aus dem Script Verwendung finden. Auf die weise sparst dir sogar noch die Ressourcen fürs laden der Klasse und hast trotzdem ne Trennung.

Undeadable:
Zu deinen Vorschlägen was eine Engine können muss kann ich mich mit deinen automatischen Inputfeldern irgendwie nich anfreunden..
Was in Inputfeldern steht das sollte doch deutlich vom Script kontrolliert werden. Füllst nen Formular mit falschen Daten aus und schickst es ab.. das Script kontrolliert die Werte und merkt: "Postleitzahl ist ungültig". Das Formular muss wieder angezeigt werden aber das Postleitzahlenfeld bleibt erhalten weil die Engine die Inputs automatisch wieder auffüllt?
Oder wenn du nen Mehr-Seiten-Formular hast wo aber einige Felder den gleichen Namen haben. Dann ist auf Seite 2 plötzlich das Namensfeld für den Mädchenname deiner Mutter mit deinem Accountnamen gefüllt weil beide Felder "name" heissen.

Und was verstehst du unter der Validierung von Eingaben aus anderen Modulen?

Original von Mudder
Das ist mir auch klar.. und deswegen sollte ne Templateengine auch Kontrollstrukturen wie mindestens if/elseif/else und Schleifen kennen. Bloss Savant empfinde ich irgendwo nur als Semi-Engine. Ok es trennt das ganze zwar ein wenig doch nun im Script Variablen zu übergeben und dann in den Templates trotzdem mit PHP-Code rumzuschreiben finde ich als doppelt gemoppelt.. da kannst am Scriptende auch gleich ne "Template-Datei" laden und per eval durchspielen wo dann einfach die Variablen aus dem Script Verwendung finden. Auf die weise sparst dir sogar noch die Ressourcen fürs laden der Klasse und hast trotzdem ne Trennung.

Das Ressourcen sparen bezweifle ich, wenn du erst eine komplette Webseite evalusierst. Den gesamten Text zu parsen und dann im Speicher zu haben ist sicher aufwendiger....

Wieso sollst du denn eine extra Sprache definieren, wenn PHP genau den Zweck erfuellt? (und den Vorteil hat, dass die Tags vom Browser ignoriert werden, wenn man sich die Templates lokal anschaut)

Dann hast das falsch verstanden..
Du initiierst die Klasse und gibst ihr einige Variablen. Zum Seitenende sagst du der Klasse sie soll Template X verarbeiten (einmal durch eval() schicken und dann per echo ausgeben).

Stattdessen kannst auch gleich am Scriptende das Template manuell laden und durch eval jagen und ausgeben.. Die Variablen hast du aus dem Script also wiso erst ne Klasse laden und dem erstmal alle Variablen übergeben?

> das Script kontrolliert die Werte und merkt: "Postleitzahl ist ungültig".
Das meine ich mit Validierung.

Konkret sollte eine Sache folgendermaßen aussehen:

"HTML-blabla
@[inputfield:zipcode name="zipcode" validationfailed="Postleitzahl ist ungültig."]
@[inputfield:generic name="birthday" onValidate="CheckBirthday" style="...." class="...." validationfailed="Geburtstag ist ungültig"]
@[validationsummary type="list"]
@[inputfield:submit onClick="SubmitForm" validate="true" value="Abschicken"]
blabla"

Das obige erzeugt nun ein kleines Textfeld und validiert die Eingaben, ist die Eingabe falsch, so erscheint in der validationsummary der Text 'Postleitzahl ist ungültig'. Im zweiten Fall wird eine benutzerdefinierte Routine aufgerufen, die true oder false je nach Wert zurückgibt.

SubmitForm wird nur aufgerufen, wenn alle Validationhandler die Werte akzeptieren.

In letzter Zeit arbeite ich nur noch mit einem solchen System und es erleichtert einfach tierisch die Arbeit.

> Wieso sollst du denn eine extra Sprache definieren, wenn PHP genau den Zweck erfuellt?

Eine Benutzerdefinierte Sprache erscheint mir teilweise sinnvoller als die PHP-Sache selbst.

@[=name] ist schöner als
oder @[=name.Substring (2,3)] schöner als das PHP-Äquivalent

@[IF=="a"]true@[ELSE]false@[ENDIF] schöner als truefalse

Abgesehen davon erreicht man eine Plattformunabhängigkeit, da man bei einem Wechsel nur den Parser portieren muss.

Ok das ist dann aber schon mehr als ne Templateengine.. weil das ist ja ne Javascript-Funktion die kontrolliert ob beim Abschicken alles richtig ist.

Und da nehm ich lieber meine getform-Funktion womit ich die Werte prüfe nur weil das nen JS-Script kontrolliert hab verlass ich mich nicht darauf das die Werte auch OK sind.. sowas geht nur per Script.

> weil das ist ja ne Javascript-Funktion die kontrolliert ob beim Abschicken alles richtig ist.

Es wird automatisch Client-Script und Server-Script generiert, das die Eingaben überprüft.

Das ändert nix an der Tatsache das nen JS-Script die Werte überprüft. Wenns mit AJAX ist Ok dann kann die Engine das vorher prüfen aber wenn ich bedenke das ich meine templateengine auch mit meinem AJAX-Adminsystem verwende dann ist das sicher nicht sehr praktisch wenn mir ne Engine mal eben ein paar JS' in meine JS' reinkopiert.

Das JS hat mir bisher keine Probleme gemacht. Und du kannst ja auch das Client-Scripting abschalten, bzw durch dein eigenes System überschreiben.

Aber es scheint ja so zu sein, als ob du dein eigenes Framework auch schon hast. Wenn du dieses noch mit deiner Template-Engine als Plugin kombinierst, wäre es genial.

Sagen wirs mal so du hast mich auf ne Idee gebracht.. ich werd in meine neue Version eine ähnliche Funktion einbauen wobei ich die Werte direkt bei der Eingabe kontrolliere.

Wobei das formcheck-Element dann einfach durch ein onchange-Attribut ersetzt wird (das ist jetzt nen integer-Beispiel für ne Postleitzahl.

= 0 && v <= 99999 && String(v).length >= 5 && String(v).length <= 5) this.value = v; else this.value = '';"  />

Das wird aber nichts an der Tatsache ändern das ich die Werte trotzdem per Script kontrolliere und ggfl. ne Fehlermeldung auswerfe.

@Flint: Du meinst eine "Fat-Client-Lösung". Davon halte ich nicht viel, weil du damit eigendlich nur noch in JavaScript denken und programmieren musst. Jede Darstellung muss vordefiniert sein und für jede Form von ankommenden Daten müssen Verarbeituns- und Darstellungsroutinen beim Client vorhanden sein.

@TheUndeadable:
Eingabevalidierung per JavaScript ist normalerweise in keiner Template-Engine enthalten. Das macht auch kaum Sinn in der Core engin, da man ja auch alle Variabeln auf PHP-Seite testen könnte oder sich entscheiden kann, kein Javascript zu verwenden. Bei Smarty beispielsweise ist es aber ein leichtes, das was du machen willst, durch ein selbst geschriebenes Plugin zu erzeugen.

@Kallisti:
Auch wenn eine Template Engine dir einiges an Arbeit abnimmt, weil sie automatisch Funktionen wie foreach, if, else, etc. abarbeiten kann, sollte trotzdem eine klare Trennung zwischen der PHP Ebene und der Template Ebene herrschen. Deine Ansprüche an den Designer sind jedenfalls mehr als Kurzsichtig, wenn man sie auf professioneller Ebene sieht. Natürlich kann ein Student den du ein paar Bilder in dein Spiel einbauen lässt, auch halbwegs einen PHP Syntax verstehen. Aber in einer Agentur kann man nicht 3 Designer beschäfftigen, von denen jeweils einer PHP einer ASP und einer JAVA "designen" kann. Dafür gibt es standards und es ist eine allgemein bekannte Tatsache, das kreative Köpfe nicht Programmieren können müssen um gute Arbeit zu leisten.
Zur Laufzeit muss ich noch sagen, das zum Beispiel Smarty die Templates nur beim ersten mal mit Eval durchläuft. Danach erzeugt die Engine eine kompilierte Version des Templates, das ähnlich wie dein Favorit, HTML-Inhalte mit PHP-Tags umfasst.

reg4rds
chojin

Original von Mudder
Dann hast das falsch verstanden..
Du initiierst die Klasse und gibst ihr einige Variablen. Zum Seitenende sagst du der Klasse sie soll Template X verarbeiten (einmal durch eval() schicken und dann per echo ausgeben).

Stattdessen kannst auch gleich am Scriptende das Template manuell laden und durch eval jagen und ausgeben.. Die Variablen hast du aus dem Script also wiso erst ne Klasse laden und dem erstmal alle Variablen übergeben?

Ich denke ich habe das sehr wohl verstanden.

Weil dein Script beim eval erst die komplette Webseite in den Speicher (deines Scriptes) laden muss, waehrend es bei der Savant Variante ganz normal vom php Interpreter geparst wird (und daher von eacc./apc gecached).

chojin: Ich sehe aber eben keinen Vorteil darin eine aufgeblasene Variante zu nutzen, wenn das Resultat = meiner ist. Ein Designer der nichts von html versteht sollte eben nur CSS machen. Und ich denke schon, dass man ein paar Befehle in php voraussetzen kann. Es ist mit Sicherheit einfacher Leute zu finden, die php basics koennen als Smarty Erfahrung haben....

> Ich sehe aber eben keinen Vorteil darin eine aufgeblasene Variante zu nutzen, wenn das Resultat = meiner ist.

Warum PHP nutzen, wenn im Endeffekt sowieso Assembler rauskommt.....

> Es ist mit Sicherheit einfacher Leute zu finden, die php basics koennen als Smarty Erfahrung haben....

Es ist auch mit Sicherheit einfach mit PHP schnell aus Versehen Unsinn zu erzeugen. Durch die Verwendung von Smarty und anderen Template-System wird der Benutzer gezwungen nur die zur Verfügung stehenden Mittel zu verwenden und baut nicht mal nebenbei eine eigene Datenbankverbindung auf, um bestimmte Features zu erreichen (Stichwort: Defensive Programmierung).

Aber scheinbar hast du dich dafür entschieden den Designer PHP schreiben zu lassen. Ich würde es niemals tun. Es würde für mich reichen, wenn der Designer Html und eine sehr einfache Syntax kann. Die Möglichkeiten der Programmiersprache PHP möchte ich nicht im Design-Layer sehen.

EDIT:
Weiterhin sehe ich PHP nicht als ideale Programmiersprache für Templates an.
Als Beispiel sei eine einfache Konvertierung des Datums in ein bestimmtes Format.

In meiner Template-Engine würde ich @[=datevariable.MakeLongDate()] für ein ausführliches Datum pder @[=datevariable.MakeShortDate()] für ein kurzes Datum. Unter PHP darf man sich mit der obskuren C-Syntax des strftime Befehles herumärgern.

Dann musst du es aber wenigstens so sehen: Deine Methode ist ungeeignet wenn du in einem Portal verschiedene Designs verwenden willst bzw. diese durch den User geändert/erstellt werden können. Und du wirst doch auch sicher eingestehen das es komfortabler ist nen einfaches {Template-Tag} zu verwenden als den zu schreiben.

Und dann das was chojin mit smarty sagte.. das erste mal wirds dann per eval erstellt doch richtig designte cache-Dateien können dann ebenfalls wie bei savant einfach includet werden. Und die Ausgabekontrolle findet egal bei wem mittels den ob_-Funktionen statt und echo statt also auch hier ist Savant kein Außenseiter sondern verwendet die selben Methoden wie eigentlich alle Engines. (Savant2.php, Zeile: 1321). Und spätestens bei dem Punkt dürften die Performencevorsprünge dann wirklich nur am Servercache liegen.. oder eben das Savant keinerlei Templatetags beherscht die er parsen müsste. (Etwas mehr Geschwindigkeit dafür deutlich schlechterer Komfort)

Original von Mudder
Dann musst du es aber wenigstens so sehen: Deine Methode ist ungeeignet wenn du in einem Portal verschiedene Designs verwenden willst bzw. diese durch den User geändert/erstellt werden können.

Da stimme ich dir vollkommen zu. Fuer so etwas finde ich auch Smarty absolut in Ordnung. Aber wir sind hier in einem Browsergame Forum und ICH moechte das meine User nicht machen lassen. CSS Pakete reichen mir da vollkommen.

Original von Mudder

Und du wirst doch auch sicher eingestehen das es komfortabler ist nen einfaches {Template-Tag} zu verwenden als den zu schreiben.

Jein, hat auch vorteile. Naemlich dass der Browser die Tags ignoriert (bei einer Var macht das nichts, bei Schleifenkonstrukten schon eher), wenn man es direkt aufruft und man somit das cleane Design sieht. Hat auch Vorteile. :-)

Original von Mudder

Und dann das was chojin mit smarty sagte.. das erste mal wirds dann per eval erstellt doch richtig designte cache-Dateien können dann ebenfalls wie bei savant einfach includet werden. Und die Ausgabekontrolle findet egal bei wem mittels den ob_-Funktionen statt und echo statt also auch hier ist Savant kein Außenseiter sondern verwendet die selben Methoden wie eigentlich alle Engines. (Savant2.php, Zeile: 1321). Und spätestens bei dem Punkt dürften die Performencevorsprünge dann wirklich nur am Servercache liegen.. oder eben das Savant keinerlei Templatetags beherscht die er parsen müsste. (Etwas mehr Geschwindigkeit dafür deutlich schlechterer Komfort)

Ich sehe es - im Browsergamebereich - immer noch als grossen Vorteil direkt PHP in den Templates nutzen zu koennen und nicht noch etwas anderes lernen / verwenden zu muessen. Aber klar, das ist auch Geschmackssache. Ich verlange von niemandem Savant zu nutzen, nur es als moegliche Alternative zu akzeptieren.

Wollt auch mal was zu Templates los werden...
Grundsätzlich halte ich bei PHP nicht viel von Templates,
da es sich ja im Grunde schon um eine recht komplexe ^^ Templateengine handelt.
Also warum den overhead von Smarty und Co mitschleppen,
gerade bei Bgames, wo doch Performance so wichtig ist.
Ich spreche da allerdings aus meiner Sicht, wir sind nur 2 Leute
im Team und eigentlich Allrounder...
Den einzigen Sinn für PHP Templates sehe ich bei so Geschichten
wie Blogs oder Foren, wo man grundsätzlich komplett verschiedene
Designs anbieten möchte.
Bei Java sieht die Sache von vorn herein ganz anders aus,
da im Endeffekt nach der ersten Kompilierung die Seite eh als Servlet vorliegt.

Aber nochmal zu PHP.
Das hat sicher jeder schon mal gelesen und ist jedem sicher klar:

Während des Parsens einer Datei geht PHP den Text solange einfach durch, bis einer der speziellen Tags gefunden wird, der PHP mitteilt, dass ab nun mit der Interpretation des Textes als PHP Code zu beginnen ist. Der Parser führt nun den Code solange aus, bis er auf einen schließenden PHP Tag stößt, welcher dem Parser mitteilt, den Text ab hier wieder nur einfach durchzugehen. Das ist der Mechanismus der es erlaubt, PHP Code in HTML einzubinden: alles außerhalb der PHP Tags wird einfach alleine gelassen, während alles innerhalb dieser Tags als Code geparsed wird.

...
aber für die Ausgabe von großen Textblöcken ist der Ausstieg aus dem Parse-Modus generell effizienter, als den gesamten Text durch echo(), print(), etc. zu jagen.
Im Endeffekt bieten mir persönlich Templates einfach zu viele Nachteile in Sachen Bgame.
Meine Homepage nutzt ein selbst geschriebenes Templatesystem, aber nur so als Spielerei, weil da die Performance auch nicht so im Vordergrund steht, zusätzlich werden die Seiten gecached und nur dann neu kompiliert wenn irgendein neuer Inhalt dazu gekommen ist.

Hm. Also ich komiliere meine Templates (manuell) in PHP-Code. Da verliere die Performance von der Instanziierung einer einzigen Klasse, das eAcc die notwendigen includes ja cached.

Die Datumsformatierung ist Aufgabe der Datendarstellungsebene, nicht des Templatesystems. Der Designer gibt nur {DATUM} an, das wird dann in der richtigen Form hineingeparsed.

Naja, smarty ist nicht viel mehr als ein Kompiler, der seine eigene Sprache in php umwandelt und diese dann bei jedem Seitenaufruf aufruft. Also dürfte der Performancenachteil nicht allzugroß sein, insbesondere wenn man einen Op-Cache wie eacc oder apc hat.

Die smarty-Sprache hat den Vorteil, dass man nicht immer zwischen zu intepretierenden php-Code und html-Code wechseln muss, sondern ich einfach zwischendurch mittels {} eine Schleife, Bedingung oder so hinsetzen kann.

Außerdem kann der Designer ein Template auch mal in seinen Dreamweaver oder ähnliches reinhauen, bei php geht das nicht, weil man da laufend

was bitte? was für einen Dreamweaver hast du denn das der Probleme mit PHP in Template hat??

Ich nutze den Dreamweaver ausschliesslich...
Allerdings nicht in der Entwurfsansicht, sowas find ich echt pfui !
Wenn ich die Seite sehen will drück ich F12.
Und dann werden auch keine echos ausgegeben,
sondern der passende Inhalt !
Also so ne Argumente zählen für mich schon mal gar nicht,
gerade bei so ner diggen IDE wie dem Dreamweaver 8...

EDIT:

btw
www.massassi.com/php/articles/template_engines/
einige kennen den Artikel sicher schon...
Ich mein seine Lösung ist für mich auch nicht der Weisheit letzter Schluss,
aber ich kann mich mit seinen Ansichten recht gut identifizieren.

Kurze zusammenfassung:

Programmiercode:
Seitensteuerung, datenbankaufrufe, ablauflogik, berechnungen und funktionen. Alle wichtigen Ausgabeinformationen werden in einfachen Variabeln oder auch Arrays, multidimensionalen Arrays oder Objekten abgelegt.

Darstellungsebene (Template):
Ansicht der eigendlichen Programmausgabe. Darstellungsbefehle wie einfache Loops durch alle Inhalte eines Arrays, Datumsformatierung, Fliestext welcher mit Variabeln gefüllt wird, einfacher syntax für formulare, links, kontainer, ect (erweiterbar) Seitengrundgerüst.

Abläufe (beispiel Smarty):
Neuer Seitenaufruf:
Programmiercode + add(translate(template, save_code)) -> Ausgabe

Weiterer Seitenaufruf:
Programmiercode + add(translated_template) -> Ausgabe

Nach dem ersten aufrufen sollte das script nicht langsamer ablaufen als würde man irgendeine zweite PHP datei mit include() an die Programmlogik anfügen.

accelerator software
bringt hier die bekannten vorteile, ganz egal ob man smarty verwendet oder eben nicht. sprich smarty behindert die funktionsweise eines accelerators nicht, wenn man deren webseite trauen kann.

Dreamwaver (ich verwende ihn nichtmehr)
gibt einem die möglichkeit template-syntax festzulegen der dann hevorgehoben werden kann und die Darstellung sonst nicht verfälscht.

reg4rds
chojin

Smarty ist keine Templateengine mehr, das is schon ne Scriptsprache, die dann in PHP umcompiliert wird. Nur: Wenn man den Cache nicht haben will, verlierste extrem viel Leistung. Smarty is für CMS geeignet, für Browsergames aber die denkbar schlechteste Wahl.

Ab dem "Nur" ist dein Beitrag komplett falsch.
Das kompilieren der Templates passiert eigentlich immer, hat aber rein garnichts mit der cache funktion zu tun... diese speichert absolut fertige html seiten ab (was zum beispiel bei einer nicht dynamischen karte oder rangliste brauchbar ist).

Meinen Beitrage hast du gelesen? :roll:

reg4rds
chojin

Die normalen Cachedateien kann man eben nur bei "starren" Seiten verwenden, was im Grunde einer normalen HTML-Datei gleich kommt.

Eine Alternative wäre hierzu das die Cachedatei einen halbgeparseten Code enthält und nur Elemente welche sich immer ändern (wie z.B. ein Benutzername auf einer Highscoreliste) neu gesetzet werden, ohne die Liste zu verändern. Doch auch solche Cachedateien bringen eben nur was wenn man kaum dynamischen Inhalt hat, da die ebenfalls einmal geparset werden müssen und die Elemente dann einmal durchlaufen bzw. der Nutzen eben auch nur begrenzt vorhanden ist.

Für meine neue Engineversion weiss ich noch nicht ganz welches System ich verwende wobei ich aktuell dazu tendiere, dass ich neben der "normalen" Cachedatei eine Parse-Datei speichere wodurch ich mir das parsen des Templates sparen kann. Wobei man diese Parsedatei nun in 2 Versionen gestallten kann/sollte. Einmal komplett geparset mit allen Tags und einmal als "Sparversion" wo nur noch die Elemente drin gespeichert werden welche sich in der Cachedatei ändern sollen.

Die Variante ist damit sicher eine der schnellsten und flexibelsten Methoden wodurch man die Cachedatei sowohl zur Cacheausgabe (ob nun voll oder halb) aber auch als Parsecache verwenden kann, was bei der Rechenzeit mindestens 1-2 PCRE-Suchanfragen spart.
Bleibt nur das erstellen bzw. auch auslesen der Cachedatei(en), was man aber zumindest mit dem Auslesen so lösen kann das man den Cache wie die Parse-Elemente als PHP-Array in die Cachedatei schreibt und diese dann einfach nur includet.


Was meint Ihr dazu?

Original von Kampfhoernchen
Smarty ist keine Templateengine mehr, das is schon ne Scriptsprache, die dann in PHP umcompiliert wird. Nur: Wenn man den Cache nicht haben will, verlierste extrem viel Leistung. Smarty is für CMS geeignet, für Browsergames aber die denkbar schlechteste Wahl.

Naja reden wir hier vom Endgültigen cache oder vom compile cache von smarty

ein starer cache ist wirklich nicht zu gebrauchen aber smarty nutzt ja noch das zwichen kompilieren - also das erste mal wird die template komplet geparsed und dann kompiliert dann werden die vars etc. angewendet udn dann ausgeführt beim 2. mal werdne nur die vars angewendet udn ausgeführt und dadurhc das die kompilierten templates php scripte sidn werdne die ja noch von apc/eaccelerator gecachet

Also ich muss ehrlich sagen, ich hab bis jetzt noch nie Templates verwendet.
Da sich das Design auch nur dann ändert, wenn eine komplett neue Version kommt, pass ich den Code an das Design an.
Bzw. setz ihn einfach da ein, wo er hin soll.
Meistens arbeite ich aber nur mit includes, vor allem bei Menüs etc.

Gibts irgendwo einen Crashkurs für Templates?
Hört sich alles recht interessant an, und scheint doch recht sinnvoll zu sein.
Habs bis jetzt nie gebraucht oder verwendet, aber würds gerne mal versuchen.

Na ja, ist ja im Grunde ganz einfach, zum testen brauchst du einfach nur, na sagen wir mal test.php und template.html...
Wobei der einfachste Fall einer Engine im Kopf der test.php so aussehen könnte:

function load($file) {

$hdl = fopen($file, 'r');
$tpl = fread($hdl, filesize($file));
fclose($hdl);
return $tpl;
}

function swap($tar, $rep) {
global $tpl;
$tpl = str_replace($tar, $rep, $tpl);
return $tpl;
}
load(); lädt dann einfach das Template...
swap(); tauscht die Platzhalter im Template aus...
Tja und dann den bearbeiteten String einfach ausgeben.

Wie gesagt das sollte nicht für ernst genommen werden,
aber so funktionieren Templates ja im Grunde...

@MagicForrest:
Also für Smarty gibt es einen "Crashkurs" (smarty.php.net/crashcourse.php)
Eigendlich geht es hier nicht umbedingt um das Design an sich. Bei meinem Projekt ist das Design nur zu 9% von dem XHTML Output abhängig. Bei einem Projekt auf Basis von HTML 4.0 kann die Abhängigkeit zwischen HTML und Design aber durchaus bei 100% liegen, und dann lohnt sich ein Templatesystem allemal.

Ich benutze Smarty um schönen Output zu erstellen, ohne das mir in der Programmierung irgendwelche HTML-Tags um die Ohren fliegen.

reg4rds
chojin

Ich habe nun mal versucht das alles zu verstehen, was ein Template ist.

Nun kommt schon das erste Problem das ich nicht genau weiß was ein Skin und was ein Template ist.

{$titel}




{$menu}
{$inhalt}






Ist das jetzt ein Skin? und die Datei die verwaltet welche Inhalt angezeigt wird das Template?

So stelle ich mir das im Moment vor. Man hat die index-datei wo als erstes die config-datei und die die Datei, die verwaltet welcher Inhalt angezeigt wird eingefügt werden und dann kommt eine Funktion die schaut welches Skin der Benutzer hat.
Wenn man dann noch eine Datei anfertig wo man schön den Inhalt der Seiten verwalten kann, hat man dann ein CMS?