Soll das Zend Framework in den Shop implementiert werden?

Hallo,

habt Ihr schon diesen Blogpost gesehen?
http://www.oxid-esales.com/de/news/blog/zend-framework-and-oxid-eshop

Wir denken darüber nach, das Zend Framework im OXID eShop zu benutzen. Im Blog hat Erik mal ein paar Vor- und Nachteile zusammengeschrieben - die Entscheidung steht noch immer aus.

OXID würde dazu gern Eure Meinung wissen. Falls Ihr mitdiskutieren wollt, könnt Ihr das gern hier in Deutsch, im Englischen Forenpost oder auch in der Mailingliste tun.

Gruß

wow Marco - der Thread ist ja Deutsch, dann antworte ich doch mal hier - hab eben gerade Andreas Mail gelesen und muß sagen “Danke Andreas”.
Bei allem technischen “Unverständnis” meinerseits aus dieser Mail lese ich aber sehr deutlich heraus, daß man auch an DEN ENDVERBRAUCHER denken soll und das sind eben WIR - wir, die momentan noch immer am hadern sind, was Umstellung Version 3 auf 4 kostet und denen dann mit Sicherheit - wie ja Andreas ganz deutlich schreibt - erneut Kosten aufgebürdet werden.
Ich halte daher den Vorschlag von Andreas für sehr gut für “Testzwecke” mit der CE zu starten.

[QUOTE=Marco Steinhäuser;13183]Hallo,

habt Ihr schon diesen Blogpost gesehen?
http://www.oxid-esales.com/de/news/blog/zend-framework-and-oxid-eshop

Wir denken darüber nach, das Zend Framework im OXID eShop zu benutzen. Im Blog hat Erik mal ein paar Vor- und Nachteile zusammengeschrieben - die Entscheidung steht noch immer aus.

OXID würde dazu gern Eure Meinung wissen. Falls Ihr mitdiskutieren wollt, könnt Ihr das gern hier in Deutsch, im Englischen Forenpost oder auch in der Mailingliste tun.

Gruß[/QUOTE]
Ich jedenfalls bin nicht dafür.

Das Zend Framework habe ich bei Magento [B]erlitten[/B]…

Im Gegensatz zu dem angenehm flachen OXID-Modell (wo man max. 1 Hierarchie-Stufe im Verzeichnisbaum navigieren muss, um im Core was anzupassen oder nachzulesen, werden das im Zend-Framework (zumindest in der Magento-Variante) schon mal 10 Ebenen… (Aua, armer Mausfinger…)

[B]Man sollte schon mal fragen, welcher OXID-Entwickler (außerhalb der OXID AG) das Zend Framework kennt oder gar nutzt…[/B]

Eines ist für mich ziemlich klar:

der Einsatz des Zend-Frameworks erzwingt eine erneute, [B]sehr steile[/B] Lernkurve, und macht das vorhandene Know-How obsolet…

OXID wird deswegen vermutlich viele externe Entwickler verlieren.

(Und endgültig auch die wagemutigen Shop-Betreiber, die sich, obwohl das jetzige OXID Objekt-Modell schon sehr viel komplexer ist, als der xtc-Spaghetti-Code, da immer noch mit eigenen Anpassungen dran trauen.)

Es gibt m.E. vergleichsweise wenige Magento-Entwickler, weil die SW so komplex ist.

Die, die es gibt, sind größere Agenturen, die sich SMBs i.d.R. nicht mehr leisten können.

[B]Mein Fazit: [/B]

die Komplexifizierung von OXID durch das Zend-Framework halte ich daher für eher kontraproduktiv.

Meine Lust, mit OXID zu arbeiten, würde sich vermutlich mindestens so schnell verflüchtigen, wie das bei Magento der Fall war.

Ein auf dem Zend-Framework basierendes OXID würde zudem sicher 2 Jahre benötigen, bevor es einigermaßen stabil und performant läuft.

Auch die vermeintlich bessere Integrierbarkeit halte ich für nicht gegeben.

Selbst wenn z.B das Shop-System und eine WaWi dasselbe Framework verwenden heißt das ja noch lange nicht, dass die damit automatisch zusammenspielen…

Man sollte lieber mehr standardisierte Schnittstellen schaffen, dann ist es egal, wie das jeweils drinnen aussieht.

Und:

Die Informatiker-Regeln 1 bis 3 lauten:

[B]Never touch a running System![/B]

Ich würd ja vorschlagen nur manche komponenten von zend zu nutzen, um intern ein paar sachen rundzuerneuern, wie zb Zend_PDF und sich auch mal gedanken über eine neue templating engine zu machen. Smarty kann man ja als “fallback” immer noch weiter nutzen und man bietet einfach eine alternative mit an, die man dann in hauptversion (d.h. oxid 5 oder 6) zum standard macht. oxid hat leider zuviele “altlasten” die in der freien wildbahn benutzt werden als das man sowas von einer version auf die andre einführen könnte.

grade bei adodb und smarty wäre ein austausch wichtig, aber kritisch.

Generell sehe ich auch ein Problem mit den getunten Oxid-Shops. Die dann anfallenden Änderungen halte ich für fast unzumutbar.
Wenn, dann denke ich, dass Schritt für Schritt nach dem ‘alles kann, nichts muss’ Prinzip das ZF integriert werden sollte.

@csmon:
Ja, Smarty muss weg!
Ein (gefühltes) viertel besteht aus assigns. Das kann man ohne Smarty viel eleganter machen.

@avanger:
Ich finde nicht, dass man ZF mit Magento gleichsetzen kann. Ich habe Magento mit ähnlichen Erfolg als [B]nichtfürmarkus[/B] eingeordnet.

…mal wieder der beliebte Vergleich mit den Autos…
Wenn man bisher nur Ferrari kennt, kann man sich auch nicht vorstellen mit einen Auto im Gelände zu fahren.

IMHO haben die von Magento einiges verkompliziert.
Keine Ahnung ob die den damaligen Trend möglichst viel triviales zu abstrahieren gefolgt sind, oder ob die third-party Entwickler und somit Mitbewerber abschrecken wollten. Denke mir aber, dies ist einfach so passiert und nicht gewollt.

Dieser Trend ist [B]sogar im Java[/B] Bereich rückläufig.

Hier ein Link zur Verzeichnisstrukturvon ZF welche mit den command-line-tool generiert wird. Selbst Zend hat hier scheinbar Handlungsbedarf gesehen. :wink:
Es kommt nach dieser Vorgehensweise maximal eine Ebene (für Module) tiefer hinzu… wenn ich das richtig verstanden habe. ZF ist auch Neuland für mich.

Also wenn sich [B]alle[/B] an diese Struktur halten und ihre Applikation als Modul anbieten, dann sollte eine integration einer anderen Applikation, die ebenfalls als Modul umgesetzt ist Problemlos sein. Dies kann zB. ein CMS sein.
Ok. derzeit sind die meisten auf ZF basierenden Applikationen nicht nach dieser Struktur… aber ich glaube in Zukunft sieht das ganz anders aus.
[I]Ich stelle mir ganz naiv vor, dass sich demnächst eine Grundapp durchsetzt, welche sich fast ausschließlich um ZendAuth und ZendAcl (Authentifikation und Accesslist) kümmert. Den Rest wird es dann als Modul geben.
Also ich habe dann ein Modul ‘Shop’, welches sich nur um Preise, Lager usw. kümmert.
Dann habe ich ein Modul ‘CMS’ welches sich um inhalte kümmert. Hier greift auch der Shop drauf zu für zB. Produktbeschreibung. Dies kann uU. mit einen wrapper oä. passieren, damit der Shop mit einen beliebigen CMS-Modul kommunizieren kann.
Es währe dann eine Art CMS-Baukasten, welcher die unterschiedlichsten Entwicklungen vereinen kann und auch individuell leicht erweiterbar ist.

… aber das ist noch ferne Zukunft und vielleicht irre ich mich ja.
Denke mir aber, wenn ein Paar Firmen so anfangen (und die Rahmenbedingungen absprechen), müssen andere Firmen nachziehen, um konkurrenzfähig zu bleiben.
Wahrscheinlich wird aber vorher CSS3 von allen Browsern [B]gleich[/B] unterstützt.:D[/I]
Ok, das macht die Sache im globalen komplexer, aber das was man anpassen will ist ein kleinerer Bereich. Wenn ich ein HTML-Formular schreibe brauche ich auch nicht zu wissen, wie das TCP/IP-Protokoll oder ein Browser im Detail funktioniert.

Der größte Vorteil von ZF ist meiner Meinung die Dokumentation… Währe natürlich toll, wenn sich die Entwickler dann auch nach dieser richten würden, damit man den Code besser nachvollziehen kann.

Was habt ihr nur alle gegen Smarty???

Ich komme prima damit zu Recht, und habe mir damit sowohl xtc als auch OXID das Templating für meinen Bedarf ziemlich umgebaut.

(Das soll mal einer bei Magento versuchen…)

Und ich kann darüber auch ziemlich massive Shop-Erweiterungen realisieren, ohne in die eigentliche Shop-Software eingreifen zu müssen.

Für Entwickler wie mich ein Segen, da man die Installation beim Kunden ohne Bastelei durch Kopieren von Dateien erledigen kann.

Und die Smarty-Nutzung in OXID reizt Smarty ziemlich aus.

(Das einzige, was mich bei Smarty/OXID ein wenig stört ist diese blöde Doppel-Klammer “[{}]”.

Finde ich absolut unleserlich, und man muss mehr tippen (und immer noch “Alt Gr” dazu)…

Wozu soll die eigentlich gut sein?)

Was aber ist die Alternative zu Smarty?

Also wenn sich alle an diese Struktur halten und ihre Applikation als Modul anbieten, dann sollte eine integration einer anderen Applikation, die ebenfalls als Modul umgesetzt ist Problemlos sein. Dies kann zB. ein CMS sein.
Ok. derzeit sind die meisten auf ZF basierenden Applikationen nicht nach dieser Struktur… aber ich glaube in Zukunft sieht das ganz anders aus.Wahrscheinlich wird aber vorher CSS3 von allen Browsern gleich unterstützt.:smiley:
…und HTML5 ist standardisiert… (D.h., wir reden so von ca. 2020+)

Aber bis dahin wird sicher noch die eine oder andere Sau durchs Entwicklerdorf getrieben…

Es gab im Laufe der EDV-Geschichte ja schon viele tolle Ideen, die alle Probleme lösen sollten.

Von den meisten kennt man nicht mal mehr den Namen.

Und dass man sich auf ein Framework einigen wird, ist auch eher unwahrscheinlich.

Schöne Utopie, aber erher praxisfremd.

.NET, Swing usw. stehen bei den Desktop-basierten Anwendungen auch gegeneinander, und haben ihre “follower”, die sich die Köppe darüber einschlagen, welches Framework nun das einzig wahre ist…

Was habt ihr nur alle gegen Smarty???

Weils ausser abstraktion für designer kaum vorteile bringt. das einzige wo ich das ganz vorteilhaft gefunden hab, war in foreach schleifen, sonst ist aber das meiste absolut unnötig schwer und vieles erfordert dann eben auch eingriff in die view klassen.

ausserdem ist die handhabung im vergleich zu reinem php unnötig schwer, allein schon das angesprochene assign:


<?php
$var = 'val';
?>

Smarty:


{ assign var="var" val="val" }

Smarty selbst “kompiliert” sich ja schon runter zu php, warum nicht direkt php geben? Eine simple rein auf PHP basierende template engine wäre schon besser als Smarty. Vor allem flexibler und wartbarer. Es stört einen für jeden mist einen modifier schreiben zu müssen oder ein smarty plugin.

Smarty schränkt per design schon extrem ein. Ist ja auch klar, smarty ist neben der normalen Template fähigkeiten eine abstraktion damit designer nicht echtes php nutzen können / müssen und wird auch teils so eingesetzt.

Dann gibts halt simples, wie ein Zahlenformatierungen was smarty nicht out-of-the-box beherrscht. Nein, entweder muss ich für so eine allgemeine aufgabe - die nativ mit php in einer einzigen codezeile zu erledigen ist - ein plugin downloaden oder selbst eins schreiben (was weit mehr als eine einzige zeile code ist).

Ja ich kann PHP code in smarty nutzen, mit den {php} tags, aber wenn man sowas ständig nutzen muss, wirklich, das sollte einem dann schon zu denken geben.

Zudem ist es einsteigerunfreundlich, weil einsteiger meist schon PHP halbwegs beherrschen und für den smarty kram sich erstmal smarty anschauen können bevor sie simple aufgaben erledigen können.

Zu guter letzt ist da noch der “Error in Smarty.class.php on line 1092”. Ehrlich, wenn ich den schon seh… :wink:

Dummerweise ist Smarty nun schon länger in OXID drin und wie Martina schon sagt, muss man das den leuten nicht aufbürden und Smarty müsste mindestens als “fallback” dableiben um Kompabilität zu wahren.

Also ich finde Smarty eigentlich auch richtig gut - wüsste spontan nicht warum man das wechseln sollte. So hat man wenigstens für das Design eine “fast” normale HTML Seite zu formatieren. Finde ich um einiges eleganter als das ganze mit php echo zu machen.

Gerade im “foreach”-Bereich gibt es gegenüber PHP-Code einige Vorteile:

$smarty.foreach.xxxx.iteration,$smarty.foreach.xxxx.first,$smarty.foreach.xxxx.last,cycle uvm.

Wenn man da mit PHP arbeitet sieht das ganze sehr schnell sehr unübersichtlich aus.

Für das reine Templating verwende ich in Smarty keinen {PHP}-Tag, sondern nur, um Shop-Erweiterungen zu integrieren.

Ich erstelle auch Wordpress-Templates, die ja reiner PHP-/HTML-Code sind.

Und ich mag das einfach nicht.

(Ganz zu schweigen von dem PHP-Müll, den Magento einem da zumutet.)

[B]Smarty rulez![/B]

“{$variable}” zur Ausgabe einer Variablen finde ich (auch als Entwickler) einfach übersichtlicher und besser lesbar als “<? echo $variable;>”.

Und bei komplexeren Konstrukten wie Loops, Bedingungen usw. sieht das gleich noch viel abartiger aus.

Aber das ist sicher ein Thema über das man trefflich unendlich streiten kann.

[B]Wäre mal interessant zu hören, was Nicht-Entwickler dazu meinen…[/B]

Smarty-Templates oder PHP-Templates?

[QUOTE=avenger;13217]

[B]Wäre mal interessant zu hören, was Nicht-Entwickler dazu meinen…[/B]

Smarty-Templates oder PHP-Templates?[/QUOTE]

Wenn mir jemand mal genau sagen könnte welche vor oder nachteile denn Shopbetreiber dadurch haben? Für mich z.B. ist diese ganze Diskussion “Böhmsche Dörfer” :smiley:

Nachteile:

  • Sämtliche Module müssen komplett portiert werden

  • Mehraufwand für Partner

  • Zusätzliche Kosten für Shopbetreiber wegen Modul-Updates

  • Mehraufwand für Shopbetreiber die den Shop selbst erweitern

  • Meines Erachtens nach zu wenig nutzen

und wenn das seitens oxid unterstützt würde, wäre support für alte version wieder hinfällig weil man ja aus kostensicht nicht 2 verschiedene systeme warten will/kann

alles in allem - wir - der endkunde - kann wieder zahlen zahlen zahlen

[QUOTE=avenger;13217][B]Wäre mal interessant zu hören, was Nicht-Entwickler dazu meinen…[/B]

Smarty-Templates oder PHP-Templates?[/QUOTE]

Tjo, was soll man als Nicht-Entwickler zu einem Thema sagen, wo man weder die Details der einen, noch der anderen Variante kennt.

Mir würde es reichen wenn es insgesamt möglichst [B]einfach[/B] bzw. überschaubar bleibt. Den jetzigen Code kann ich meistens nachvollziehen und kleinere Änderungen selbst machen. Das ist für mich im Moment super.

[B]Egal was gemacht wird, die .tpl Dateien betrifft das nicht, oder? [/B]
Dort ist es mir besonderst wichtig kleine Änderungen mit meinem Programiersprachengrundwissen selbst machen zu können.

CYA
Firefax

P.S.: Ich habe auch keine Zeit (und Lust) mich als Händler in irgendeine Zend-Programmierung einzuarbeiten. Da sehe ich die Aufgaben eines Händlers als etwas andere an als zu programmieren. Auf der anderen Seite steht mir im Moment auch nicht genug Geld zur Verfügung einen Zend-Progger zu beschäftigen, der ja die Kosten dramatisch in die höhe treiben würde.

Da wir uns ja alle wegen der Templateengine einig sind…
… zumindestens scheint niemand XSL zu wollen… :smiley:
habe ich mal im Smarty-Forum geschaut, ob das Problem mit den Assigns in bearbeitung ist.

Also wenn Oxid so früh wie möglich auf Smarty3 migriert, dann überwiegen auch für mich die Smarty Vorteile.

Also ich sehe das so wie einige Leute vorher auch schon.

Smarty halte ich für das Mittel der Wahl. Einfach, unompliziert und erprobt. Ein Update auf die neuere Smarty Engine würde ich auch begrüßen.

ZendFramework? Ich wüsste nicht wofür. Wir haben hier mit dem Shopsystem ein ganz klar skizziertes Anwendungsfeld. Alle wichtigen Sachen (DB-Handling, Session Handling, etc.) sind vorhanden und seit Jahren im Betrieb. Warum soll man hier was ändern?

ZendFramework halte ich eher für Firmen interessant, die X verschiedene PHP Anwendungen betreiben und nicht immer das Rad neu erfinden wollen.

Ich denke wir sollten beim aktuellen “OXID-Framework” bleiben.

Zend hat ja eigentlich nix mit smarty zu tun. das würde ich wenn dann nur intern einsetzen und wenn dann wären im idealfall “nur” die module betroffen. Wenn eine neuere Version von Smarty in arbeit ist die die alten wirklich störenden macken beseitigt, kann wegen mir auch smarty drinbleiben. Nur im moment ists einfach hinderlich, und oxid befindet sich damit zudem in einer art “Vendor Lock-in”. Aufgrund des hohen portierungsaufwands für die templates wird man quasi nie von smarty wegkommen und immer in irgendeiner form auf die template engine angewiesen sein. Man kann ja sogar kaum die eckigen klammern entfernen, weil die templates syntaktisch alle so aufgebaut sind.

Nichtsdestotrotz würde ich trotzdem eine zu frühe migration zu smarty 3 nicht sonderlich gut finden, da früher versionen eben oft noch eine Menge fehler enthalten. Zudem ists ja auch nicht offiziell draussen.

Smarty halte ich für das Mittel der Wahl. Einfach, unompliziert und erprobt. Ein Update auf die neuere Smarty Engine würde ich auch begrüßen.

Das ding ist, ich finds für einsteiger einfach überkompliziert. als ich das erste mal mit oxid in berührung gekommen bin, war smarty auch neuland für mich, ich konnte nur “reines” PHP und war auch nur reinen php engines vertraut. Anstatt sofort arbeiten zu können musste ich mich also erstmal in smarty einlesen, was ich als sehr sehr umständlich und hinderlich empfand.

natürlich sehe ich auch ein das das keinem shopbetreiber aufgebürdet werden kann jetzt auf was ganz neues umzusteigen.

Deshalb würde ich vielleicht vorschlagen, die möglichkeit zu schaffen eine eigene template engine nutzen zu können. OXID benutzt ja schon an vielen stellen Engine-unabhängige methoden, sodass man eigentlich nur die entsprechenden schnittstellen schaffen müsste.

Vorteile:

[ul]
[li] für shopbetreiber ändert sich garnichts[/li][li] leute die eigene engines oder alternativen nutzen wollen können das tun[/li][/ul]

Nachteile:

[ul]
[li] Module müssten entweder jedes mal angepasst werden oder…[/li][li] … die engine müsste je template bzw je view klasse beliebig sein, sodass manche mit smarty gerendert werden, und andere mit einer anderen.[/li][/ul]

ZendFramework? Ich wüsste nicht wofür. Wir haben hier mit dem Shopsystem ein ganz klar skizziertes Anwendungsfeld. Alle wichtigen Sachen (DB-Handling, Session Handling, etc.) sind vorhanden und seit Jahren im Betrieb. Warum soll man hier was ändern?

Weil zb AdoDB (zumindest so wies im OXID shop ausgeliefert wird) hoffnungslos veraltet ist und mit anderen adaptern wesentlich höhere flexibilität in sachen alternative DBMS (Oracle etc.) geschaffen werden könnte. Alternative DBMS sind mit AdoDB natürlich auch kein problem, aber die struktur und architektur zeigt halt schon ihr alter. Für diesen zweck müssten die datenbankabfragen natürlich auch flexibilisiert werden, aber da gibts heute auch schon sehr flexible ORM lösungen, siehe zb Propel welches datenbankunabhängig arbeitet. (ist kein vorschlag, nur ein beispiel)

Ich weiss nicht wie modern und gut neuere AdoDB versionen sind, aber die die aktuell dabei ist ist nicht grade das gelbe vom Ei.

Inwiefern Zend_PDF eine gute alternative zu fpdf wäre, kann ich nicht sagen, aber umschauen könnte man sich ja mal.

Natürlich ist adodb seit jahren in betrieb, aber je länger diverse sachen im betrieb bleiben desto schwerer werden sie zu warten, und wartbarkeit ist grade im eCommerce Sektor meiner Meinung nach ein Killer-Kriterium. Die Shopbetreiber kostet es ja auch geld, wenn für vergleichsweise simple anpassungen Stunden berechnet werden müssen, weil die Komponente die es betrifft so schwer wartbar ist.

ZendFramework? Ich wüsste nicht wofür. Wir haben hier mit dem Shopsystem ein ganz klar skizziertes Anwendungsfeld.

So ähnlich denke ich auch. Viele allgemeine Komponenten wären einfach unnötig dabei, dagegen halte ich es aber für sinnvoll wirklich einzelne fragmente des ZF zu nutzen, aber nur da wo es wirklich sinn macht.

Ich kann einfach nicht nachvollziehen was für einen Entwickler an Smarty umständlich oder schwierig zu erlernen ist?

Das ist doch im Prinzip reines HTML wo ich mir mit ein paar Funktionen und Variablen dynamischen Content reinknallen kann. Super simpel und eigentlich müsste das für jeden, der sich mit PHP und HTML auskennt auch weitgehend selbsterklärend sein.

Dagegen ist es doch ein totaler Murks, HTML Ausgaben in PHP Dateien zu realisieren. Wenn ich mir beispielsweise Wordpress Templates anschaue bekomme ich jedes Mal das Grauen. Ständig irgendwelche echo sonstwas Ausgaben.

Aber mal um bei dem Thema Template Engine zu bleiben, was ja sicherlich durch die Entscheidung Zend oder nicht auch involviert wäre - was gäbe es denn noch für Alternativen?

Und zum nächsten Punkt. Auf der Commons wurde ja angekündigt, dass die nächste Oxid Version 5 schon auf einem Cloud basierten Ansatz beruhen würde. Ist dann das aktuelle Oxid Framework nicht eh hinfällig?

Das ist doch im Prinzip reines HTML wo ich mir mit ein paar Funktionen und Variablen dynamischen Content reinknallen kann. Super simpel und eigentlich müsste das für jeden, der sich mit PHP und HTML auskennt auch weitgehend selbsterklärend sein.

Ne, ists nicht. Wenn ich einen String zusammen setzen will mach ichs in reinem php so:


$neuerString = $teil1 . $teil2;

in Smarty:


[{ assign var=neuerString val=$teil1|cat:$teil2}]

Bis man das für den anfang rausgefunden hat ist schon einige sucherei vonnöten, und großen sinn machts auch nicht, dieses “cat”, da kommt man ja nichtmal von selber drauf. Und leserlich ists auch nicht.

Obiges gehört zu den Grundkenntnissen bei PHP, und bei smarty muss mans sich erstmal anlesen.

Es ist einfach eine unnötige sprachliche zwischenebene und reines php wäre viel viel simpler.

Kleiner edit:

http://nosmarty.net/

Zwar leichtes bashing, aber die haben auch noch so einige gründe dafür, warum man smarty nicht nutzen sollte.

Aber wie gesagt, ich denke Smarty ist aus oxid nicht so leicht entfernbar, und für die leute die es gerne nutzen kann es ja auch drin bleiben, aber eine schnittstelle für alternative template engines wäre durchaus zu begrüßen.

Zu Deinem Beispiel:

Variablen etc. verarbeite ich in der Regel in Modulen oder Plugins und halte diese aus dem Design raus, bzw. gebe sie dort nur aus.

Gegenbeispiel:

Ausgabe der Variable $test in PHP

<?php echo $test; ?>

In Smarty

$test :wink:

Ausgaben von Variablen kommen zumindest bei mir deutlich öfter in einem Template vor als Variablen-Zuweisungen, die man auch in Modulen und Plugins realisieren kann, da die Templates dadurch “sauber” bleiben. Somit erhalte ich mit Smarty deutlich weniger Code als mit PHP. Und übersichtlicher ist er auch.

Dafür nehme ich es auch in Kauf, dass ich mal zwei Minuten in der Smarty Doku nach einer Funktion suchen muss.

[QUOTE=Michael Fritsch;13251]Zu Deinem Beispiel:

Variablen etc. verarbeite ich in der Regel in Modulen oder Plugins und halte diese aus dem Design raus, bzw. gebe sie dort nur aus.

Gegenbeispiel:

Ausgabe der Variable $test in PHP

<?php echo $test; ?>

In Smarty

$test :wink:

Ausgaben von Variablen kommen zumindest bei mir deutlich öfter in einem Template vor als Variablen-Zuweisungen, die man auch in Modulen und Plugins realisieren kann, da die Templates dadurch “sauber” bleiben. Somit erhalte ich mit Smarty deutlich weniger Code als mit PHP. Und übersichtlicher ist er auch.

Dafür nehme ich es auch in Kauf, dass ich mal zwei Minuten in der Smarty Doku nach einer Funktion suchen muss.[/QUOTE]
Richtig!

Smarty ist ja primär für die [B]Präsentation [/B]von existierenden Daten gedacht, [B]nicht [/B]für deren Erstellung.

Solche Rechenoperationen sind also eher die große Ausnahme als die Regel.