Plugin-Fähigkeit von GX2: Ein Überblick und Ausblick für Entwickler, Designer und interessierte Shopbetreiber Über die MainFactory Wir möchten Modulinstallationen, individuelle Anpassungen und vor allen Dingen Service Pack-Installationen in Zukunft vereinfachen. Ein großes Problem sind dabei immer die für Module häufig anzupassenden Dateien, z.B. die includes in der application_top.php, die bei fast jeder größeren Anpassung notwendig sind. Dadurch hat man es mit unterschiedlichen Versionen der application_top zu tun, die sich entweder gegenseitig überschreiben oder die man manuell zusammenführen muss. Beides ist für alle Beteiligten störend. Aus diesem Grund haben wir in GX2 als ersten Schritt zumindest das Includen von Klassendateien in eine statische Factory umgelagert. Die Factory kennt alle Klassendateien, die sich in den Unterverzeichnissen unseres neu eingeführten "system"-Verzeichnisses befinden und includet diese erst, wenn die jeweilige Klasse auch abgerufen wird. Beispielaufruf: $coo_filter = MainFactory::create_object('FilterManager'); Dadurch sparen wir uns Anpassungen in der application_top und der Code wird schlanker, da der Shop nicht mehr pauschal ALLES includet. Zudem können für diese Klassen, die über die Factory aufgerufen werden, im Verzeichnis "user_classes" modifizierte Kopien der Klassendateien abgelegt werden. Diese Kopien werden von der Factory dann anstelle der Originaldateien für die Erzeugung des jeweiligen Objekts verwendet. Was das nun bedeutet? Das bedeutet, dem Shop können auf diesem Wege Code-Änderungen zugeführt werden, die bei einem Shop-Update nicht wieder verlorengehen. Aktuell gilt dies für alle Code-Bereiche, die wir in die Klassen in den Verzeichnissen "system" und "templates/EyeCandy/source/classes" verschoben haben. Die altbekannten Klassen wie Order, Product, xtPrice, usw. werden wir im nächsten Schritt ebenfalls in die Factory überführen. Damit werden individuelle Anpassungen an den am häufigsten betroffenen Dateien update-sicher vorgenommen werden können. ContentViews In GX2 haben wir zahlreich Smarty-assign-Abschnitte und Code ganzer include-Dateien in neue, eigene Klassen (die "ContentViews") umgelagert. Aktuell betrifft dies beispielsweise sämtliche PHP-Dateien zum Erzeugen der Menüboxen im EyeCandy-Template. Auf diese Weise schaffen wir eine verbesserte Wiederverwendbarkeit von Code, z.B. lassen sich die neuen Menüboxen nun ohne großen Aufwand in jedem beliebigen Kontext erzeugen während man vorher den Code der Menübox möglicherweise hätte duplizieren und an die jeweilige Code-Umgebung hätte anpassen müssen. seit GX2 stattdessen in nahezu jedem Kontext einfügbar: $coo_bestsellers = MainFactory::create_object('BestsellersContentView'); $t_box_html = $coo_bestsellers->get_html($current_category_id); Mit den ContentViews lassen sich damit auch Anpassungen an den Menüboxen update-sicher vornehmen (siehe oben "user_classes"). Das Umlagern der PHP-Codes in eigene Klassen werden wir wie oben beschrieben mittelfristig auf weite Teile des Shops anwenden (z.B. shopping_cart.php und product_info.php). Die Codes an sich versuchen wir dabei möglichst wenig zu verändern, um die Kompatibilität zu älteren Modulen möglichst lange aufrecht zu erhalten. Das Überschreiben vorhandener Klassen eröffnet gerade in Verbindung mit den neuen ContentViews ganz spannende Möglichkeiten im Frontend-Bereich. So können z.B. für nachinstallierte Module neue Smarty-Variablen (auch global) in Template-Dateien "hineinassignt" werden, ohne dafür die ausgelieferten PHP-Dateien des Shops anrühren zu müssen. Mit einem weiteren Konzept, mit dem selbst die shopeigenen Template-Dateien nicht mehr angerührt werden müssten, experimentieren wir aktuell noch (besten Dank nochmal an Avenger für diese Idee). Das Schaffen von Modularität und neuer Abstraktionsebenen auf der einen Seite bedingt irgendwann das Einbüßen von Performance und beherrschbarer Komplexität auf der anderen Seite. Hier die richtige Mischung zu finden ist eine wichtige und anspruchsvolle Aufgabe. Die angestrebte Plugin-Fähigkeit ist immerhin kein Selbstzweck, sondern soll Shopbetreibern, Entwicklern und Designern die Zusammenarbeit bei der Pflege des Systems gleichermaßen erleichtern. Eben wegen der hohen Wichtigkeit dieses Ziels lassen wir uns bei der Einführung neuer Systemstrukturen im Zweifel lieber etwas mehr Zeit und testen Architekturänderungen wie in GX2 vorerst im Rahmen teilweiser Implementierungen bis wir uns der nachhaltigen Handhabbarkeit gewiss sind. Denn die dauerhafte Vorhaltung einst vorgegebener Strukturen und Schnittstellen hilft in der Regel allen die Planungssicherheit zu erhöhen. Kurzgefasst: In der nächsten größeren Version GX2.1 liegt der Schwerpunkt in dem Ausbau und der Weiterentwicklung der mit GX2 eingeführten Konzepte zum Thema Skalierbarkeit und Update-Sicherheit. Diese umfassen insbesondere - die Erweiterung der MainFactory auf die meistgebrauchten Klassen im Frontend und Backend - die Möglichkeit Klassen aus der Factory nicht nur komplett zu überschreiben, sondern optional auch nur einzelne Methoden zu modifizieren - die Verlegung sämtlichen für Template-Dateien zuständigen PHP-Codes in neue ContentView-Klassen und damit die Schaffung einer neuen, sauber getrennten Präsentationsschicht sowie - das systemweite Ersetzen der alten Sprachkonstanten durch die neuen Sprachvariablen aus unserem neu eingeführten Textphrasensystem Fragt nun bitte nicht alle nach dem Termin für GX2.1, denn der volle Umfang dieses Vorhabens ist vom heutigen Stand aus noch schwer zu beurteilen. Wir halten euch bei den Fortschritten aber immer auf dem Laufenden.
@nonito das hört sich alles super an und ist genau das was ich immer gesucht habe. Bin mal gespannt was dann an Modulen von externen Anbietern so kommt - lohnt sich dann auch wieder richtig Geld zu investieren.
Der Ausblick in die Zukunft ist prächtig. Nur geht ihr m.E. da zu zögerlich an's Werk, was die Überlademöglichkeit der neuen, und vor allem auch der alten(!), Klassen angeht. Es ist alles bekannt und vorhanden, was dazu nötig ist, um innerhalb kürzester Zeit (2 bis 3 Tage!) GX2 das Überladen aller(!) Klassen zu erlauben. Bei den neuen Klassen, die schon über die Factory instantiiert werden, muss lediglich die Factory angepasst werden, um das zu ermöglichen. Diese geänderte Factory-Klasse habe ich ja schon zur Verfügung gestellt (wobei es mittlerweile eine wesentlich verbesserte Version gibt). Was ist nun mit den alten Klassen (Frontend und Admin)? Man könnte natürlich alle explizit über die Factory instantiieren, was aber sehr umständlich ist, und gegenüber dem jetzigen Stand kein selektives Laden von Klassen erlaubt. PHP hat aber seit Version 5 auch die schöne Möglichkeit, einen "Autoload"-Handler für Klassen zu definieren, der von PHP, quasi als letzte Chance, aktiviert wird, wenn bei Instantiierung einer Klasse (mit "new") die Klasse noch nicht geladen ist, um die entsprechende Klasse dann zu laden. (D.h., es werden dabei dann auch nur noch die Klassen instantiiert, die auch verwendet werden!) Und siehe da, die Factory kann wunderbar diese Rolle des "Autoloaders" übernehmen! Mit den folgenden 2 Zeilen in der "application_top.php" wird der Autoloader definiert: $MainFactory=new MainFactory; spl_autoload_register( array($MainFactory, 'create_object') ); Das nützt uns aber noch nicht allzuviel, da die Klassen ja immer noch mit "include/require" explizit geladen werden, und der "Autoload"-Prozess gar nicht notwendig ist... Man muss also die "include/require" für Klassen loswerden (auskommentieren/löschen). Mit einem Tool wie UltraEdit ist das in wenigen Minuten erledigt.... Aufgrund der nicht durchgängig konsistenten Definition und Verwendung von Klassen in osc/xtc/Gambio sind aber noch weitere Arbeiten notwendig. (Das sind aber rein formale Änderungen, inhaltlich Änderungen an den Klassen sind nicht(!) erforderlich, weil ja nur die Art der Klassen-Instantiierung geändert wird.) Was bleibt zu tun? 1. Dem "Autoloader" werden leider keine Initialisierungs-Paramter einer Klasse mit übergeben (warum auch immer). D.h., Klassen wie "product", "currency", "order" usw., die u.U. mit einem Parameter (products_id, order_id) aktiviert werden, müssen explizit über die Factory gestartet werden. Die betroffenen (wenigen) Klassen sind (mit UltraEdit) aber auch leicht identifiziert, und der Aufruf geändert. 2. Die Factory setzt voraus, dass der Klassen-Name und der Klassendatei-Name gleich sind, was bei einigen alten Klassen aber nicht der Fall ist. Auch diese Klassen kann man (mit UltraEdit) leicht identifizieren. Man kann für diese Klassen dann den Datei-Namen auf den notwendigen Namen ändern, damit die Factory ihr Werk tun kann. Und das war's dann schon.... In einer Woche könnte so eine GX2-Version fertig sein! Und dann hat man viel Zeit, individuelle Anpassungen alter Klassen vorzunehmen..... Mit brennt das Thema deshalb so auf den Nägeln, weil ich mit der GX2 allen alten Ballast aus der xtc-/Gambio-/Gambio GX-Zeit über Bord geworfen habe, jetzt aber wieder Änderungen brauche, die ich ungerne in den Core-Dateien machen will.... Und da ich weiss, dass man das Klassen-Überlade-Verfahren mit wenig Aufwand realisieren kann (siehe oben), würde ich halt gerne sauber aufsetzen, um mir das Update-Problem vom Hals zu halten. Könnte ich mir zwar alles selbst machen, aber das muss im Core verankert sein, weil man sonst ein Riesen-Update-Problem hat...
Ich wusste gar nicht, das Cowboys programmieren können. Hört sich super an. Ihr habt bei mir eine INCEPTION durchgeführt. Ich habs gar nicht gemerkt aber ich will das auch!
Er wird sich auf den gleichnamigen Film bezogen haben: http://de.wikipedia.org/wiki/Inception Kommen wir wieder zurück zum Thema .
auch einen Fingerhandschuh über einen Fäustling ziehen? - der mußte einfach sein jetzt aber zurück zum Thema, is kein Chat hier
In letzter Zeit wird ja häufig von der Möglichkeit der Klassenüberladung in Gambio GX2 gesprochen: Gambio hat darüber berichtet, und ich habe das auch getan. Um mal vom Allgemeinen in's Konkrete zu wechseln, habe ich meine Implementierung dieser Funktionalität aufbereitet und dokumentiert, so dass man mal in einer Testumgebung(!) ausprobieren kann, wie das funktioniert, und was man damit machen kann. Das ist natürlich ein Thema eher für Spezialisten, denen die PHP- und (interne) Gambio-Welt nicht fremd ist, weil das am Anfang sicher einige Zeit braucht, bis man das verstanden hat. Und um eine Klasse überladen zu können, muss man natürlich verstehen, wie die Klasse funktioniert. Meine Implementierung basiert auf dem im OXID eShop verwendeten Konzept, das ich ziemlich 1 zu 1 übernehmen konnte. Dort ist das schon viel Jahre in Gebrauch, und hat den großen Vorteil, sehr einfach anwendbar zu sein. Der eigentliche zuätzliche Code für die Funktionalität in der "MainFactory.inc.php" beträgt schlappe 40 Zeilen PHP-Code, so einfach kann das sein. Es ist dann allerdings doch mehr geworden, weil ich (zur Vorbereitung auf die Anwendung mit allen Klassen) die Ermittlung der Klassenpfade gecached (das sind doch insgesamt so 350 Klassen), und ein paar Optimierungen vorgesehen habe. Die "ClassRegistry.inc.php" habe ich auch geändert, damit man auch die Admin-Klassen sauber verwenden kann (blöder Weise haben Klassen im Admin und im Shop oft die gleichen Namen, was bei der Art und Weise, wie die Klassenfactory arbeitet, zu heftigen Problemen führte... Aber das ist damit auch gelöst. Die Doku und die Dateien kann man unter http://www.powertemplate.de/kunden/class_overloading.zip laden. Viel Spaß beim Testen.... (Der Frust am Anfang ist ganz normal! )
Also das ist ja alles wunderschön. Aber ich glaube bei der Anzahl interressierter Leser in diesem Forum, sollte sich mal einer Gedanken machen, diese Beschreibungen und Ankündigungen so zu verfassen, das man auch die Möglichkeit hat, als Laie das zu verstehen. Vieleicht um das Interresse zu wecken es verstehen zu wollen. Es gibt sicher nicht viele die das raffen was da steht. Ich gehöre zu denen die es nicht so auf die Reihe bekommen haben. Allerdings ist die Schreibweise der Texte von @Nonito und @Avenger so profesionell, das man einfach Lust darauf hat, sich dem Thema zu stellen. Wo zum Teufen findest du jemanden der dir einfach das Grundprinzip von XTC, Gambio und Co. erklährt. Ich habe nie schulisch oder von der Ausbildung her etwas mit so etwas zu tun. Was ich kann hab ich mir selbst beigebracht oder "WICHTIG" in Foren gelernt. Mir reicht das nicht. Ich habe nirgends etwas Literrarisches gefunden. Und was das im Netz steht ist, naja, auch nicht unbedingt hilfreich. Also: Wo bekomme ich das Wissen her???? Und wie bekomme ich es sachlich verständlich??? Ich weis das das jetzt alles komisch klingt aber es macht mich sauer, so etwas zu lesen(und ich lese gern!) und ich versteh nur Bahnhof. PS: ich hab nicht getrunken und auch nix geraucht!!! ;-)
Deine Antworten bringen mich immer zum Schmunzeln. Nein Fakt ist, das wir dieses Level nicht erreichen werden. Das hat auch damit zutun das wir nicht die Zeit finden werden um das alles zu lernen und zu verstehen. Fakt ist aber auch, wenn man zumindestens ein ABC dieser Materie kennt, versteht man den Sinn der hinter diesen Projekten steht. Und wenn man etwas versteht, dann ist die Weise wie man es sieht eine ganz andere. Wie kann ich mich über etwas freuen(z.B. Ankündigung von Gambio-Projekten) wenn ich nichts davon raffe. Es geht mir ja nicht darum jeden Programmcode zu lesen wie eine Tageszeitung aber das System sollte man kennen. Ich weis auch wie ein Motor funktioniert aber kann ich ihn einstellen oder reparieren? NEIN Sowas wie eine Gambio-Fibel, das wäre gut. Wo man alles mal erklährt bekommt. Wie der ganze Kram miteinander funktioniert oder z.B. was heist Klassenüberladung? Wer weis das hier schon. Die wenigsten. Und das ist eigentlich schade. Man könnte noch viele Beispiele bringen.
Ein Laie kann das nicht verstehen, da einfach zu viel Grundlagen-Know-How erforderlich ist. Und da braucht man schon ein paar Jährchen intensive Auseinandersetzung mit PHP und Shop-Systemen, um so weit zu sein. (Ein Informatik-Studium kann da auch nicht schaden....) http://www.amazon.de/s/ref=nb_sb_no...alias%3Dstripbooks&field-keywords=php&x=0&y=0 Da gibt es einiges, um sich da rein zu finden....
Guten Morgen Avenger, naja, bin jetzt Ende 30, da muss ich mich beeilen. Wenn ich es so kann wie du, gibts sicher schon GX10. Grins. Aber ich werde es probieren. Hab eben 2 dieser Bücher bestellt. Und wenn was nicht verständlich ist, gibts ja noch das Forum. Danke
Bei all der Euphorie und Begeisterung über eine fantastische (neue) Prgrammiertechnik, bitte ich eines zu bedenken: Die Kluft zwischen denen, die mit durchschnittlicher Programmierkenntnis in der Lage sind die Software anzupassen und denen, die die "OpenSource-Software"!! nur noch so hinnehmen müssen wie sie ist, wird immer größer. Kleines Beispiel, siehe hier... Meiner Meinung nach ist es ein riesen Vorteil der bisherigen Technik, dass viele in der Lage sind solche und ähnliche "Zusatz-Module" selber in den Shop zu integrieren. Wie o.g. Beispiel zeigt, ist damit bereits jetzt Schluss mit Lustig und ohne die von Avenger genannte erforderliche Zusatzausbildung dem Einzelnen nicht mehr möglich. Das Ende vom Lied wird sein: Es wird ein GX5 geben dass man entweder so nimmt wie es ist - oder sich jede Anpassung von einem Spezialisten programmieren lassen muss - für Euronen natürlich! Für mich wäre in einem solchen Fall die Entscheidung klar, ein System (und sei die Technik dahinter noch elegannt, fantastisch, updatefreundlich und modern!!) dass ich nicht anpassen kann, käme nicht in Frage. Ist nur meine persönliche Meinung ... und Sorge.
Manfred da kann ich dir nicht ganz zustimmen. Die Anpassungen des System kannst du wohl weiter selbst machen, nur halt etwas anders als bissher. Das Problem was ich eigendlich gemeint habe ist folgendes. Es gibt tausende Module mit Einbauanleitungen die du in die Tonne drücken kannst. Das literrarische hinter solchen Systemen ist das Problem. Wenn man solche Systemänderungen umsetzt, läuft man Gefahr sich vom Ursprung, dem XT, zu trennen. Das heist die bissherigen Module vom XT die in Gambio laufen, kannst du nicht mehr einfach nach dessen Anleitung einbauen. Anders eingebaut gehts schon, nur gibt es nichts wo du so etwas VERTÄNDLICH nachlesen kannst. Und als neuling hast du dann keine Chance selbst was zu machen.
Moin Steffen, dann sind wir doch einer Meinung. Du kannst es (wahrscheinlich) nur verständlicher ausdrücken!? Und wohin führt uns dass? Ein GX7 ala 'Word' - friss oder stirb! EDIT: Und was bringt es uns? Läuft der Shop dann besser, schneller ... bringt es mehr Kunden, Umsatz?? Oder haben es "nur" die Entwickler leichter?
Man muss diese Thematik veralgemeinern. Der Fortschritt in diesem Bereich ist enorm. täglich kommen neue dinge hinzu, Anforderungen an die Systeme erhöhen sich und damit auch an die Programmierer. In Zukunft wird es nicht mehr möglich sein selbst in den Code einzugreifen oder du bist Avenger. Der hat aufgrund seines Wissens die Möglichkeit dazu. Es sei ihm gegönnt!! Ein kleiner Vergleich: mein erster Rechner war ein SX25 mit MsDos und Windows 3.11 Wollte ich eine Soundkarte, musste ich in der config.sys und autoexec.bat alles selbst eintragen. Ich war stolz, es hat funktioniert. Und heute? Genau, nix mit selbst reinschreiben. Reinstecken und fertig(fasst immer) Bei den Shopsystemen sehen ich da ein Problem. Windows hatte keine Konkurenz. Schau dir an wieviele Shopsysteme es gibt. Und jeder will das beste und neueste. Klar müssen die Entwickler mit dem Trend gehen und solche Sachen machen. Aber der Benutzer bleibt programmiertechnisch im Hinterland. Wenn wir unsere Shopsysteme einmal so steuern wie wir mit Windows umgehen, dann ist das auch nicht mehr wichtig, weil du als Benutzer die Sache benutz und nicht mehr.
Sehr schön .... und dass soll eine gute Entwicklung sein, hin zu einem, an persönliche Ansprüche/Anforderungen gestalteten Shop? Nur damit da keine Missverständnisse aufkommen: Ich stamme noch aus der C64-Zeit, .... keine Maus, .. kein Windows! Habe mir Basic, dBase, Clipper, Pascal, HTML, PHP selber beigebracht und als Programmierfreak immer noch für alles Neue offen! Bleibt immer noch meine Frage: Bringt der Aufwand mehr Kunden, Umsatz ... GEWINN? Das ist doch wohl der Sinn dessen, weshalb wir uns hier über den Weg laufen - ooooder?