Ankündigung

Einklappen
Keine Ankündigung bisher.

Code wird zu komplex - Codedesign?

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Such mal nach der PHP Workflow Engine von Sebastian Bergmann, da definierst du deine Schritte durch Regeln und kannst so auch einfach welche überspringen.
    actra.development - Zend Certified Engineer for PHP5 - actra-oss @ github

    Kommentar


    • #17
      Zitat von paddelboot Beitrag anzeigen
      Das größte Problem für mich ist, dass ich einen Kern-Code habe, der durch die ganzen Regeln und Spezialfälle aufgesplittert wird. Ich müsste stattdessen einen mehr oder weniger fest definierten (und abstrahierten) Kern-Code haben, den ich durch Regeln und Sonderfälle erweitern kann. Ein Template würde also nicht mehr durch include() geladen, sondern durch eine Funktion, die vor dem include noch prüfen müsste, ob irgendwelche Regeln registriert wurden. Nach diesem Schema müsste sich dann sämtliche Logik aufbauen lassen, also auch bei der Berechnung des Produkts usw.
      Ich würde da so vorgehen, erstmal die URLs der Einzelnen Schritte aufteilen. Aktuell klingt es für mich so, als ob du immer die gleiche php aufrufst und je nach dem was bei ?step= was anderes anzeigst. Dadurch hast du in einer PHP Datei zu viel Logik.

      Ich würde diese PHP Datei in 3 Dateien Kopieren und in jeder Datei einzeln den Step rausschmeißen. Dann hast du zb meineFormStep1.php meineFormStep2.php und meineFormStrep3.php und jede tut was anderes.

      Anschließend empfehle ich dir PHPStorm zu nutzen, dieser hat ein "Compare with Clipboard" feature. Du kannst dann den Inhalt meineFormStep2.php kopieren und den Inhalt von meineFormStep1.php markeieren und dann vergleichen. Teile die Gleich sind würde ich in eine formFunctions.php erstmal auslagern.

      Zitat von paddelboot Beitrag anzeigen
      Die Kunst dabei ist abzuschätzen *welche* Bausteine *wie* flexibel sein müssen.
      Ich habe mir selbst oft selbst in den Bein Geschossen weil ich immer dachte "Was ist aber wenn man das und dies möchte" letztendlich habe ich dann sehr viel Zeit an unnötiger Flexibilität vergeudet, bei features die keinen Interessieren. Wichtig erstmal, der Code soll einfach veränderbar sein, nutze auch gerne lange variable namen, damit du es besser lesen kannst. Nutze kommentare nur bei dingen die man nicht sofort lesen kann, zb reguläre ausdrücke. Wenn du dann irgendwann die Aufgabe bekommst "Kunde möchte sein Formular Workflow per Drag und Drop zusammenklicken können mit Abhängingkeiten etc" dann stecke deine Energie rein
      apt-get install npm -> npm install -g bower -> bower install <package> YOLO https://www.paypal.me/BlackScorp

      Kommentar


      • #18
        Zitat von BlackScorp Beitrag anzeigen
        Ich würde diese PHP Datei in 3 Dateien Kopieren und in jeder Datei einzeln den Step rausschmeißen. Dann hast du zb meineFormStep1.php meineFormStep2.php und meineFormStrep3.php und jede tut was anderes.
        Grundsätzlich ist das sinnvoll. Ich denke, ob man den Code in Klassen, Methoden oder Dateien (oder alles zusammen, so wie ich) aufteilt, hat am Ende einen ähnlichen Effekt. Wirklich helfen tut es nicht gegen das Problem, das ich in diesem Fall habe. Nach jeder Änderungsrunde durch den Kunden müsste nämlich der Code neu strukturiert und umgebaut werden, und genau das will ich ja vermeiden.

        Edit: zum Thema Workflow-Engine habe ich einige interessante Dinge entdeckt;

        https://www.infoworld.com/article/26...velopment.html
        https://omniworkflow.com/ (für WordPress)
        http://mamchenkov.net/wordpress/2017...kflows-in-php/
        http://bpmn.io/

        Doch ich sehe noch 2 Probleme:

        a. Es ist immer noch nicht klar, was eine Workflow-Engine genau ist bzw. was sie in der Webentwicklung eigentlich nützt. Kann das jemand kurz & anschaulich erklären?
        b. Steile Lernkurve, d.h. ein komplexes System implementieren, um einen komplexen Code in den Griff zu bekommen.

        Kommentar


        • #19
          Zitat von paddelboot Beitrag anzeigen

          Grundsätzlich ist das sinnvoll. Ich denke, ob man den Code in Klassen, Methoden oder Dateien (oder alles zusammen, so wie ich) aufteilt, hat am Ende einen ähnlichen Effekt. [...]
          Nicht ganz. Das eine ist in der Anwendung begrenzt ("Dateien") und das andere lässt sich sehr modularisiert aufbauen (Klassen).

          Ob du eine Workflow-Engine einsetzt oder nicht, das mag eine andere Diskussion sein. Der Symfony Form Builder ist z.B. auch sehr mächtig. Damit könntest du dynamisch Formulare generieren und die Daten generisch (z.B. als JSON) abspeichern. Die heutigen DB-Systeme können auch damit umgehen (JSON mittels "XPath" oder ähnlichen durchsuchen). Du kannst auch Voter, Event Subscriber und ähnliches einbauen, um je nach Input einen anderen Output (Zwischenschritt, ...) einzubauen. Validierung lässt sich auch sehr einfach erreichen und dynamisch generieren.

          Oder, um eine ganz andere Ebene aufzugreifen (um vom Code wieder zum Prinzip zu kommen). Du könntest eine Process Engine einsetzen, die BPMN ausführen kann. Bei den meisten Process Engines lassen sich mittels REST Softwaresysteme anhängen, auf denen dann Aktionen ausgeführt werden können. Das hätte den Vorteil, dass du in BPMN all diese Fälle modellieren kannst. Signavio könnte hier ein mögliches Produkt sein.

          GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken - Vagrant AMPP-Stack (Apache, MySQL, PHP, PgSQL), fully configured

          Kommentar


          • #20
            Hallo,

            ich hätte dir auch zu der Symfony Form Komponente geraten, denn wie bereits erwähnt, bist du damit flexibel. Eine komplette grafische Workflow Engine, wo sich zum Beispiel der Kunde sein Formular anhand von Diagrammen modellieren kann, halte ich für übertrieben, bzw. für unbezahlbar für einen Kunden. Würden wir hier von einer Standardsoftware reden, die hunderte Kunden bedient, dann würde ich klar den Diagramm Workflow nehmen. Da es aber eher eine Einzelumsetzung ist, würde ich auf die Symfony Form Komponente setzen. Konfigurieren mit all deinen Regeln kann man das dann ja zum Beispiel mit einer JSON Datei oder Regeln aus einer Datenbank (Datenbankmodell mit mehreren Tabellen).

            Was eine Workflow Engine ist, wird dir auch niemand genau erklären können. Das ist eine weitläufige Definition für ein Stück Software. Und je nachdem welche Engine du dir anschaust, können die auch verschiedene Dinge. Eine mir bekannte Engine durch Codeproject ist Wexflow. Nettes Tool, wenn man einen CRM Ablauf braucht...

            PS: Für deinen Anwendungsfall dürfte auch das Container Pattern interessant sein und die damit verbundenen Services. Schonmal darüber nachgedacht deine Kern Klassen in Services auszulagern und so unabhängig zu gestalten?


            MFG

            derwunner

            Kommentar


            • #21
              Zitat von derwunner Beitrag anzeigen
              Hallo,

              ich hätte dir auch zu der Symfony Form Komponente geraten, denn wie bereits erwähnt, bist du damit flexibel. Eine komplette grafische Workflow Engine, wo sich zum Beispiel der Kunde sein Formular anhand von Diagrammen modellieren kann, halte ich für übertrieben, bzw. für unbezahlbar für einen Kunden. Würden wir hier von einer Standardsoftware reden, die hunderte Kunden bedient, dann würde ich klar den Diagramm Workflow nehmen. Da es aber eher eine Einzelumsetzung ist, würde ich auf die Symfony Form Komponente setzen. Konfigurieren mit all deinen Regeln kann man das dann ja zum Beispiel mit einer JSON Datei oder Regeln aus einer Datenbank (Datenbankmodell mit mehreren Tabellen).

              Was eine Workflow Engine ist, wird dir auch niemand genau erklären können. Das ist eine weitläufige Definition für ein Stück Software. Und je nachdem welche Engine du dir anschaust, können die auch verschiedene Dinge. Eine mir bekannte Engine durch Codeproject ist Wexflow. Nettes Tool, wenn man einen CRM Ablauf braucht...

              PS: Für deinen Anwendungsfall dürfte auch das Container Pattern interessant sein und die damit verbundenen Services. Schonmal darüber nachgedacht deine Kern Klassen in Services auszulagern und so unabhängig zu gestalten?


              MFG

              derwunner
              Ich habe bisher noch kein einziges Framework für Formulare in PHP gesehen, das flexibel genug wäre, um wirklich alle Kundenwünsche zu ermöglichen. Normalerweise ist man immer irgendwo eingeschränkt in der Umsetzung. Pixelgenaues responsives dynamisch bestückbares duplizierbares AJAX-Select-Feld mit Tooltip? Das ist in meinen Projekten eine typische Anforderung, und das geht am Ende meist nur, wenn man den Code selber schreibt. Zumindest ist das meine Erfahrung.

              Verstehe nun auch ansatzweise, warum hier alle Workflow Engines erwähnen, aber es niemand erklären mag - wäre vermutlich ohnehin viel zu komplex geworden.

              Kommentar


              • #22
                Zitat von paddelboot Beitrag anzeigen

                Ich habe bisher noch kein einziges Framework für Formulare in PHP gesehen, das flexibel genug wäre, um wirklich alle Kundenwünsche zu ermöglichen. Normalerweise ist man immer irgendwo eingeschränkt in der Umsetzung. Pixelgenaues responsives dynamisch bestückbares duplizierbares AJAX-Select-Feld mit Tooltip? Das ist in meinen Projekten eine typische Anforderung, und das geht am Ende meist nur, wenn man den Code selber schreibt. Zumindest ist das meine Erfahrung.
                Pixelgenaues responsive Design ist CSS Sache, damit hat erstmal das Formular selbst nichts zu tun. Aber auch hier bietet Symfony viele Möglichkeiten das Formular schon semantisch halbwegs so zu gestalten, wie man es am besten braucht. Natürlich ist die Komponente um eigene Späße erweiterbar. Hier stehts eigentlich schon wie es geht (einfach eigene Klasse für die UI Komponente anlegen): https://symfony.com/doc/current/comp...-a-simple-form

                Kommentar


                • #23
                  Den Ansatz mit der Workflow-Engine halte ich auch für den richtigen Weg.
                  In Verbindung mit Form-Komponenten aus Frameworks, eventuell. Zumindest meine Kollegen haben damit gute Erfahrungen gemacht, es muss aber auch zu den Anforderungen passen, da gebe ich dir Recht.

                  Dabei ginge es dann darum zu definieren in welchem Fall ein Formular-Element X angezeigt werden soll.

                  Als Beispiel aus meinem Browsergame:
                  Bei der Charaktererstellung gibt es verschiedene Stufen.
                  1. Personendaten
                  2. Vorteile und Nachteile wählen
                  3. Fraktion wählen
                  4. Klasse wählen
                  5. Klassenspezifische Attribute wählen

                  Die Voraussetzungen um zur nächsten Stufe sind straight forward, "du musst auf dieser Seite alles ausfüllen".
                  Aber beim "weiter" gehen wird im Hintergrund dann ausgewählt was für Optionen dem User als nächstes zur Verfügung stehen.

                  - wenn man bei den Personendaten sagt der Charakter ist 17 Jahre alt bekommt man nicht angezeigt, dass es einen Vorteil "Altersweisheit" gibt
                  - wenn man als Herkunft Asien angibt bekommt man keine Klassen angezeigt die einen strikt europäischen oder amerikanischen Sitz haben
                  - wenn man als Nachteil "bettelarm" auswählt kann man keine Klasse wählen die von Natur aus reich ist
                  - als Fraktion "normaler Mensch" kann man keine klassenspezifischen Attribute für Magier auswählen, oder nur in geringerer Ausprägung
                  ...

                  Hinter so etwas muss nichtmal eine umfangreiche oder komplizierte Engine stehen (oben beschriebenes ist sehr simpel), du musst nur die Voraussetzungen und Reihenfolgen definieren und die bisherigen Eingaben entsprechend auswerten.
                  Relax, you're doing fine.
                  RTFM | php.de Wissenssammlung | Datenbankindizes | Stay fit

                  Kommentar


                  • #24
                    Zitat von derwunner Beitrag anzeigen

                    Pixelgenaues responsive Design ist CSS Sache, damit hat erstmal das Formular selbst nichts zu tun. Aber auch hier bietet Symfony viele Möglichkeiten das Formular schon semantisch halbwegs so zu gestalten, wie man es am besten braucht. Natürlich ist die Komponente um eigene Späße erweiterbar. Hier stehts eigentlich schon wie es geht (einfach eigene Klasse für die UI Komponente anlegen): https://symfony.com/doc/current/comp...-a-simple-form
                    Ich habe noch kein Framework gesehen, das mir in der visuellen Umsetzung 100% Freiheit lässt, und daher ist es eben nicht nur eine CSS-Sache. Layoutgestaltung fängt mit dem DOM/HTML an, und das wird serverseitig erzeugt, sprich: durch das Framework.

                    Ich finde Frameworks toll, deshalb arbeite ich ja auch seit Jahren damit, sei es im Frontend- oder Backendbereich. Wenn ich also für einen bestimmten Anwendungsfall auf ein Framework verzichte, ist es deshalb, weil das Wort "Frame"work bereits die Limitierung anzeigt; man muss nämlich immer innerhalb eines gewissen "Rahmens" entwickeln, auch wenn er bei sehr guten Frameworks noch so weit gezogen ist. Je spezifischer die Anforderungen, desto schneller stößt man an die Grenzen von modular vorgefertigtem Code. Bei Projekten, wo die Komplexität erwartungsgemäß durch die Decke geht, schätze ich normalerweise die Freiheit und Flexibilität von eigenem Code. Meine Frage war also nicht, welches Framework ich verwenden kann oder soll, sondern wie ich meinen selbstgeschriebenen Code strukturieren könnte.

                    Kommentar


                    • #25
                      Zitat von paddelboot Beitrag anzeigen
                      Ich finde Frameworks toll, deshalb arbeite ich ja auch seit Jahren damit, sei es im Frontend- oder Backendbereich. Wenn ich also für einen bestimmten Anwendungsfall auf ein Framework verzichte, ist es deshalb, weil das Wort "Frame"work bereits die Limitierung anzeigt; man muss nämlich immer innerhalb eines gewissen "Rahmens" entwickeln, auch wenn er bei sehr guten Frameworks noch so weit gezogen ist. Je spezifischer die Anforderungen, desto schneller stößt man an die Grenzen von modular vorgefertigtem Code. Bei Projekten, wo die Komplexität erwartungsgemäß durch die Decke geht, schätze ich normalerweise die Freiheit und Flexibilität von eigenem Code.
                      Da muss ich dir widersprechen: Ich habe noch keine Anforderung gesehen und / oder selbst umgesetzt, die nicht auf Symfony mit Doctrine passen würde. Wenn man jetzt mal von einer normalen Applikation mit relationaler Datenbankanbindung ausgeht. Und da waren schon ziemlich komplizierte Dinge dabei, wie z. B. eine komplette Produktionssteuerung mitsamt dessen Workflow. Das sollte den Horizont von deiner Formularbastelei weit übersteigen. Wenn man da Frameworks ohne Probleme einsetzen kann, dann sollte es erst recht für deinen Fall gehen.

                      Außerdem zu sagen, dass einem die HTML Struktur eines Frameworks bei der responsive Anpassung stören würde, ist in meinen Augen nur eine müde Ausrede... Man kann diese schließlich ebenfalls auf seine Bedürfnisse anpassen. Und ich denke nicht, dass du mit was eigens gebasteltem schneller bist, als eine vorhandene minimal auf deine Bedürfnisse anzupassen.

                      Kommentar


                      • #26
                        Zitat von paddelboot Beitrag anzeigen
                        Meine Frage war also nicht, welches Framework ich verwenden kann oder soll, sondern wie ich meinen selbstgeschriebenen Code strukturieren könnte.
                        Hast du denn bereits die Anforderungen definiert oder ein grobes Konzept?

                        Kommentar


                        • #27
                          Zitat von paddelboot Beitrag anzeigen
                          (..) Meine Frage war also nicht, welches Framework ich verwenden kann oder soll, sondern wie ich meinen selbstgeschriebenen Code strukturieren könnte.
                          Structurieren ohne Rahmen, aber mit PSR-x Compabilität ?
                          Oder ist das dann auch zu eng ?

                          Kommentar


                          • #28
                            Zitat von paddelboot Beitrag anzeigen
                            [...]
                            Ich habe noch kein Framework gesehen, das mir in der visuellen Umsetzung 100% Freiheit lässt, und daher ist es eben nicht nur eine CSS-Sache. Layoutgestaltung fängt mit dem DOM/HTML an, und das wird serverseitig erzeugt, sprich: durch das Framework.
                            [...]
                            Wird serverseitig erzeugt? Kann, ja. Muss allerdings nicht. Du kannst HTML auch vollständig Client-seitig erstellen lassen mit irgendwelchem JS-Framework oder auch von Hand. Und dann bleibst du in deiner Gestaltung völlig frei. Der Einsatz eines Form-Frameworks dient dann nur zur Vereinfachung der API, und da nimmt dir z.B. Symfony Forms mit der Validierung und dem Mapping (und dem CSRF-Token) einiges an Arbeit ab. Darauf möchte ich persönlich nicht verzichten.
                            GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken - Vagrant AMPP-Stack (Apache, MySQL, PHP, PgSQL), fully configured

                            Kommentar


                            • #29
                              Hallo,

                              und wenn du das Formular on the fly erstellst? So dass in einem Fall vier und in einem anderen nur drei Schritte vorhanden sind?! So liefert das Backend jeweils ein Formular zurück, das auf deine Anforderungen und für die ausgewählten Formulareinstellungen passt.
                              Viele Grüße

                              Dirk

                              Kommentar


                              • #30
                                Zitat von lottikarotti Beitrag anzeigen
                                Hast du denn bereits die Anforderungen definiert oder ein grobes Konzept?
                                Darum geht es doch - der Kunde weiß selber nicht, wie genau sich die App noch weiter entwickeln wird. Also kann ich auch nicht einschätzen, welche "Bausteine" in Zukunft modifizierbar sein müssen. Daher habe ich mich entschloßen, die App neu aufzubauen - auf Grundlage eines Frameworks. Ob das jetzt Symfony oder Laravel oder was anderes sein wird, ist noch offen. Dazu muss ich erstmal die Formularkomponenten der Frameworks genauer anschauen. Und natürlich muss der Kunde diesen zusätzlichen Aufwand auch kaufen. Ich setze also quasi meine Murmeln auf ein MVC-Framework, weil ich annehme, damit aus der Sackgasse rauszukommen. Die Workflow-Engine hört sich interessant an, es ist mir aber auch nach Recherche nicht klar genug, wie das abläuft bzw. wie das zu implementieren wäre.

                                Zitat von BLU Beitrag anzeigen
                                Hallo,

                                und wenn du das Formular on the fly erstellst? So dass in einem Fall vier und in einem anderen nur drei Schritte vorhanden sind?! So liefert das Backend jeweils ein Formular zurück, das auf deine Anforderungen und für die ausgewählten Formulareinstellungen passt.
                                Im Grunde darf ich ja von gar keiner festen Anzahl Schritte ausgehen, weil das der Kunde schon mal durcheinandergewürfelt hat, und das auch in Zukunft wieder geschehen kann. Die Anzahl der totalen Schritte ergibt sich außerdem erst aus den Eingaben in den ersten zwei Schritten.

                                Kommentar

                                Lädt...
                                X