Hallo! Erst einmal vielen Dank für eure tolle Arbeit! Mit dem GX3 hat sich ja wieder extrem viel getan und Vieles ist besser geworden. Es wäre prächtig wenn sich die Seiten nicht ständig neu laden müssten. Bei vielen Änderungen die zB in der Artikel-Liste gemacht werden können, lädt sich die Seite immer neu. Jeweils 2-3 Sekunden Pause bei einigen Änderungen (zb Artikel Aktiv/Inaktiv) lähmt den ganzen Arbeitsprozess. Wäre super wenn hier in den nächsten Updates mehr AJAX eingesetzt werden könnte - das würde das Administrieren flüssiger machen. Beste Grüße, Martin
Hallo Martin, Gmbio will den ganzen alten Daten-Müll los werden und hat dafür den Grundstein gelegt. Die einzelnen Seiten / Bereiche werden jetzt nach und nach neu gemacht. Die Seite "Bestellungen" ist z.B. schon fertig und läuft auch recht flott.
Aus Entwicklersicht ist das Problem nur, dass fast der gleiche Lernaufwand notwendig wird, als wenn man sich z.B. mit Shopware oder OXID befasst. Wobei Gambio derzeit ein bewegliches Ziel ist, weil sich alle naselang wieder was ändert.
Im Moment ist es für Entwickler sicher schwierig, aber wenn Änderungen langfristig einfacher und updatesicher eingefügt werden können (was ich als nicht - Entwickler hoffe ) sollte es irgendwann einfacher und übersichtlicher werden. Zumindest hat Gambio jetzt auch eine Dokumentation angefangen...
Das Ziel ist richtig, wir sind auch auf dem Weg dahin. Wir werden Seite für Seite alle Seiten im Backend neuimplementieren, um unter anderem das zu erreichen. Die Bestellübersicht hat das jetzt hinter sich, weitere kommen. Ich glaube mit der GXEngine bauen wir gerade etwas, was relativ schnell zu verstehen und zu erlernen ist. Es ist aber richtig dass man einmal umdenken muss, wenn man gedanklich noch beim Universum von 2008 ist. Die alten Muster sind nicht mehr alle gültig, das technische Ziel ein anderes. Das nennt man Innovation
Im Moment betrachte ich die GXEngine als maßlosen Overkill.... Gambio war auf einem guten Weg, die alte mit der neuen Welt zu verheiraten.... Mit der GXEngine jedoch wird aber m.E. die Usability (aus Entwicklersicht) auf dem Altar der reinen OOP-Lehre geopfert. Innovation ist gut, und dem Stand von 2008 bin ich lange entwachsen. Zu Deiner Information: eine erste Implementierung eines Overload-Konzepts bei Erscheinen von Gambio GX2 stammt von mir (inspiriert durch das OXID-Konzept). Also erzähl mir nix von Weiterentwicklung und lernen!
"aber wenn Änderungen langfristig einfacher und updatesicher eingefügt werden können" Genau das ist mein Problem: es wird m.E. nicht einfacher sondern nur viel unübersichtlicher! Wenn man mal einen Ablauf debugged um zu sehen, wie die Prozesse so ablaufen (um z.B. updatesicher ein Mail-Attachment anhängen zu können), wird man ganz schwindelig bei den vielen Klassen die da durchlaufen werden... Was ja auch viele Schichten Software bedeutet, die da durchlaufen werden müssen. Und besonders beunruhigend: der aktuelle Code weist teilweise schon darauf hin, dass das bald alles wieder ganz anders werden wird. Da kann man als Entwickler eigentlich nur noch die weiße Fahne hissen.
Ok, reden wir: Aus unserer Sicht ist der jetzige Code schrecklich unübersichtlich. Beispiel, jemand sagt: " "Wenn ich Attribute und Staffelpreise gleichzeitg verwende, rechnet der Shop 10% Steuer aus Kirgisien auf meine Rabattkoupons. " Wenn so ein Ticket kommt, rennen alle Leute hier ganz schnell weg. Ein Problem bei der Preisfindung heisst debuggen der XtcPrice Klasse im Shop. Das ist 1100 Zeilen purer Spaghetticode. Und wenn man dort irgendwo eine Zeile ändert, weiss man oft nicht exakt genau wo das Seitenwirkungen hat. Das Ding kann man auch nicht automatisiert testbar machen, was die Wahrscheinlichkeit das ein Fix den wir machen 5 neue Bugs auslöst einfach immer erschreckeckend hoch hält. Das ist kein Theoretikum, das ist Erfahrung, wir sind alle etwas ehrfürchtig vor dem Ding und einigen anderen "erprobten" Sachen. Was machen wir jetzt: Wir zerlegen Monsterfunktionen mit 500 Funktionen auf einmal in 500 einzelne Bausteinchen. Das sind echt viele, ja. Aber jedes dieser Bausteinchen hat dann genau eine Funktion und ist damit automatisiert testbar. Das ist komplett grossartig und purer Luxus! Wenn jemand eine Funktion der neuen Engine ändert, erweitert, umprogrammiert oder optimiert, läuft anschliessend eine Testsuite über die Engine. Das passiert jeden Tag einige male, so oft wie Änderungen aus der Entwicklung kommen, und das passiert eben in vielen Steps. Wenn nun eine Änderung für eine Fehlfunktion sorgt, also irgendein Test gegen irgendeine Mikrofunktion schief geht, bekommt der Entwickler eine Mail. Grober Sinninhalt: Du hast es kaputt gemacht. Und das früh erkennen können, heisst Updates und Module mit weniger Problemen ausliefern können. Diese Tests kann auch jeder externe Entwickler mit GIT Zugang bei sich laufen lassen, das ist ein ganz warmer Tipp. Dazu kommt die neue Erweiterbarkeit: Entwickler sagt: Ich will bei der Addition von Eigenschaften den Sonnenstand miteinbeziehen, morgens gibts Dunkelheitsrabatt. Bisher hiess das eben "Ich muss die Gesamtpreisrechnung anfassen". Das birgt das Potenzial, gerade für Anfänger, mit den Änderungen andere Funktionalitäten grundlegend schachmatt zu setzen. Die Eigenschaften rechnen dann richtig, aber nicht ganzzahlige Artikelmengen gehen plötzlich nicht mehr. Grosser Käse, schwer zu finden, noch schwerer zu lösen. Wir sagen jetzt in Zukunft: Dann fass die Preisfindung für die Eigenschaften an. Die sind isoliert für sich, das hat keine besonderen Nebenwirkungen mehr. Und es sind 50 Zeilen Code die man verstehen muss, statt 1100, das reicht. Ich verstehe nun wenn jemand sagt: Das sind plötzlich 10000 Dateien, vorher waren es 12. Richtig, das ist die logische Konsequenz. Das sieht nach viel aus, richtig. Man muss auch mal in ein Klassendiagramm schauen, das hilft. Den Pfeilen folgen zeigt aber ziemlich schnell wo der Hammer hängt, das kann sogar ich, und ich mach das nicht jeden Tag, ich bin kein Kernentwickler. Soviel zur groben Vision. Damit erklärt sich nun: Genau das behaupten wir. Altes Denken vs neues Denken. Altes Denken: "Ich habe wenige Klötze mit allen Funktionen. Ich muss jeden genau verstehen, damit ich entwickeln kann". Neues Denken: "Ich lasse die kleinen Klötzchen die mit meinem Problem nichts zu tun haben einfach liegen, und kucke mir die wenigen Spezialklötze zu meinem Problem und 10 andere Klätzchen rundrum an. Wenn ich die angepasst oder erweitert habe, quellen meine Daten durch bis an die Oberfläche." Das ist exakt das Modell. Das kann ich dir beantworten wenn du sagst wo du bist. Wenn es um den Code zur Preisfindung und den Checkout geht, dann ja. EIn Teil der Probleme, die wir abschaffen wollen hab ich oben genannt. Es sind noch einige mehr, die mit dem jetzigen Code nicht lösbar sind ohne trotzdem allen größte Schmerzen zu erzeugen. Und das dann auch noch immernochmal und immernochmal wieder, denn die alte Architektur wird ja auch nicht besser. Das wäre auch nicht cool. Für genauere Angaben bitte konkrete Baustellen. Haben wir früher auch schon mal son bisschen über das Gesamtkonstrukt gedacht. Wie kriegt man das Fossil in die Gegenwart und vor allem auch fit in die Zukunft? Wir waren damit im Rückstand, und das Problem sah gross aus. Wir haben trotzdem einfach mal angefangen das zu machen, das war vor einigen Jahren. Mit der Firmengrösse und den Erfolgen der Aktionen, wuchs auch der Anspruch an uns selbst, das nicht halbgar sondern richtig zu machen. Wir reden immernoch über Altleichen die es gibt, aber wir haben an vielen Stellen inzwischen einen guten und modernen Stand. Es gibt andere die da kein Stück mehr besser sind als wir, aber den Vorwurf der Altleichen nicht mit sich herumschleppen. Auch nochmal deutlich: Xtc3 Kompatibilität ist kein grosses Argument mehr für irgendetwas, das gehört so gut wie überhaupt nicht mehr zum Zukunftsplan. Xtc3 genügt gegenwärtigen Ansprüchen echt nicht mehr, und sanfte Verbesserungen daran reichen nicht aus, das brauchte eine Rosskur, und wir fühlen uns gut im Rennen. Nochmal konkret: Wir haben ein eigenes Produkt. Wer ein Xtc3 und Gambio gleichzeitig Modul für irgendwas bauen will, wird einen gehörigen Spagat machen und sich dabei vorhersehbar und absehbar verletzen. Als Entwickler hat man also die Wahl abzubiegen in unsere Spur oder beim alten Kram zu bleiben, oder man macht 2 Entwicklungen.