Der Titel ist provokant, soll es auch sein... Ich war in den letzten Tagen gezwungen mich durch die Untiefen der GXEngine durchzuwühlen, da ich einige Zusatzinformationen in die Bestellung einbringen muss. Und was ich dabei gesehen habe, hat mich doch sehr erschüttert. Ein kurzer Blick auf die Abläufe zur Erstellung einer Bestellung ("checkout_process.php") in der Vor-GXEngine-Zeit: es wird das "orders"-Objekt generiert, das (in Form eines Objekts und dort in "Arrays" enthaltenen Daten) alle Informationen zu Bestellung enthält: Adressen, Artikel, Attribute, Zusammenfassung,... Es waren auch Methoden bereitgestellt, über die man (durch Überladung) sehr einfach eigene Informationen in diese Struktur einbauen konnte... Aus dieser Struktur wurden dann die notwendigen SQL-Befehle erstellt, um die notwendigen Einträge in der DB zu erstellen. Das war schlank, übersichtlich, und enthielt alles, was der Entwickler braucht, um einfach eigene Erweiterungen/Änderungen in diesen Prozess einzubringen. Wie sieht das heute im Zeitalter der GXEngine aus? Es wird wieder das "orders"-Objekt generiert, das (in Form eines Objekts und dort in "Arrays" enthaltenen Daten) alle Informationen zu Bestellung enthält: Adressen, Artikel, Attribute, Zusammenfassung,... Einfache Methoden diese Daten zu erweitern sind nicht mehr vorhanden. Und wenn es dann an das Abspeichern der Bestellung geht, schlägt gnadenlos die GXEngine zu! Und die macht nichts anderes, als ein neues GXEngine "order"-Objekt aufzubauen, diese Mal aber in perfekter OOP-Manier. Dabei wird nicht die schon im vorhandenen "order"-Objekt enthaltene Info verwendet, sondern die notwendigen Infos werden noch mal komplett aus der DB gelesen.... Und es werden auch keine Arrays mehr aufgebaut für diese Informationen, sondern (mit Hilfe vieler Klassen) "Collections"... Und in diesen "Collections" ist jedes einzelne Daten-Element ein Objekt, mit eigenen Methoden um die zu lesen und zu schreiben.... (Wenn man sich diese Datenstrukturen in einem Debugger ansieht, wird man schwindelig. Ich zumindest.) Über die Probleme, in diese Strukturen eigene Inhalte einzubringen, hatte ich ja schon unter http://www.gambio.de/forum/threads/sendorderprocess.26835/ und http://www.gambio.de/forum/threads/sendorderprocess.26835/#post-225360 berichtet.... Insgesamt wird eine Unmenge an PHP-Code bewegt, und gigantische Datenstrukturen aufgebaut, um das alles aufzubauen.. Das Beste kommt, wie meist, aber zum Schluss! Nachdem dann alles aufgebaut ist, geht es dann an das Speichern der Daten in der DB. Und dazu werden dann alle diese gigantischen Datenstrukturen wieder umgewandelt in... ....einen klassischen Array mit den Datenfeldern.... Da wir das aber alles schon hatten, bevor die GXEngine zugeschlagen hat, frage ich mich doch ernsthaft: warum, um alles in der Welt, tut man das???? Warum wird ein schlankes und performantes Shop-System, das schon mit den frühen 2.x-Versionen nahezu fast alles enthielt, um updatesicher, nachvollziehbar und einfach eigene Lösungen einzubringen, so vergewaltigt??? Das Einzige, was man aus meiner Sicht erreicht hat, ist, das System maximal unverständlich zu machen. Und die Ladezeiten in die Höhe zu treiben.... Server Return-Time für die Speicherung der gleichen Bestellung: v2.0.18: 0,65 Sekunden: v2.7.1.2: 2 Sekunden (also 3 Mal länger als zuvor.) Dafür hat man eine perfekte "OOP-Hölle" geschaffen, Vorteile irgendwelcher Art mag ich beim besten Willen nicht zu erkennen, sondern ausschließlich Nachteile. (Stimmt nicht ganz, denn das durchgängige Refactoring aller bis dahin prozeduralen Programm-Module wie "index.php", "checkout_process.php" in Klassen usw. ist sicher sehr wünschenswert. Das hat aber nichts mit der GXEngine zu tun, sondern läuft unabhängig davon parallel...) Wenn ich mir vorstelle, was man mit dem für die GXEngine sicher betriebenen Aufwand an funktionellen Verbesserungen hätte erreichen können... Kann mich irgend jemand vielleicht doch eines Besseren belehren????
nun manche Sachen erschließen sich mir auch nicht mehr ganz. Mir ist mittlerweile auch schon aufgefallen, das einige Sachen nurnoch sehr umständlich zu lösen sind ... leider
Und hier ein kurzer Blick auf das Vorgehen und die damit verbundenen Stolpersteine eines Modul-Entwicklers, der mit seinem eigenen Modul neue Bestellungen anlegen möchte (z.B. für einen Wawi-Abgleich oder für Marktplatz-Schnittstellen) in der Vor-GXEngine-Zeit: Er kopiert sich den o.g. Code mit Objekt-Erzeugung, Arrays und SQL-Befehlen aus dem Checkout und fügt diese in seine Moduldateien ein. Da er möglichst valide, vollständige Bestellungen im Shop anlegen möchte, die optimalerweise aussehen wie "echte" Bestellungen, kopiert er sich sehr, sehr viel Code aus dem Checkout, auch wenn für seine Bestellungen nicht wirklich alles relevant ist. Oder er beschränkt sich eben auf das Nötigste und hat dann eben keine vollständig validen Bestellungen im System. Kann man machen, ist aber eigentlich auch nicht so schön. Nun kommt ein reguläres Gambio-Update, in dem für ein Bugfix, neues Feature oder eine rechtlich relevante Umprogrammierung eine kleine Änderung an der Order-Speicherung notwendig ist. Mit den Update-Dateien gelangen die gebrauchten Code-Änderungen in den Checkout. Im Checkout ist damit alles gut, aber da das Modul Teile der Shop-Infrastruktur einfach "mitkopiert" bekommen hat statt auf wiederverwendbare, gemeinsame Infrastruktur zu setzen, bekommt es von der Änderung nichts mit. Die evtl. neue Information fehlt in den Bestellungen des Moduls oder noch schlimmer: das Modul funktioniert einfach gar nicht mehr. Wenn man viele solcher Module hat, weil man etwa aus vielen Kanälen Bestellungen übernimmt, wird das Szenario umso spannender. In der Zeit seit der GXEngine: Statt ganze Code-Teile aus dem Shop zu kopieren, die sich jederzeit ändern könnten, spricht der Entwickler nur noch die dokumentierte API der GXEngine an. In etwa so: PHP: // Ich möchte mit Kundeninformationen arbeiten.$customerReadService = StaticGXCoreLoader::getService('CustomerRead');// Ich möchte mit Bestellinformationen arbeiten.$orderObjectService = StaticGXCoreLoader::getService('OrderObject');// Ich möchte Bestellungen schreiben.$orderWriteService = StaticGXCoreLoader::getService('OrderWrite');// Dies ist mein Kunde.$testCustomerId = new IdType(1);$customer = $customerReadService->getCustomerById($testCustomerId);$customerAddress = $customerReadService->getCustomerDefaultAddress($customer);// Dies sind meine bestellten Artikel.$item1 = $orderObjectService->createOrderItemObject(new StringType('Product 1'));$item1->setPrice(new DecimalType(2.90));$item1->setQuantity(new DecimalType(3));$item2 = $orderObjectService->createOrderItemObject(new StringType('Product 2'));$item2->setPrice(new DecimalType(19.50));$item2->setQuantity(new DecimalType(2));// Dies sind meine Versandkosten.$totalShipping = $orderObjectService->createOrderTotalObject( new StringType('Versandkosten'), new DecimalType(4.90), new StringType('4,90 EUR'), new StringType('ot_shipping'));// Dies ist meine Endsumme.$totalSum = $orderObjectService->createOrderTotalObject( new StringType('Gesamtsumme'), new DecimalType(52.60), new StringType('52,60 EUR'), new StringType('ot_total'));// Meine Bestellung ist komplett und nun möchte ich sie speichern.$orderId = $orderWriteService->createNewCustomerOrder( $testCustomerId, $customerAddress, $customerAddress, $customerAddress, new OrderItemCollection($item1, $item2);, new OrderTotalCollection($totalShipping, $totalSum);, new OrderShippingType('Pauschale Versandkosten', 'flat_flat'), new OrderPaymentType('Vorkasse', 'moneyorder'), new CurrencyCode('EUR'), new LanguageCode('DE'), new StringType('Test Kommentar')); Der Entwickler muss sich keine Gedanken mehr darüber machen, wie die Tabellen oder Tabellenspalten heißen, die für eine Bestellung relevant sind. Ebenso interessiert ihn nicht mehr, ob sich diese in Zukunft irgendwann ändern könnten. Ebenso interessiert ihn nicht mehr, welche anderen Daten sonst noch für eine vollständige, valide Bestellung wichtig sein könnten. Der Entwickler muss sich hier nur noch darauf verlassen, dass sich die Methode createNewCustomerOrder() nicht so schnell ändert und bekommt nicht mehr sofort die Krise, wenn Gambio wieder mit noch mehr Refactoring zuschlägt. ;-) Aufräumarbeiten in den Dateien wie index.php und checkout_process.php konnten uns unter anderem deswegen gelingen, dass wir viele Abläufe in eben solche Services ausgelagert haben und in den Dateien nur noch die APIs dieser Services nutzen. Wir wissen, dass unsere Umbauten für viele total nervig sein müssen. Immerhin haben wir viel gewohntes einfach weggerissen und das mag meistens niemand gern. Allerdings sind wir der Meinung, dass viele Dinge dafür in Zukunft nun wesentlich geordneter gemacht werden können. Ich schätze, das ist wie wenn man Zuhause über Jahre sein eigenes Chaos gewohnt war und plötzlich jemand kommt, einfach alles wegräumt und in Schränke und Schubladen verstaut. Ist erstmal überhaupt gar nicht lustig. Man findet ja gar nichts mehr wieder! Bis man vielleicht merkt, dass die Schränke und Schubladen ja alle (oder zumindest überwiegend ;-) ) beschriftet sind, und die neue Ordnung vielleicht doch den einen oder anderen Vorteil hat.
Hi Avenger, Mist! Da war Nonito schneller! Naja, damit ich den Roman jetzt nicht umsonst verfasst habe, hau' ich den trotzdem mal raus! Danke erst mal für dein Feedback und deine Meinung. Ich möchte dir die Vorteile der GXEngine gerne versuchen zu verdeutlichen und einige Nachteile der vorherigen Vorgehensweise aufzeigen. Zunächst etwas zum aktuellen Zustand des Checkouts: In ähnlicher Weise, wie wir es mit dem neuen Gambio Admin gemacht haben, haben wir auch begonnen Services in Shop einzuführen. Beim Admin hatten wir den gesamten Unterbau unangetastet gelassen und zunächst die Oberfläche umgestaltet. Beim Checkout ist es aktuell ähnlich. Wir haben einen großen Teil des alten Codes (CheckoutProcessProcess) beibehalten und haben nebenher Strukturen geschaffen, die in dem alten prozeduralen Code nicht wirklich existierten, nämlich die gekapselte Handhabung einzelner Entitäten, wie der GXEngineOrder. Damit haben wir für uns die Grundlage geschaffen, den Checkout neu zu bauen. Genau das werden wir in Kürze auch angehen. Daher ist die CheckoutProcessProcess aktuell eher wie eine Art Adapter zwischen alter und neuer Technik zu sehen. Nun gehe ich im einzelnen auf deine Anmerkungen ein. In der Tat hat dieses Vorgehen in der Vergangenheit Entwicklern viele einfache Möglichkeiten geboten sich in (nahezu) jegliche Stelle einzuhängen und eigenen Code auszuführen. Das kann man als Vorteil sehen, ist aber ein Fluch, wenn man mehrere Module im Shop hat, die sich an den gleichen Stellen einklinken, Geschäftslogik auseinanderreißen und somit vollkommen inkonsistente Shopzustände erzeugen. Später muss der Support ran und sich nach langer Fehleranalyse über die seltsamen Zustände der Daten wundern. Technisch ist der alte prozedurale Checkout überholt und nahezu unwartbar. Jede Änderung, die wir z.B. für einen Bugfix am Checkout vornehmen mussten, hat sehr lange gedauert. Nicht weil der Fix schwierig an der gewünschten Stelle einzubauen ist, sondern, weil wir nie genau wissen konnten, welche Auswirkungen unsere Änderung auf andere Stellen im Shop hat. Wie ich eingangs beschrieben hab', ist die aktuelle CheckoutProcessProcess eher als Adapter zu sehen. Dadurch ist Einiges gerade etwas umständlich gelöst. Auf jeden Fall verstehe ich, dass dir das widerstrebt. Keine Sorge, das bleibt nicht so. Mithilfe von Collections können wir sicherstellen, dass die enthaltenen Inhalte den richtigen Datentyp haben. Das ist ein großer Zugewinn in Puncto Stabilität. Wenn eine Methode z.B. mehrere Orders als Parameter erwartet kann es nicht passieren, dass ein Entwickler stattdessen versehentlich eine Reihe von Order-IDs übergibt, weil die Methode ausdrücklich eine valide Collection erwartet. Stimmt. Breakpoints an interessanten Stellen setzen. Das kann ich dir sagen. Wenn wir künftig unsere Datenbankstruktur anpassen möchten, wird das einen Modulentwickler nicht mehr sonderlich stören. Da alle Daten über Repositoriesan entsprechende Reader, Writer und Deleter delegiert wird, die dafür sorgen, dass die Handhabung der Daten korrekt abläuft. Das was ein Entwickler tun muss, um z.B. eine Bestellung anzulegen oder abzurufen, bleibt dabei unverändert. Da wollen wir hin. Dafür brauchen wir auch die Typisierung über Collections, um sicherzustellen, dass das, was uns an Daten reingegeben wird, valide ist. Das geht mit einem Array, in dem jedes Element einen anderen Typen haben kann, nicht so leicht. Innerhalb der Methode, in der bereits sichergestellt ist, dass die übergebenen Daten valide sind, kann das Array wieder genutzt werden, um die Daten dann in die Datenbank zu schreiben. Ich kann gut nachvollziehen, dass dir das System unverständlicher vorher vorkommt. Wir sind da in einer ähnlichen Situation: Wir kannten die alte Struktur wie unsere Westentasche (du wahrscheinlich sogar noch mehr als ich) und müssen uns nun mit etwas vollkommen Neuem beschäftigen. Ich fühle mich auch manchmal, als hätte ich alle Möbel in meiner Wohnung umgestellt und müsste noch immer einige selten genutzte Möbel erneut suchen. Mit Gewohnheit brechen kann ungemütlich sein. Aber ich kann dir versichern, dass das nur eine Frage der Umgewöhnung ist. Ein Vorteil an der neuen Struktur ist nämlich, dass sie konsistent ist. Wenn du z.B. weißt, wie man den OrderService benutzt, um Bestellungen zu persistieren oder abzurufen, dann weißt du auch, wie man dies mit dem ProductService tut. Die längere Ladezeit ist aktuell natürlich auch der bereits beschriebenen Adapter-Funktion der CheckoutProcessProcess geschuldet. Ich gehe aber auch stark davon aus, dass die Ladezeit künftig länger sein wird, als in der v2.0.18. Wir opfern so zu sagen Geschwindigkeit gegen System-Stabilität. Auch Module werden dadurch stabiler und mindern die Stabilität des Systems nicht mehr so leicht. Wir haben sogar noch mehr Aufwand betrieben, als es äußerlich den Anschein haben mag und haben damit einen der größten Vorteile der GXEngine genutzt. Die GXEngine wurde vollständig testgetrieben Entwickelt. Das heißt, dass wir für den gesamten Code der Engine Unit-Tests haben, die uns fortlaufend, die Stabilität und korrekte Funktionsweise der bestätigen. Jede Änderung, die wir an der Engine vornehmen, wird automatisiert auf Herz und Nieren geprüft. Das Shopsystem kann bereits sehr viel. Natürlich gibt es immer neue Funktionalitäten, die man sich wünschen kann. Wir haben auch mit der Weiterentwicklung neuer Funktionen nicht geknappst. Was das Shopsystem bislang nicht so gut konnte, war flexibel auf Veränderungen zu reagieren und dabei seine eigene Stabilität sicherzustellen. Das haben und werden wir mit der GXEngine erreichen. Ich hoffe, ich konnte etwas Licht ins Dunkel bringen und dich vielleicht auch überzeugen, dass die GXEngine nicht als Totgeburt, sondern als ernstzunehmendes Fundament unserer künftigen Entwicklung zu sehen ist. Schöne Grüße Wu
Hallo, Nonito, erst mal vielen Dank dass Du Dir Zeit nimmst, mir zu antworten. Da kennst Du aber den tollen Code älterer Gambio-Versionen aber nicht mehr richtig ! Nehmen wir mal als Beispiel die Version 2.1... Da war die "checkout_process" schon "refactored" als Klasse, der Checkout wurde in der Klasse "CheckoutProcessProcess" abgewickelt. Und da brauchte man natürlich nicht eine einzige Zeile der Basisklasse zu kopieren, um eigene Änderungen/Erweiterungen an den Bestelldaten zu machen, weil Ihr da (auf meine Anregung übrigens ) eigene Methoden dafür bereit gestellt habt! Nehmen wir als Beispiel mal die "save_order"-Methode in "CheckoutProcessProcess", die die Daten für die "orders"-Tabelle aufbereitet und speichert. Darin findet man vor dem Abspeichern den Aufruf der Methode "add_order_data", über die ich dann durch Überladung der Methode meine zusätzlichen Daten einbringen konnte. Code: $this->add_order_data($t_sql_data_array); $this->wrapped_db_perform(__FUNCTION__, TABLE_ORDERS, $t_sql_data_array); $GLOBALS['insert_id'] = xtc_db_insert_id(); $this->order_id = $GLOBALS['insert_id']; $_SESSION['tmp_oID'] = $this->order_id; Für andere Bestelldaten (Artikel, Zusammenfassung usw) gab es analoge Methoden, um Zusatzinfos einzubringen. Code: $this->add_order_product_quantity_data($t_sql_data_array, $p_products_array); $this->add_order_total_data($t_sql_data_array, $this->order_totals_array[$i]); $this->add_order_status_history_data($t_sql_data_array); $this->add_product_data($p_products_sql_data_array, $p_products_id); $this->add_order_product_data($t_sql_data_array, $p_product_array); $this->add_special_data($t_sql_data_array, $t_special_array); $this->add_product_attribute_data($t_sql_data_array, $p_attribute_array); $this->add_order_product_attribute_data($t_sql_data_array, $t_attributes_array); $this->add_order_product_download_data($t_sql_data_array, $t_attributes_array); $this->add_tracking_data($t_sql_data_array, $t_customers_logon_array); Diese Datenabstraktion hat sicher etwas für sich... Solange man nicht anfangen muss, in diesen standardmäßig aufgebauten Strukturen etwas zu ändern oder hinzuzufügen will (siehe meine Beispiele). (Vielleicht können wir uns ja mal konkret eines dieser Beispiele ansehen, ob man das besser lösen kann, ich werden dazu noch mal einen Post erstellen.) Das hat die "save_order"-Methode der Version 2.1 auch geleistet.... Und wenn ich eine Zusatzfeld in der Datenbank bedienen will mit eigenen Erweiterungen, dann nutzt mich diese Datenabstraktion nichts mehr, da ich dann auch wissen muss, wie der Name und Type des Feldes sind... Das würde ich jetzt erst einmal bestreiten wollen! Der "Beweis" ist z.B. die Version 2.1 mit einer "refactored" "checkout_process" und "CheckoutProcessProcess", die im wesentlichen schon so aussehen wie heute... Die Methoden zur Speicherung einer Bestellung aber noch den bisherigen Ansatz verwenden (Daten werden in Arrays gespeichert.) In der Tat! Das gefährliche für Gambio dabei ist aber m.E.: die Migration meiner Module in die neue Gambio-Welt ist auch nicht wesentlich einfacher als die zu Shopware, OXID oder Magento. Und einer der größten Erfolgsfaktoren der osCommerce-Familie (die Anpassbarkeit des Systems auch durch Nichtfachleute) schwindet, es wird auch ein "Entwickler-Only"-System. .
Auch Dir vielen Dank für Deine Zeit... Wie ich schon bei Nonito geschrieben habe: Spätestens ab Version 2.1 war diese prozedurale Vorgehensweise ja Geschichte, und hat schon sehr viel Flexibilität erlaubt .... Also irgendwie verstehe ich das fast als Drohung... Das trifft aber doch nur auf die Standard-Daten zu.... Bei Änderungen/Erweiterungen fangen dann die Klimmzüge an... Also mit neuen Technologien habe ich prinzipiell keine Probleme. Im Laufe meines beruflichen Lebens habe ich so ca. 5 massive Technologiewechsel in der IT durchlebt (und durchlitten)... Na, eigentlich nicht... Weil die Generierung des bisherigen klassischen "order"-Objekts (new order) ja nicht viel Zeit benötigt. Der Rest wird in dem order-Objekt der GXEngine verbraten.. (Wobei man das klassische "order"-Objekt doch gar nicht mehr braucht, da dessen Daten im weiteren gar nicht mehr genutzt werden, und auch nicht in der DB landen..) Ja das konntest Du. Als "Totgeburt" habe ich die nicht betrachtet, eher als massiven Overkill.
Unter http://www.gambio.de/forum/threads/sendorderprocess.26835/#post-225360 hatte ich ja das Problem, eine nicht-standard-Lieferadresse in eine Bestellung einzuschleusen und meine Lösung dazu mit der GXEngine beschrieben. Muss das so kompliziert sein, oder liegt das an meiner noch ziemlichen Unkenntnis der GXEngine? Ich habe einfach den normalen Prozess der Lieferadressenermittlung debugged, und für meinen Bedarf nachgebildet...
Ich fürchte, wir reden gerade von unterschiedlichen Anwendungsfällen. Mein Beispiel beschrieb den Fall "Entwickler will unabhängig(!) vom Checkout eigene Bestellungen erzeugen". Dein Beispiel beschreibt glaube ich den Fall "Entwickler will im(!) Checkout das Erzeugen einer Bestellung beeinflussen". Beides total sinnvolle und häufige Anliegen, sind aber verschiedene Sachen. Deine angeregte Methode "add_order_data" war für deinen Fall echt super! Darum hatten wir die auch übernommen. Die hilft aber nicht weiter, wenn man Bestellungen außerhalb des Checkouts erzeugen möchte wie bei Imports oder Synchronisationen. Ja das wäre echt toll, wenn du deinen aktuellen Fall einmal konkret beschreiben könntest. Ich bin zwar wirklich davon überzeugt, dass die neuen Konzepte durchaus vorteilhafter sind, aber wenn da im Detail noch wichtige Sachen fehlen oder nicht ausreichend verständlich beschrieben sind, dann hat da ja niemand etwas von. Von daher freue ich mich, wenn wir über deinen Fall einmal gemeinsam drübergucken könnten.
Da hast Du allerdings Recht.... Meine Sicht der Dinge betrifft den Fall, dass ich einen bestehenden Gambio Shop erweitern/ändern muss.
Das ist der zentrale Punkt... Es fehlen einfache Methoden in der GXEngine, um im Shop z.B. die orders im normalen Ablauf zu ändern oder zu erweitern. Oder ein Mail-Attachment anzuhängen.... Was aber m.E. 99% der Anforderungen sein dürften. (Von den anderen Möglichkeiten profitieren Dinge wie WaWis, Magnalister, usw...) Es fehlen mir bei den orders die GXEngine-Äquivalente zu Code: $this->add_order_data($t_sql_data_array); $this->add_order_product_quantity_data($t_sql_data_array, $p_products_array); $this->add_order_total_data($t_sql_data_array, $this->order_totals_array[$i]); $this->add_order_status_history_data($t_sql_data_array); $this->add_product_data($p_products_sql_data_array, $p_products_id); $this->add_order_product_data($t_sql_data_array, $p_product_array); $this->add_special_data($t_sql_data_array, $t_special_array); $this->add_product_attribute_data($t_sql_data_array, $p_attribute_array); $this->add_order_product_attribute_data($t_sql_data_array, $t_attributes_array); $this->add_order_product_download_data($t_sql_data_array, $t_attributes_array); $this->add_tracking_data($t_sql_data_array, $t_customers_logon_array); (und vielleicht noch andere). Ich habe zwar meine Probleme auch so lösen können, aber ich muss dazu viel zu viel über die Struktur und Abläufe der GXEngine wissen (zumindest nach meinem jetzigen Kenntnisstand). Eines möchte ich aber auch noch sagen: technisch ist die GXEngine ein Sahnestück. Diejenigen, die das konzipiert und implementiert haben (und auch verstehen ), genießen meine volle Hochachtung... Gibt es eigentlich Generatoren, die diese ganzen Klassen, Setter, Getter usw. generieren, oder ist das alles Handarbeit?
Wir arbeiten mit PHPStorm als IDE. Da gibt es die Möglichkeit zu Klassenvariablen Getter und Setter zu generieren. Aber so oft nutze ich das gar nicht selbst, da das relativ schnell getippt ist. Die meiste Zeit geht da eher für die beschreibenden Kommentare drauf . Wenn wir in dieser Diskussion weiter kommen wollen brauchen wir ein konkretes Beispiel, was an Daten zu einer Bestellung gespeichert werden soll. Mit dem Order-Service können zu einer Bestellung oder zu Artikeln einer Bestellung OrderAddonValues bzw. OrderItemAddonValues gespeichert werden, so dass eben zusätzliche Daten auf sehr einfache Art und Weise ohne Anpassung der Struktur oder Abläufe hinzugefügt werden können. Ob das im Konkreten ausreichend ist, können wir hier gerne schauen.
Ein konkretes Beispiel: http://www.gambio.de/forum/threads/ueber-den-unsinn-der-gxengine.27067/#post-225842 Das mit den "Addon-Values" geht relativ einfach... EDIT: Dieser konkrete Themenkreis gehört auch noch dazu:
Wir arbeiten seit einigen Wochen fleißig an GX 3.3. Da haben wir bisher nicht die Zeit gefunden hier zu antworten. Da das in dieser Woche nicht besser wird, schaue ich mir das jetzt genauer an. Ich lese mich mal in das Adress-Beispiel ein...
Hier gehts mit dem konkreten Beispiel weiter: http://www.gambio.de/forum/threads/sendorderprocess.26835/#post-225360