Ankündigung

Einklappen
Keine Ankündigung bisher.

HMVC: APF vs. Kohana

Einklappen

Neue Werbung 2019

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

  • HMVC: APF vs. Kohana

    Hi Leute,

    ich wollte mich mal zum Thema HMVC schlau machen und durch die Google-Recherche bin ich auf folgenden Artikel gestoßen:
    http://www.net-developers.de/blog/20...eren-probleme/

    Nun, da der Autor des APF-Frameworks (dr.e) hier Member ist, dachte ich, er (oder auch andere geneigte Leser) könnte zu den Hauptkritikpunkten Stellung nehmen, die da sind:

    * Es gibt keine Controller ohne Templates
    * Man muss eine neue Sprache erlernen
    * Man kann nur HTML ausgeben, kein XML oder JSON
    * Je nach Zustand des Users ein anderes Template anzeigen. Auch das ist nur sehr schwer möglich.

  • #2
    Hallo hts,

    die Punkte hatten wir - glaube ich - auf phpforum.de schon mal diskutiert. Wenn ich mich recht erinnere ist das im Thread http://phpforum.de/forum/showthread.php?t=255733&page=9 gewesen.

    Der verlinkte Artikel ist für meinen Geschmack ein wenig oberflächlich recherchiert, da er lediglich die Nachteile heraus arbeitet, nicht aber die konzeptionellen Vorteile z.B. einer DSL sieht. Hier meine Antwort/Stellungnahme im Detail:

    * Es gibt keine Controller ohne Templates
    Das ist falsch! Das APF nutzt die Entwurfs-Muster Page-Controller und MVC als Basis für die HMVC-Implementierung. Beide haben ein von der GOF/Martin Fowler definiertes Einsatzgebiet.
    Das Page-Controller-Pattern definiert im wesentlichen einen Rahmen um bzw. einen Einsprungs-Punkt für eine Web-Applikation. Das MVC-Pattern ist zur Granulierung der Präsentations-Schicht gedacht und wird genau in der im Pattern beschriebenen Konstellation von Controller, Model und Template als MVC berzeichnet. Die Forderung nach einem Controller ohne Template ist im MVC- und damit auch im HMVC-Kontext falsch.
    Controller ohne Template sind i.d.R. solche Controller, die lediglich Business-Funktionen ausführen. Suchen wir in unserem Baukasten hierfür nach einem geeigneten Pattern, so finden wir das Front-Controller-Pattern.
    Auch für dieses bietet das APF eine Implementierung, in der es - nach Spezifikation des Pattern - möglich ist, verschiedene Business-Aktionen vor dem Aufbau der Präsentations-Schicht (durch den Page-Controller) Business-Aktionen auszuführen. Diese heißen zwar nicht "Controller" sondern "Action", das Naming ist hier jedoch nicht das entscheidende.

    * Man muss eine neue Sprache erlernen
    Ich denke, der Artikel zielt hier auf die Taglib-Notation ab, denn der Rest ist PHP. APF-Taglibs sind de facto keine neue Sprache, sondern einfach eine XML-Notation die XML-Namespaces mit einbezieht. Wer sich bereits mit XSD-Dateien oder XML-/HTML-Dateien mit Namespaces beschäftigt hat, dem kommt die Notation sicher bekannt vor.
    Sofern in diesem Bereich noch kein KnowHow vorhanden ist, lässt sich die Syntax sehr schnell erklären: der Tag-Name besteht immer aus einem Präfix und einem Klassen-Bezeichner, die per ":" verbunden sind.
    Was ich an diesem Argument etwas schade finde ist, dass die APF-Tag-Notation als sehr negativ dargestellt wird. Sie ist umgekehrt betrachtet das Herzstück des APF und dasjenige Konzept, dass das APF im Bereich der GUI so generisch und erweiterbar macht. Ohne Taglibs wäre keine Abbildung einer HMVC-DOM-Struktur in der geschlossenen und kompakten Form möglich. Ebenso hätte der Entwickler nicht die Möglichkeit in den Aufbau und die Transformation des Baumes einzugreifen. Wer hier mehr wissen möchte, kann sich das Timing-Modell des Page-Controller ansehen.

    * Man kann nur HTML ausgeben, kein XML oder JSON
    Das ist falsch! Die Implementierung der APF-GUI-Komponenten (inkl. Page-Controller und dem Taglib-Konzept) sind nicht an ein Ausgabe-Format gebunden. Es lässt sich mit dem Aufruf eines Document-Controllers, einem Template und auch innerhalb von Taglibs ohne weiteres XML, JSON, YAML, ... erzeugen und ausgeben.
    Einschränkungen ergeben sich lediglich dann, wenn spezielle Taglibs verwendet werden, die auf das Erzeugen von HTML/XHTML zugeschnitten sind (z.B. Formular-Unterstützung). Hier ist die Intension jedoch Programm, denn HTML-Formulare möchte ich z.B. nicht in XML oder JSON abbilden. XML wäre vielleicht noch denkbar, aber hier bewegen wir uns in einem Bereich der konzeptionellen Ausrichtung eines Tools, das auf dem APF-Kern aufsetzt. Der Kern des APF unterstützt definiv unterschiedliche Formate.

    * Je nach Zustand des Users ein anderes Template anzeigen. Auch das ist nur sehr schwer möglich.
    Dieses Argument kann ich nicht nachvollziehen. Durch das Taglib-Konzept ist dem Entwickler jede nur denkbare Möglichkeit gegeben um abhängig von definierten zuständen den Aufbau des HMVC-DOM-Baumes zu beeinflussen. Die einfachste Möglichkeit ist sicher das <core:importdesign />-Tag. Mit diesem kann abhängig von einem URL-Parameter ein anderes Template an derjenigen Stelle in den Baum geladen werden, wo es definiert ist. Nehmen wir an, es wurde im Inhalts-Bereich der Seite definiert, so kann dort für den eingeloggten Benutzer durch ändern eines URL-Parameters ein definierter Inhalt angezeigt werden. Klingt unsicher? Ist es nur dann, wenn im Controller des zugehörigen Templates keine Prüfung stattfindet.
    Ist das hinsichtlich der Prüfung etwas umständlich, schlage ich eine eigene Taglib vor, die von der oben genannten ableitet und an Hand der Benutzer-Informationen (z.B. in der Session) entscheidet ob Template a oder b eingebunden werden soll.
    Eine etwas anspruchsvollere Möglichkeit ist, den Status der Applikation in einem View-Model von einer Front-Controller-Action verwalten zu lassen. Diese füllt das Model mit dem anzuzeigenden Model und der <generic:importdesign />-Tag übernimmt an Hand der Model-Informationen die Einbindung des gewünschtenTemplates.
    Innerhalb dieser Vorgehensweisen gibt es noch einige weitere Nuancen, die zu diskutieren jedoch den Rahmen der Antwort sprengen. Fakt ist, dass es gerade mit dem APF ein leichtes ist, den Aufbau des HMVC-Baumes zu beeinflussen um bestimmte Bereiche abhängig vom Status anders zu befüllen.

    In Summe hast du mit dem APF ein äußerst flexibles und gut erweiterbares Tool in der Hand, das im GUI-Bereich keine Fragen offen lässt. Der Page-Controller stellt einen Rahmen zur Verfügung, der für dich die Verwaltung des HMVC-DOM-Baumes übernimmt und du keine expliziten Abhängikeiten in deinen Controllern verwalten musst (soehe Kohana). Für den Aufbau von deinen GUI-Strukturen hast du ein mächtiges Werkzeug (Taglibs) und jede Menge mitgelieferter Tools (z.B. Formular-Unterstützung), die dich in die Lage versetzen, schnell entwickeln zu können.
    Sofern die Komplexität der Anwendung wächst, kannst du mit dem Front-Controller die Steuerung der Anwendung noch eleganter lösen.

    Ich denke, du solltest dem APF, dessen Code mittlererweile > 6 Jahre im täglichen Live-Einsatz erprobt ist, eine Chance geben. Hier im Forum haben wir beispielsweise einen Vergleich der Formular-Unterstützungen vorgenommen und gerade dort schlägt das Taglib-Konzept die sonstigen Konzepte in Punkto Flexibilität im Längen.
    Viele Grüße,
    Dr.E.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    1. Think about software design [B]before[/B] you start to write code!
    2. Discuss and review it together with [B]experts[/B]!
    3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
    4. Write [I][B]clean and reusable[/B][/I] software only!
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Kommentar


    • #3
      Hallo dr.e.,

      ich danke Dir für Deine umfassende Antwort. Ich hatte auch den Eindruck, dass der Blogeintrag nicht der Weisheit letzter Schluss bzw. subjektives Empfinden ist, darum hatte ich ja hier nachgefragt.

      Fragen hätte ich zwar noch jede Menge, aber da die Materie für mich vorerst noch zu komplex ist, kann ich keine Konkrete formulieren. Dazu müsste ich mich erst intensiver mit dem Thema HMVC auseinandersetzen, wozu mir zum jetzigen Zeitpunkt keine Luft bleibt.

      Daher wollte ich mich hiermit erstmal vorab für Dein promptes Feedback bedanken.

      Kommentar


      • #4
        Hallo hts,

        für fachliche Diskussionen bin ich immer gerne zu haben. Keine Ursache also für die Antwort!

        Das Thema HMVC ist nicht einfach - zugegeben -, aber mit dem richtigen Tool auch nicht so schwer anzuwenden. Beim APF beispielsweise merkst du zunächst nichts davon, sofern du nicht direkt hinterfragst, was ein <core:importdesign /> technisch tut. Sofern du durch also einarbeiten und nicht zu viel Zeit mit theoretischer Forschung verbringen möchtest, empfehle ich dir ein Tool (es dürfte nicht schwer fallen zu erraten, dass ich das APF empfehlen würde ) zu nehmen und zu lernen, wie man damit umgeht. Im Laufe der Zeit der Eingewöhnung / des Lernens - und sicher auch einiger Diskussionen - kommst du ganz alleine dahinter. Ich verstehe den Anspruch, dass du das verstehen möchtest, nur habe ich schon oft das Feedback erhalten, dass HMVC garnicht so schwer ist, wenn man es einfach mal anwendet.
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design [B]before[/B] you start to write code!
        2. Discuss and review it together with [B]experts[/B]!
        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
        4. Write [I][B]clean and reusable[/B][/I] software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


        • #5
          @Dr. E.: Interesse halber: Wie ist das mit der JSON-Ausgabe und den Taglibs? Werden die Taglibs dann innerhalb einer JSON-geschrieben? Also z. B. möchte ich pro Ajax-Request ein JSON-Objekt mit
          "success" = 1 oder 0 und ggf.
          "content" = Ein weiteres Objekt oder
          "error" = ein Array
          zurück geben.
          Jetzt würde ich aus dem Bauch heraus ein JSON-"Template" anlegen (Ich weiß jetzt leider nicht die korrekte Syntax des APF, deswegen schreibe ich es mal ohne die notwendigen XML-Steuerungs-Notationen )
          Code:
          {"success":<...taglib oder Platzhalter, der den Erfolgsstatus enthält />,"<error oder content />":<inhalt für Fehler oder eben Rückgabe />}
          Wäre das so korrekt?

          Kommentar


          • #6
            Hallo xm22,

            es ist nicht so, dass ich für das APF hätte in der Zwischenzeit etwas implementieren müssen, es war einfach in dieser Woche verdammt viel los.

            Für die Ausgabe von JSON-Content für einen AJAX-Request gibt es mehrere Möglichkeiten.
            1. Ausgabe über Template
              1. Generierung über Controller
              2. Generierung über Taglib
            2. Ausgabe über Front-Controller-Action
              1. Generierung über eigenen Action-Code
              2. Generierung über einen Page-Controller-Aufruf der Templates, die unter 1.) verwendet werden.

            Welchen Weg du wählst kommt i.d.R. auf deine Architektur an. Ich persönlich würde Variante 2.1 bevorzugen, da du so die PHP-JSON-Funktionen nativ verwenden kannst.

            Sofern du das auf Basis einer Taglib in einem Template durchführen möchtest, kannst du ganz einfach den Code in eine taglib schreiben und die einzelnen Elemente zusammen setzen. Hier würde sich beispielsweise der Iterator- oder der Template-Tag eignen. Soll ich mal ein konkretes Beispiel zeigen?
            Viele Grüße,
            Dr.E.

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            1. Think about software design [B]before[/B] you start to write code!
            2. Discuss and review it together with [B]experts[/B]!
            3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
            4. Write [I][B]clean and reusable[/B][/I] software only!
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Kommentar


            • #7
              Ich wollte gar nichts unterstellen

              Ein bsp. Wäre super..

              Kommentar


              • #8
                Welches hätten's denn gerne?
                Viele Grüße,
                Dr.E.

                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                1. Think about software design [B]before[/B] you start to write code!
                2. Discuss and review it together with [B]experts[/B]!
                3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                4. Write [I][B]clean and reusable[/B][/I] software only!
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                Kommentar


                • #9
                  Generierung über die Taglib

                  Kommentar


                  • #10
                    Hallo xm22,

                    ich habe dir drei Arten der Generierung von JSON-Output hier zusammengestellt:
                    • Ausgabe über Controller per json_encode().
                    • Ausgabe über Controller via html:template-Tag.
                    • Ausgabe über Taglib via json_encode().

                    Das ist - wie oben angesprochen - nur eine Auswahl an Möglichkeiten. Man könnte innerhalb der Taglib jsonutput z.B. weitere Struktur-Elemente vorsehen um die schematische Darstellung wie in der Variante mit dem html:template-Tag beeinflussbar zu haben. Darauf habe ich jedoch verzichtet, da in PHP bereits eine sehr einfache Möglichkeit existiert, das JSON-Format zu erzeugen.

                    Der Bezug der Daten von einem Service könnte genauso gut durch ein Model oder einer anderen Komponente substituiert werden.

                    Sollte dich eine Variante noch mehr interessieren, sag einfach Bescheid.
                    Viele Grüße,
                    Dr.E.

                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    1. Think about software design [B]before[/B] you start to write code!
                    2. Discuss and review it together with [B]experts[/B]!
                    3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                    4. Write [I][B]clean and reusable[/B][/I] software only!
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                    Kommentar


                    • #11
                      Genau so hatte ich mir das vorgestellt (Nicht sarkastisch gemeint). Allerdings ist da die Notation mit den "html"-Tags etwas unglücklich..

                      Kommentar


                      • #12
                        Genau so hatte ich mir das vorgestellt (Nicht sarkastisch gemeint).
                        Fragen wir mal umgekehrt: was hast du denn erwartet?

                        Allerdings ist da die Notation mit den "html"-Tags etwas unglücklich..
                        Wie meinst du das?
                        Viele Grüße,
                        Dr.E.

                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                        1. Think about software design [B]before[/B] you start to write code!
                        2. Discuss and review it together with [B]experts[/B]!
                        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                        4. Write [I][B]clean and reusable[/B][/I] software only!
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                        Kommentar


                        • #13
                          Fragen wir mal umgekehrt: was hast du denn erwartet?
                          So, wie Du es gezeigt hast. Ich wollte nur nicht, dass aufgrund unserer anderen Diskussion der Verdacht aufkommt, dass das hier ein Rachefeldzug werden soll

                          Zu 2.: Naja - was heißt unglücklich... Mich persönlich würde es jetzt nicht stören. Es geht nur ums Äußerliche - Du baust ein Ajax-Objekt mit Tags zusammen, die mit "html" beginnen..

                          Kommentar


                          • #14
                            Zu 2.: Naja - was heißt unglücklich... Mich persönlich würde es jetzt nicht stören. Es geht nur ums Äußerliche - Du baust ein Ajax-Objekt mit Tags zusammen, die mit "html" beginnen..
                            Das ist aber wirklich kleinlich. Wenn du möchtest, kannst du das aber ändern und die Taglib per

                            PHP-Code:
                            class json_taglib_template extends html_taglib_template {

                            und

                            Code:
                            <core:addtaglib namespace="..." prefix="json" class="template"/>
                            <json:template name="...">
                            </json:template>
                            umlabeln können.
                            Viele Grüße,
                            Dr.E.

                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                            1. Think about software design [B]before[/B] you start to write code!
                            2. Discuss and review it together with [B]experts[/B]!
                            3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                            4. Write [I][B]clean and reusable[/B][/I] software only!
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                            Kommentar


                            • #15
                              Das sieht doch viel schöner aus

                              Kommentar

                              Lädt...
                              X