Spike-Solution des OXID eShops + Zend Framework verfügbar
Geschrieben von Peter Rother • Donnerstag, 24. September 2009 • Kategorie: OXID
Zuerst aber meine Einschätzung zu OXID und dem Zend Framework ... ich persönlich würde diesen Weg mehr als begrüßen. Das Zend Framework ist schon seit längerem in aller Munde und man könnte mit der Integration mit Sicherheit viele neue Kunden und auch third party Modul Entwickler in der Community begrüßen dürfen. Die Einzelnen Module des Zend Frameworks werden von der großen Community regelmäßig auf Bugs überprüft und vorhandene Bugs werden "relativ" schnell gefixt.
Warum OXID diesen Weg gehen möchte, sollte eigentlich allen, die mit dem Shop arbeiten klar sein. Nicht, dass der Shop schlecht ist, ich habe bisher kein besseres Shop System kennen gelernt. Warum OXID meiner Meinung nach diesen Schritt unternehmen möchte, behalte ich aber für mich 
.
Nun aber genug von dem Geplänkel, welche "Komponenten" könnte man sinnigerweise in den Shop einbinden? Im OXID Forum wurde darüber gesprochen, vorhandene Module wie z.B. den phpmailer durch Zend's Zend_Mail auszutauschen. Ich halte das für riesen Schwachsinn, da keiner, der mit dem Zend Framework arbeitet, wegen so einer marginalen Umstellung zu OXID wechseln wird. Da ich arbeitstechnisch nur mit dem Shop zu tun habe, darf man aus meiner Sicht aber auch nicht das ganze Partner Netzwerk vergraulen. Eine komplette Umstellung wäre so dann eigentlich nicht möglich, da etliche Module angepasst werden müssten und dies darf man den Kunden nicht zumuten. Klar, hätten alle Partner dann die nächsten Jahre einiges zu tun, aber das haben wir auch so schon.
Nun aber endlich mal zu den Teilen die man eigentlich ohne weiteres austauschen könnte, da OXID Partner mit diesen nicht viel zu tun haben, die aber mehr als Shop relevant sind.
1. MVC
Da niemand in den MVC des OXID Shops eingreifen muss (mir fällt hierzu kein Beispiel ein wo das passieren müsste), kann man schon einmal die komplette ZF Struktur hierfür übernehmen. Somit hätte man das ZF schon einmal so komplett eingebettet.
2. Config
Über Zend_Config kann man ohne Weiteres die komplette Konfiguration des OXID Shop abdecken.
3. Cache
Auch dieser Bereich lässt sich ohne Weiteres einbinden, da auch hier normalerweise kein Modul eingreifen muss.
4. Templates
Einer meiner Lieblings Punkte, die im Forum und der Mailing List angesprochen wurden. Hier wurde tatsächlich eingeworfen, dass man mit dem ZF alle Templates über den Haufen werfen könnte. Die Aussage von Einem der, wie es aussieht nur Templates erstellt, ist der größte Schwachsinn den ich je gehört habe. Smarty kann ohne Weiteres über einen View Helper weiter benutzt werden, was ich auch nur empfehlen kann. Bei Bedarf kann ich den View Helper gerne zur Verfügung stellen
5. Datenbank
Hier wäre etwas mehr Einarbeitungs Zeit nötig. Viele Querys in den Modulen sollten hier über die ZF Datenbank Logik laufen. Dies sollte eigentlich kein Problem sein, bei Bedarf halte ich hierüber auch gerne ein paar Schulungen. Der Vorteil, der nicht von der Hand zu weisen ist, ist, das OXID dann auch endlich auf anderen DBMS laufen würde und das alte ADODB damit aus dem Spiel wäre.
Das Hauptaugenmerk was OXID aber bei einer Umstellung - die mit Sicherheit kommen wird - beachten sollte, ist die I18N vernünftig umzusetzen. Hierzu müssten nur ein paar weitere Tabellen eingeführt werden und wir hätten eine vernünftige Internationalisierung.
So, das war es auch erstmal von meiner Seite. Ich werde mit Sicherheit noch einige weitere Punkte finden, die ich dann gerne hier ansprechen werde. Zu diesem Thema hätte ich auch RIESEN Interesse an einer Diskussion.
2 Kommentare
Ich denke dass sich da OXID eShop sich selber und den Entwicklern von Modulen und Komponenten einen großen Gefallen tut. Habe selbst nun einige Applikationen mit ZF entwickelt, und kann nur sagen dass die Entwicklung mit ZF wirklich Freude bereitet. Dadurch dass es komponenten-basiert ist, kann man viele Klassen auch in kleineren Projekten einsetzen ohne gleich das ganze Anhängsel mitbenutzen zu müssen.
Die Gefahr die ich darin sehe ist dass das zu einem Mammut-Projekt wie Magento mutieren könnte. Die Idee den Shop auf einem bestehenden, soliden Framework aufzubauen, welches die Arbeit den Entwicklern erleichtern soll ist gut, aber bitte auch gut dokumentiert, ressourcen-schonend und einfach in der Handhabung.
das sehe ich genau so wie du. Natürlich sollte OXID nicht probieren, auf biegen und brechen alle verfügbaren Komponenten mit aufzunehmen. Ich glaube die von mir bereits angesprochenen Teile sollten schon einmal vieles von dem was benötigt wird abdecken. Ich werde mir mal ein paar Gedanken dazu machen, was noch nützliches von dem Zend Framework, Einzug in den OXID Shop finden könnte.
Ein großer Vorteil bei einer Umstellung wäre natürlich auch, dass third Party Entwickler auf ein großes Spektrum an bereits vorhanden Komponenten zurück greifen könnten. Somit würde die Entwicklung neuer größerer und komplexerer Module mit Sicherheit um einiges leichter.
Für mich wäre auch noch wichtig, dass man eine vernünftige API zur Verfügung stellt, um auch von anderen Systemen aus mit dem Shop kommunizieren zu können.
Kommentar schreiben