[Marco Steinhaeuser]

Hallo,

habt Ihr schon diesen Blogpost gesehen?
http://www.oxid-esales.com/de/news/b...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ß

[laramarco]

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.

[avenger]

Originally Posted by Marco Steinhäuser

Hallo,

habt Ihr schon diesen Blogpost gesehen?
http://www.oxid-esales.com/de/news/b...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ß

Ich jedenfalls bin nicht dafür.

Das Zend Framework habe ich bei Magento erlitten...

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....)

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

Eines ist für mich ziemlich klar:

der Einsatz des Zend-Frameworks erzwingt eine erneute, sehr steile 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.

Mein Fazit:

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:

Never touch a running System!

[csimon]

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.

[MBa]

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 *nichtfürmarkus* 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 sogar im Java Bereich rückläufig.


Hier ein Link zur Verzeichnisstruktur von ZF welche mit den command-line-tool generiert wird. Selbst Zend hat hier scheinbar Handlungsbedarf gesehen.
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 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.

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 gleich unterstützt.

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.

[avenger]

Originally Posted by MBa

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

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.

..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....

[csimon]

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 Code:

<?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...

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.

[Michael Fritsch]

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.

[avenger]

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

$smarty.foreach.xxxx.iteration,$smarty.foreach.xxx x.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.)

Smarty rulez!

"{$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.

Wäre mal interessant zu hören, was Nicht-Entwickler dazu meinen...

Smarty-Templates oder PHP-Templates?

[lafi]

Originally Posted by avenger

Wäre mal interessant zu hören, was Nicht-Entwickler dazu meinen...

Smarty-Templates oder PHP-Templates?

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"