Smarty ja oder nein ?

So - jetzt ich als Laie.
Ich habe von beidem (Smarty und php) keine Ahnung, werde aber das Gefühl nicht los, dass ich da wie dort letztlich "rein muss". php allein oder php+Smarty?
Wenn dann php allein, das reicht mir.
Es ist nicht schwer, in eine Seite ein paar php-Zeilen reinzusetzen, wenn sie gut dokumentiert sind und das tun, was man erwartet.
Warum sollte ich auf ein System setzen, das nochmal wo draufgesetzt ist und letztlich die Sache verlangsamt? Es ist nicht mein Ziel, alle 2 Wochen das Design zu ändern, sondern meine Vorstellungen einmal umzusetzen und das Ding dann lange "unbeaufsichtigt" laufen zu lassen.

Ich mache mir gerade Gedanken über mein erstes Shop-Projekt, und bin entsprechend erschlagen von den (Un)Möglichkeiten. Und da wird es mir gehen wie den meisten, die sowas anfangen: _noch_ ein Dings obendrauf ist mir für den Anfang zuviel.

Es geht nicht darum ein "Ding" oben drauf zu setzen.
Eigentlich ist die Idee vielmehr, daß Du die verschiedenen Verantwortlichkeiten auslagerst.
Das bedeutet:
Du hast eine Schichte, die Datenbank macht, eine Schicht, die Darstellung macht, eine Schicht die die "Logik" beeinhaltet (und ggf. andere noch verwendet)
Smarty erleichter dir dann eben die Arbeit was die Darstellung incl. Caching angeht. Nen php script hinfrickeln kann jeder, aber wenn es darum geht etwsa noch Jahre weiter zu entwickeln und zu warten dann trennt sich die Spreu vom Weizen.

Hilfreich für die Entwicklung von Software (in PHP) könnte das hier sein:

https://www-128.ibm.com/developerworks/ ... signptrns/

https://www.phppatterns.com/docs/?idx=design

Oder wenn du für Deinen Shop shoppen möchtest: https://www.oreilly.de/catalog/phpdesignpatger/

Viel Erfolg!

So, bis jetzt hatte ich noch nie etwas mit Smarty zu tun, jetzt habe ich mich mal rasch eingelesen.

Und die Antwort ist klar - so ein Stuß.

Das Ding ist eine Templateengine von vielen.

Ein Zitat: https://de.wikipedia.org/wiki/Template_Engine

Die Masse von Template Engines ist enorm. Eigenentwicklungen sind an der Tagesordnung. XSLT ist für alle Template Engines eine Konkurrenz. Bei PHP ist Smarty weit verbreitet, hat aber die Eigenentwicklungen und andere Template Engines nicht vom Markt verdrängt.

Ich erledige das direkt mit Xslt - Template Engines sind offenbar der letzte Schrei - für jemanden, der 1995 steckengeblieben ist. Für jeden, der die Xml/Xsl - Entwicklung ab 1996 mitbekommen hat, sind solche Strukturen veraltet.

oldInternetUser hat geschrieben:Template Engines sind offenbar der letzte Schrei

Dieses Gefühl habe ich auch (obwohl ich auch keine Ahnung von Xslt habe, aber alles gute neue fängt mit X an - seit Jahren, scheint bewährt zu sein...)
php IST ein Frickelwerk, völlig klar, aber da muss man ohnehin durch, zumindest so halbwegs. In Wahrheit machen 90% der Leute die Standard-Installation und 9% frickeln noch irgendwas herum.
Das restliche Prozent frickelt soviel, dass ein Fork daraus wird.

Ich (Laie) wage zu bezweifeln, dass die Leute tatsächlich Smarty nutzen: Wer sich auskennt macht's besser, wer nicht: sowieso nicht.

everflux hat geschrieben:PHP selber macht doch gar kein Caching? Wäre mir zumindest neu.

Naja, das Smarty-Caching cacht ja auch nur den Smarty-Überhang, so dass Smarty sich das Kompilieren der Templates erspart. Dadurch werden die Templates performancemäßig erst PHP-Code vergleichbar.

Bei Smarty hast Du den Vorteil, daß verschachtelte Templates (hat man ja häufig, ich sag nur "header", "footer") direkt in ein einzelne Datei kompiliert werden. (was dann unter anderem besser für Caches und weniger Festplatten-Seeks ist, aber mehr Platz auf der Platte braucht)

Gutes Argument. Hängt natürlich vom Programmierer ab, ob er es in dieser Form nutzt, aber wenn er es macht, erspart er sich damit auf einfache Weise ein paar Millisekunden Ausführungszeit.

Wenn Du so argumentierst, dann wäre doch phpmailer statt der php mail() Funktion auch völliger Ballast und unnötig, ähnliches gilt für curl, Snoopy, Captcha Libraries, ADODB etc....

Halte ich auch wieder für etwas weit gegriffen. Es ist trivial, ein include('myTemplate.php') auszuführen. Es ist aber nicht trivial, komplexe Emails zu erzeugen oder Netzwerkzugriffe auszuführen. Ich halte es für sehr fraglich, dass der Einsatz von Smarty grundsätzlich sinnvoll ist. In bestimmten Fällen (z.B. wenn der Designer eh schon mit Smarty Erfahrungen gemacht hat), ist es sehr sinnvoll. In einigen Fällen ist es egal, ob Smarty oder nicht.

Der größte Vorteil von Smarty liegt IMHO in den Modifikatoren. Man kann kinderleicht ein Datum formatieren, Zeichenketten kürzen, Zeichen abzählen etc. ...aber alles, was darüber hinaus geht (in der Preisklasse: mehrspaltige Layouts aus Datenarrays erzeugen, oder komplexe Fallentscheidungen) endet immer bei komplexen Templates, die an Leserlichkeit und Wartbarkeit mit den equivalenten PHP-Skripten vergleichbar sind.

oldInternetUser hat geschrieben:Ich erledige das direkt mit Xslt - Template Engines sind offenbar der letzte Schrei - für jemanden, der 1995 steckengeblieben ist. Für jeden, der die Xml/Xsl - Entwicklung ab 1996 mitbekommen hat, sind solche Strukturen veraltet.

Transformierst Du serverseitig, oder verlässt Du Dich darauf, dass alle Besucher neuere Browser haben? Falls letzteres, was sagen die Suchmaschinen dazu?

SloMo hat geschrieben:Transformierst Du serverseitig, oder verlässt Du Dich darauf, dass alle Besucher neuere Browser haben? Falls letzteres, was sagen die Suchmaschinen dazu?

Das wird serverseitig erledigt, ausgeliefert wird nur reines Html, für Suchmaschinen also unproblematisch.

Da mixe ich nicht nur eine Xml-Quelle mit einer Xsl-Datei, sondern der Transformation werden zusätzlich diverse Xml-Fragmente und Parameter aus der Datenbank übergeben.

Eine zentrale Idee bei Xml/Xsl ist, daß ich nicht einen eigenen, neuen Parser schreiben und einen eigenen, Non-Xml-Dialekt entwickeln bzw. lernen muß, wie dies bei Smarty offenbar der Fall ist.

Der größte Vorteil von Smarty liegt IMHO in den Modifikatoren. Man kann kinderleicht ein Datum formatieren, Zeichenketten kürzen, Zeichen abzählen

Das kann ich natürlich alles in der NET-Programmiersprache selbst erledigen. Das, was ich so auf die Schnelle über Smarty gelesen habe, erinnert mich an die Zeiten von Ini-Dateien - bei einem Update bricht alles zusammen.

Ahh, .net - das erklärt wieso Du so XML geil bist >:->
Ich vertrete die Meinung, daß man XML zum Datenaustausch verwenden sollte, jedoch bei internern Sachen XML völliger Overkill ist. Aber ich glaube das gibt schon wieder genug Stoff für einen anderen Thread.

@Slomo
Zum Cachen von Smarty: Du kannst bei Smarty die gesamte Ausgabe cachen, ich bin nicht sicher, ob Du das meintest/weißt. Smarty hat nämlich eigentlich zwei Caches, einmal für die compilierten Templates, und einmal nen "richtigen" Cache, bei dem die generierten Seiten gecacht werden.
Damit spart man sich quasi den gesamten Prozess der Seitengenerierung, und bekommt enorme Geschwindigkeitsvorteile!
Selbst bei sehr dynamicshen Angelegenheiten wie einem Forum hat man ja doch ein höhere Lese-zu-Schreib-verhältnis und bekommt damit dann eine deutliche Entlastung vom Server.
Damit relativiert sich sehr stark auch das Argument von @edvsb, daß "immer alles von der Datenbank abgerufen werden muß, ob man es braucht oder nicht".

Zu dem phpmail vs. mail(): Also mir machts keinen Spaß etwas, das es bereits gibt und das getestet ist quasi nochmal zu erfinden, um html-Mails mit eingebetteten Grafiken per php verschicken zu können.
Da spielt keine Rolle, ob ich es kann, sonden ob es nicht Dinge gibt, die ich in der gesparten Zeit machen kann, die es bisher noch nicht gibt.

everflux hat geschrieben:@Slomo
Zum Cachen von Smarty: Du kannst bei Smarty die gesamte Ausgabe cachen, ich bin nicht sicher, ob Du das meintest/weißt. Smarty hat nämlich eigentlich zwei Caches, einmal für die compilierten Templates, und einmal nen "richtigen" Cache, bei dem die generierten Seiten gecacht werden.
Damit spart man sich quasi den gesamten Prozess der Seitengenerierung, und bekommt enorme Geschwindigkeitsvorteile!
Selbst bei sehr dynamicshen Angelegenheiten wie einem Forum hat man ja doch ein höhere Lese-zu-Schreib-verhältnis und bekommt damit dann eine deutliche Entlastung vom Server.

Klingt so gut, dass ich es direkt mal ausprobieren werde. Dadurch, dass man eine cache_id angeben kann, kann man auch benutzerbezogen cachen.

oldInternetUser hat geschrieben:

Der größte Vorteil von Smarty liegt IMHO in den Modifikatoren. Man kann kinderleicht ein Datum formatieren, Zeichenketten kürzen, Zeichen abzählen

Das kann ich natürlich alles in der NET-Programmiersprache selbst erledigen.

Womit Du Darstellung und Code vermischt... der Designer/Entwickler sollte im Template entscheiden, welches Datumsformat in dieser Sprache das übliche und in diesem Design das optisch ansprechendste ist. Wenn man das Datum im Code auf die Darstellung vorbereitet, ist die Trennung futsch.

everflux hat geschrieben:Ahh, .net - das erklärt wieso Du so XML geil bist >:->
Ich vertrete die Meinung, daß man XML zum Datenaustausch verwenden sollte, jedoch bei internern Sachen XML völliger Overkill ist.

Das sind Daten, die als statische Html-Dateien vorliegen, aus der Datenbank kommen oder nutzerspezifisch sind - die werden mit Xsl zu Html transferiert. Ob ich die Daten aus der Datenbank im Xml-Format oder als doppelten Array abrufe, ist Jacke wie Hose.

SloMo hat geschrieben:Womit Du Darstellung und Code vermischt... der Designer/Entwickler sollte im Template entscheiden, welches Datumsformat in dieser Sprache das übliche und in diesem Design das optisch ansprechendste ist. Wenn man das Datum im Code auf die Darstellung vorbereitet, ist die Trennung futsch.

Aber doch nicht so: Natürlich wird das Datumsformat nur im Template festgelegt. Man definiert sich dann ein Xsl-Erweiterungsobjekt in einer NET-Sprache, übergibt das der Transformation, die Transformation nimmt den Datumswert aus der Datenbank und das Format aus dem Template - und schon hat man das gewünschte Ergebnis.

Hm, wie siehts inzw. aus mit .NET <-> Apache ? Die meisten haben ja Apache als WebServer und nicht IIS..

oldInternetUser hat geschrieben:Aber doch nicht so: Natürlich wird das Datumsformat nur im Template festgelegt. Man definiert sich dann ein Xsl-Erweiterungsobjekt in einer NET-Sprache, übergibt das der Transformation, die Transformation nimmt den Datumswert aus der Datenbank und das Format aus dem Template - und schon hat man das gewünschte Ergebnis.

Das entspricht einem selbst geschriebenen Modifikator in Smarty.

@Slomo
Poste doch mal Deine Erfahrungen wenn Du es ausprobiert hast, das würde mich sehr interessieren

Noch eine Ergänzung zum Datumsformat: Eigentlich möchte man ja, daß das Datum lokalisiert formatiert wird, genauso wie andere Ausgaben. Smarty ist dafür vielleicht nicht ganz der richtige Ort, so vom Gefühl her.
Gibt es da irgendeine best-pratice für PHP und Lokalisierung? Ich hab mich damit zwar mal kurz gedanklich beschäftigt, aber mangels Anforderung bisher nie umsetzen müssen/wollen. Ich bin da aber für Infos und Tipps sehr dankbar, sollte jemand dazu eine Idee haben. Danke schonmal.

Airport1 hat geschrieben:Hm, wie siehts inzw. aus mit .NET <-> Apache ? Die meisten haben ja Apache als WebServer und nicht IIS..

Keine Ahnung, ich nutze das auf eigenen IIS-Servern.

Theoretisch gibt es Mono, Erfahrungen habe ich damit keine, irgendwie finde ich es auch drollig, ein Microsoft-Produkt per OpenSource nachzubauen. Dann lieber gleich das Original.

Mit NET.2 hat die Xsl-Verarbeitung einen riesigen Sprung gemacht, da der Xsl-Code intern beim Erstaufruf als ein ganzer Stapel von Klassen kompiliert wird und so extrem performant ist.

Allgemein zur Diskussion: Wenn es einen Aufsatz auf eine Sprache gibt, dann sollte im Ergebnis richtiger Bytecode erzeugt werden, um das Parsen zur Laufzeit zu streichen. Ansonsten wirkt Smarty für mich eher wie ein Projektverwaltungstool.

SloMo hat geschrieben:Das entspricht einem selbst geschriebenen Modifikator in Smarty.

Muß man da selbst per Regex parsen oder wird das erledigt? In NET ist das ein Aufruf der Form

ergebnis = DateTime.ParseExact(dT_Quelle, Array von Formatkürzeln[bsp. yyyy-MM-dd], Kultur [en-US, de-DE], Optionen)

die Formatkürzel können bsp. im Template definiert werden, die Kultur wird aus den Browsereinstellungen ausgelesen und dem aktuellen Thread zugeordnet.