Ahoi in die Runde,
Ich bin gerade per Zufall über euer Projekt gestolpert - erstmal Respekt für die Idee! 
Da ich ein paar Kunden betreue die Xentral-Instanzen am Laufen haben, wollte ich mal nachfragen wie im Moment bei euch die Roadmap aussieht.
Ich weiß das Xentral selbst gerade dabei ist seine Codebase auf Laravel neu aufzusetzen. Gibt's da bei euch auch Bestrebungen in die Richtung? Soweit ich weiß ist die Codebase der 20.3 noch ein ziemlich unperformanter Clusterf-...
Also wenn du mich fragst, dann würde ich langfristig sehr gerne auf irgendeine Art Framework (ob nun Laravel, Symfone oder what ever ist erstmal egal) setzen. Aber das ist (wenn es überhaupt durch uns leistbar ist) sicherlich noch in größerer Ferne. Momentan sind wir dabei Funktionalität hinzuzufügen die in der Priorisierung "Show-stopper"/"Must have" liegt, damit OpenXE für viele Anwender nutzbar ist. Ich befürchte, dass diese Phase auch noch mehrere Monate anhalten wird.
Aber wir sollten das auf jeden Fall im Blick behalten. Die Frage ist natürlich auch: Wer kann das machen. Ich habe Erfahrung in Laravel und Symfony, bin aber kein Experte in dem Gebiet. Und man wird ja sicherlich eine gute Zeit lang ein Hybrid-System fahren müssen wie Xentral es mit der 22.x auch schon macht. Also bspw. Laravel Core mit Adaptern auf Legacy-Code. Sowas geht natürlich mit einem Laravel/Symfony-Experten einfacher.
Und ja: Die Codebasis ist ein ziemlicher Haufen von gutem, schlechtem und WTF-Code der aber in großen Teilen funktioniert. Und mit einem kleinen Team sollte man "If it is not broken, do not fix it" ebenfalls in gesundem Maße beherzigen. Ich versuche bei meinen Entwicklungen eine gewisse Modularität im Hinterkopf zu halten und vieles in eigene Module/Libs auszulagern um den Haufen zumindest nicht zu vergrößern 
Okay - "Experte" ist immer so ne Sache. Eventuell hilft es ja, dass ich Schnittstellenentwickler bin, der so ziemlich alles auf Laravel baut... 
Ich hatte mal ein kleines Projekt namens "Xentral-API-Extension", was nur dazu da war einige Datenbanktabellen als Models abzubilden. Eventuell kann man damit ja anfangen. Da muss ich aber schauen wie ich das mit Arbeit, Frau und Kind vereinbaren kann.
Ist aber halt die Frage ob das überhaupt gewünscht ist, zumal halt auch jetzt noch das Problem ist das im Code sich noch Verweise auf Klassen und Dateien befinden die gar nicht existierten (beispielsweise der Verweis auf /www/pages/uebertragungen.php in der api_uebertragungen.php).
Da mal noch als Nebenfrage: Funkt das Übertragungen-Modul hier?
Ich glaub halt auch, dass mit einem Framework auch die Möglichkeiten der Nutzer bedeutend besser sind. So wie es im Moment für mich aussieht (nur durch einen kurzen Blick auf das Projekt) müsste ich gerade jedes mal meinen Custom-Code neu rein schubbsen, sobald da eine Änderung ansteht. Ist halt die Frage ob man sowas lieber eher als später angeht. (Persönlich bin ich da für "eher" in dem Fall, weil man ja den kompletten Quellcode so oder so überarbeiten muss. Da hat man das gleich in einem Aufwasch...)
Danke für die Anregung.
Ich teile im Moment allerdings auch die Meinung von Andi. Mit einem stabilen OpenXE zu starten und dann die wichtigsten Plugins zu integrieren, dürfte zunächst mal die höchste Priorität haben.
Viele kommen ja direkt von Xentral und sind erst mal froh, da rausgekommen zu sein, da liegt der Fokus vermutlich nicht im Wechsel auf ein anderes Framework (mit einer langen Entwicklungsphase, vielen Bugs, usw...).
Lasst uns zunächst eine stabile OpenXE Community aufbauen, dann gibt es auch sehr viel mehr Feedback, was hilft bei der weiteren Entwicklung und ggf. dann auch für das eine oder andere Framework spricht.
Okay - "Experte" ist immer so ne Sache. Eventuell hilft es ja, dass ich Schnittstellenentwickler bin, der so ziemlich alles auf Laravel baut...
Das ist doch super und ich bin mir sicher, dass Du Dich hier auch gut einbringen kannst (egal ob zunächst mit oder ohne Laravel) 
Mit einem stabilen OpenXE zu starten und dann die wichtigsten Plugins zu integrieren, dürfte zunächst mal die höchste Priorität haben.
Viele kommen ja direkt von Xentral und sind erst mal froh, da rausgekommen zu sein, da liegt der Fokus vermutlich nicht im Wechsel auf ein anderes Framework (mit einer langen Entwicklungsphase, vielen Bugs, usw...).
Naja - es geht ja nur um einen Framework-Unterbau für die Codebasis... Da verstehe ich nicht was das mit "von Xentral weg kommen" zu tun hat, als würde Laravel was dafür können was für Software damit gebaut wird.
Ich verstehe allerdings wo die Meinung herkommt.
Allerdings möcht ich da noch folgendes zu bedenken geben: Die wichtigsten Plugins zu migrieren ist eine gute Sache, aber es ist immer die Frage was man als "wichtig" ansieht.
Wenn man ein Hammer ist sieht alles wie ein Nagel aus - in dem Sinne sehe ich die ShopImporter als sehr wichtig an. Doof ist aber bei denen, dass die Systeme dahinter immer weiterentwickelt und geändert werden (Shopify ist da so ein Kandidat...) und dementsprechend muss dann halt auch der OpenXE-Code angepasst werden, womit eine eh schon komplexe Codebasis nur noch komplexer wird und irgendwann blickt da kein Mensch mehr durch. Deswegen auch meine Meinung zum "eher als später".
Noch ein Grund warum es gut wäre das jetzt zu klären ist das kommende Entwickler damit dann auch wissen woran sie sind, zumal man halt auch eben den Parallel-Betrieb den Xentral selbst gerade macht damit auch fahren könnte. Man muss es ja nicht sofort umsetzen, aber kann es sich wenigstens auf die Roadmap packen.
Tatsächlich werd ich wohl diese Woche mal etwas Zeit nehmen und eine Testinstanz von OpenXE aufsetzen, die ich dann mit meinen Kunden mal testen werde. Ich hoffe ja das OpenXE das Replacement sein kann für das ich es im Moment halte.
Mir fehlt hier aber als Neuling in OpenXE gerade so ein bisschen die Ausrichtung des Projekts - eben sowas wie eine Roadmap.
Ich finde die Idee "wir nehmen Xentral und machen das Community-tauglicher" sehr gut, zumal ja (ehrlicherweise) in Xentral auch vieles richtig läuft, aber halt der Maintainer als "fragwürdig" eingestuft werden kann. Aber ich sehe halt nichts im Sinne von "Daran arbeiten wir gerade und das haben wir noch vor." - eventuell fehlt da auch noch etwas Doku?
Versteht mich bitte richtig - ich will hier niemandem Körperflüssigkeiten vor dem Karren parken. Aber es wäre schade wenn das Projekt das "alles besser machen soll" am Ende genau das gleiche wird wie das Original: Viel Hype und dann wirds dünne mit der Zeit.
Ich schlage in die gleiche Kerbe: Eine verbesserte Software-Architektur (mit oder ohne Framework) wäre wünschenswert. Im Sinne von Wunsch. In der Realität müssen wir mit der Büchse produktiv arbeiten und schauen dass wir unsere allerwichtigsten Anforderungen umgesetzt bekommen. Das ist quasi die Roadmap für die nächsten Monate. Da stehen noch Sachen an wie:
Allerdings haben wir überhaupt keine Performance-Probleme, im Gegenteil. OpenXE läuft auf unserem Server gefühlt 10x so schnell wie das Xentral Enterprise 20 mit Ioncube das wir vorher hatten.
Grundsätzlich schlummern in der Codebasis mindestens 4 Generationen von Software die nie migriert wurden und entweder parallel oder verzahnt laufen. Nur so als Anektdote: Ich habe beim Redesign des Ticketsystems 3 verschieden Bibliotheken zum Versenden von Mails gefunden.
Nicht falsch verstehen, ich bin für Aufräumen, aber wenn dann müsste man wahrscheinlich bei Dingen wie der erpapi oder diesem seltsamen class.YUI anfangen. Und das hat noch nichtmal etwas mit Frameworks zu tun, sondern eher mit Grundlagen der Informatik.
Was Deine Frage nach den Schnittstellen angeht, das Übertragungen-Modul gibt es hier meines Wissens nicht. Grundsätzlich könnte man auch überlegen, die Shopschnittstellen auszulagern, um der Dynamik gerecht zu werden.
Auf jeden Fall freuen wir uns natürlich über jede tatkräftige Unterstützung.
Viele Grüße
Alex
Was Deine Frage nach den Schnittstellen angeht, das Übertragungen-Modul gibt es hier meines Wissens nicht. Grundsätzlich könnte man auch überlegen, die Shopschnittstellen auszulagern, um der Dynamik gerecht zu werden.
Oha... Dann haben wir jetzt wohl weitestgehend den Stand "Yo nice, aber solange das Ding nicht nach außen funken bzw. Gefunke von außen nicht versteht, bringt uns das nix." - zumindest jetzt von den Use-Cases her die ich betreue. Da ist Xentral eigentlich eher ne Middleware auf Steroiden (mit den entsprechenden Nebenwirkungen ).
Ich werd mal schauen was sich die nächsten Tage so bei mir ergibt und ob ich da mal was machen kann. (Sofern es mein eigenes Projekt und Familie zulassen...)
Ich möchte es nochmal so formulieren: Ja, ich möchte gerne bald eine solide Basis schaffen (z.B. mit Laravel oder Symfony). Aber wir sind bereits mit OpenXE produktiv und es läuft noch nicht alles so rund wie wir es eigentlich brauchen. Warum? Weil wir von Xentral dazu genötigt wurden und uns für das Ende mit Schrecken als ein Schrecken ohne Ende entschieden haben. Aber ich kann vor niemandem, nichtmal vor meinem IT- und Bastelherz rechtfertigen, dass ich an solchen Umbauten arbeite während wir noch keine Matrixartikel über die UI verwalten können.
Wenn ich mal meine Glaskugel frage, würde sie vermutlich einen Zeitrahmen von etwa 6 Monaten ausspucken in der zumindest ich persönlich noch keine Zeit für solche Umbaumaßnahmen finden werde.
Wenn du als erfahrener Laravel-Entwickler aber eine Idee hast, wie man die Umstellung des aktuellen Codes auf z.B. Laravel sinnvoll angehen sollte, dann bin ich da sehr offen für. Was wären deine ersten Schritte? Was würde man damit bereits "gewinnen"?
Ich möchte es nochmal so formulieren: Ja, ich möchte gerne bald eine solide Basis schaffen (z.B. mit Laravel oder Symfony). Aber wir sind bereits mit OpenXE produktiv und es läuft noch nicht alles so rund wie wir es eigentlich brauchen. Warum? Weil wir von Xentral dazu genötigt wurden und uns für das Ende mit Schrecken als ein Schrecken ohne Ende entschieden haben. Aber ich kann vor niemandem, nichtmal vor meinem IT- und Bastelherz rechtfertigen, dass ich an solchen Umbauten arbeite während wir noch keine Matrixartikel über die UI verwalten können.
Komplett verständlich. Es geht ja auch nicht darum zu sagen, dass man jetzt und sofort loslegt, sondern das man sich jetzt mal Gedanken darüber macht ob man den Umbau machen sollte (was ja eindeutig bisher mit "Ja" beantwortet wurde) und welches Framework genutzt werden soll. Es stehen ja bereits Symfony und Laravel im Raum, aber es gibt ja noch mehr (beispielsweise CakePHP).
Ich persönlich finde Laravel besser, weil es eine größere Userbase hat, auch auf Teile von Symfony aufbaut (beispielsweise Doctrine) womit sich ein Symfony-Entwickler recht schnell reinfinden kann und weil ich es halt nun schon seit Jahren benutze.
Mein Punkt ist halt der, dass durch die jetzige Entscheidung welches Framework es werden soll, man Entwicklern die neu dazu kommen auch die Chance geben kann mit dem Umbau schon loszulegen und beides parallel laufen lassen könnte. Zumal man als Entwickler dann auch eben weiß woran man ist. Das wird Laravel? Cool - da kenne ich mich bereits aus! Das wird Cake-PHP? Okay - da muss ich mich nochmal reinlesen. Das wird Symfony? Och nööö... Eventuell war ich da etwas unklar.
Und der Punkt mit "Weil wir von Xentral dazu genötigt wurden..." - ich fühle mit dir. Von den 10 grauen Haaren die ich in den letzten 5 Jahren bekommen hab, sind 8 Xentral zu verdanken.
Wenn ich mal meine Glaskugel frage, würde sie vermutlich einen Zeitrahmen von etwa 6 Monaten ausspucken in der zumindest ich persönlich noch keine Zeit für solche Umbaumaßnahmen finden werde.
Noch ein Grund mehr das zu nutzende Framework auf die Roadmap zu packen. Ich weiß zum Beispiel, dass ich wohl im Mai etwas Zeit haben werde und eventuell auch schon vorher. Nur ehrlich gesagt möchte ich mich nirgendwo rein committen ohne zu Wissen worauf ich mich dann am Ende einlasse. Wenn ich jetzt sage "Okay, ich forke das Ding mal und hol mal als ersten Schritt eine composer.json rein und mach mir die Mühe die Datenbanktabellen als Models darzustellen." und 3 Monate später wird gesagt "Wir nehmen Cake-PHP." dann waren die ganzen Stunden die ich mit dem Fork verbracht hätte für die Katz. Und da hab ich einfach keine Lust drauf - andere vermutlich auch nicht. Ich red ja nur von Planungen (halt ner Roadmap) und nicht bereits von der Umsetzung.
Wenn du als erfahrener Laravel-Entwickler aber eine Idee hast, wie man die Umstellung des aktuellen Codes auf z.B. Laravel sinnvoll angehen sollte, dann bin ich da sehr offen für. Was wären deine ersten Schritte? Was würde man damit bereits "gewinnen"?
Okay - ohne jetzt viel Zeit in dem Code verbracht und noch keine eigenen Tests zu haben - als erstes würde ich (nachdem man Laravel mit eingebunden hat) auf die Datenbank losgehen. Namentlich würde das bedeuten die Tabellen in Models bzw. Pivot-Relations umzuwandeln und dabei schon zu schauen was man optimieren kann. Gewinnen würde man dadurch in der Hauptsache Übersicht und die ganzen rohen DB-Statements würden rausfliegen, was auch dafür sorgt das man im Code recht gut sehen kann "Wo wird das Model denn überhaupt genutzt?". Dazu könnte man auch das Observer-System von Laravel anzapfen um die ganzen Trigger die Xentral ausführt anzustubsen. Damit meine ich sowas wie "Was passiert codeseitig, wenn ein Auftrag freigegeben wird?". Danach müsste man sich halt den Teppich mal anschauen... Welche Fäden kann man ziehen und umbauen, ohne das der ganze Spaß einem entgegen kommt.
Am Ende stimmen ja alle bereits zu, dass da ein Framework mal irgendwann kommen soll, nur welches wird es den nun? Der erste der sich die Mühe mal macht eins drunter zu legen trifft dann die Entscheidung? Also wenn ich jetzt sofort mit Laravel anfangen würde dann wird es das auch?
Ich frag halt nach einem "Machtwort", denn Alex hat ja schon gesagt, dass da 4 Codegenerationen im bestehenden Code drin sind - bei der Fluktuation an Mitarbeitern die das System aufgebaut haben ist das auch kein Wunder.
Alles klar, danke für deine Ausführungen! Ich glaube dann sind wir gar nicht weit voneinander entfernt.
Ich glaube das mit dem Machtwort lässt sich einrichten, wenn wir Zeit haben uns mit der Fragestellung zu befassen. Ich persönlich hätte von meinem Bauchgefühl z.B. jetzt zu Symfony gegriffen. Vielleicht eignet sich Laravel aber besser?! Oder was ganz anderes?! Ohne das beantworten zu können, kann ich da auch keine Meinung zu abgeben und schon gar kein Machtwort
Vielleicht kannst du uns hier ja etwas unterstützen und ein paar Argumente pro/contra für die verschiedenen Frameworks sammeln. Wenn sich daraus bereits ein klares Bild ergibt, dann ist auch das Machtwort einfach. Wenn es das nicht tut, dann ist es sehr wertvoll nicht voreilig ein "go" in irgendeine Richtung gegeben zu haben.
Für mich persönlich ist zum Beispiel eine große Fragestellung: Wie gut ist es jeweils möglich neue Funktionen bereits auf Basis eines Frameworks zu entwickeln, gleichzeitig aber wenig Folgeanpassungen an altem Code machen zu müssen.
Ich glaube dann sind wir gar nicht weit voneinander entfernt.
Eigentlich überhaupt nicht, aber Armlänge wäre schon nice, bevor es zu touchy wird...
Ich persönlich hätte von meinem Bauchgefühl z.B. jetzt zu Symfony gegriffen. Vielleicht eignet sich Laravel aber besser?!
Hmm Symfony kenne ich bisher eher als "Sammlung nützlicher Projekte", aber nicht wirklich als "Framework" (bitte nicht ernst nehmen - es ist Ewigkeiten her das ich damit zu tun hatte). Laravel und CakePHP bauen aber teilweise auf Symfony auf (Doctrine ist zum Beispiel bei einigen drunter, wobei ich mir aber nicht sicher bin ob das mit Eloquent in Laravel wieder entfernt wurde).
Cake hatte ich mal in der Ausbildung genutzt, aber bin danach durch Wechsel der Firma bei Laravel gelandet.
Ich kann deswegen gerade nur wirklich sauber über Laravel Aussagen machen. Dessen größte Vorteile (meiner Meinung nach) sind:
)Zu der Kiste mit "Wie gut ist es jeweils möglich neue Funktionen bereits auf Basis eines Frameworks zu entwickeln, gleichzeitig aber wenig Folgeanpassungen an altem Code machen zu müssen." -> Ich glaube um einen kompletten Umbau wird man in keinem Framework wirklich herum kommen. Da wäre für mich die bessere Frage: "In wie weit ist das Framework mit der bestehenden Code-Basis kompatibel, sodass man für den Übergang beides parallel laufen lassen kann?"
Das sind nur meine 5 cent dazu - bin mal gespannt was noch von anderen eventuell kommt.
- Die bestehende Codebase kann man einbinden bzw. müsste es möglich sein
- "Xentral selbst nutzt Laravel!" ist für mich jetzt nicht wirklich ein Argument, zeigt aber das sie Laravel zumindest als "wirtschaftlich sinnvoll" ansehen.
- Wenn man sich den aktuellen Code von Xentral anschaut, dann sieht man auch das es zu funktionieren scheint.
Hey,
Naja hier würde ich ehr sagen Sie haben viele PHP Entwickler eingestellt und setzen somit auch auf PHP weiter.
Deren Geschichte fing in PHP an und somit führen Sie es fort.
Ich habe schon vor 2 Jahren gesagt.. Fangt von vorne an. Kleines Team für Bugfix und must have und das andere größere Team komplett neu.
Das Die überhaupt klarkommen mit deren Quellcode "Denglisch"... mal deutsche Begriffe, mal englische...
Ich persönlich hätte es nicht in PHP gemacht, sondern in c# ASP Core Framework dazu hätte ich auch kein MySQL genommen sondern PostgreSQL.
Aber das sind ja nur meine persönliche Wünsche, wenn es um Community geht denke ich ist es am Ende besser PHP zu benutzen, grade im Open Source Bereich und einfacher zu hosten. Kleine Firmen können es selber hosten bei einem XY Hoster.
Ich glaube PostgreSQL ist schon schwer zu finden bei einem normalen deutschen Hoster?
Um eine größere Community aufzubauen, ist dieser Quellcode nicht wirklich eine Basis um mehr contributors zu haben. Hier müsste das ganze Projekt auf Deutsch / Englisch gesetzt werden damit mehr Leute kommen.
Aber erstmal kleine Schritte und dann die großen.
Das sich einige Leute überhaupt zusammengetan haben und hier für die Öffentlichkeit etwas kostenfrei zu Verfügung stellen ist schon ein großer lob. Ich wäre auch dafür das man buy me a coffee spenden kann
Grüße
Jordan .
PHP ist (meiner Meinung nach) nach wie vor eine tolle Sprache und ich sehe ehrlich gesagt keinen Grund warum man hier von PHP weg gehen sollte. Ähnliches gilt für MySQL/MariaDB.
Jedes System und jede Sprache hat ihre Stärken und Schwächen und man wird immer Dinge finden die woanders schöner sind.
Aber für mich kommt es letztendlich darauf an was am Ende dabei raus kommt und das kann man mit PHP+MySQL gut bewerkstelligen.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
