Ankündigung

Einklappen
Keine Ankündigung bisher.

Controller inkl. oder exkl. Action

Einklappen

Neue Werbung 2019

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

  • #46
    Zitat:
    Zitat von xm22
    @Dr. E.: Weil vermutlich diese Frage kommen wird: Das Multilinguale Request-Objekt ist eine konkrete Implementierung für ein aktuelles Projekt.

    Definitiv. Ein Framework soll per Definition generische Implementierungen zur Verfügung stellen. In diesem Fall wäre das ein Bruch.
    Tut es auch, indem es ein Interface dafür zur Verfügung stellt - Daher sehe ich da auch keinen Bruch.
    Was hat das denn mit einem Interface zu tun ??


    Ich hab ja auch ein kleines, prozedurales Framwork:
    da läuft alles über eine index.php, je nach Parameter werden andere Dateien
    (Sprachdateien, php-Programmlogik-Dateien und Ausgabedateien includet
    und am Ende alles ausgegeben (EVA-Prinzip).
    Läuft sehr gut, sehr schnell, ist gut dokumentiert und andere Programmierer
    die schon mal etwas anpassen/ändern mußten haben die Übersichtlichkeit etc. gelobt.

    Wenn ich jetzt ein neues Projekt starte kopier ich eine der vielen Anwendungen die
    der aktuellen am nächsten kommt, ändere die DB, trag config-Daten ein und mach die
    Anpassungen am Verarbeitungs- und Ausgabecode die eben notwendig sind.


    So scheints Du auch zu arbeiten, eben in OOP und mit dem Unterschied
    daß Du jedes mal noch Dein Framework umbauen mußt wenn neue Anforderungen
    wie Mehrsprachigkeit hinzukommen.

    Wenn ich aber jedes Mal oder fast jedes Mal mein Framework umbauen,
    in den Core eingreifen muß. dann ist das kein Framework mehr, dann ist das Copy/Paste
    von existerienden Projekten.

    Ist ja auch kein Problem, kannst ja so machen wenn es für Dich paßt.


    Nur versteh ich Deine Kritik am APF nicht und Dein Beharren darauf daß man alles auch anders
    machen kann als es im APf umgesetzt ist.


    Natürlich kann man beispielsweise auch eine Hintertür namens "helper" einbauen und dann unter dem
    Vorwand der Produktivität und weil man schnell was Hinzubasteln kann die Integration
    von Helpern in der Form wie es das beispielsweise das ZF tut rechtfertigen.

    Weiter- oder zielführend ist das nicht und ein schlüssiges Gesamtkonzept anwendbar für
    alle denkbaren Fälle läßt sich daraus nicht ableiten.
    Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

    Kommentar


    • #47
      Nur versteh ich Deine Kritik am APF nicht und Dein Beharren darauf daß man alles auch anders
      machen kann als es im APf umgesetzt ist.
      Was habe ich kritisiert?! Es geht nicht darum, _alles_ anders umzusetzen, sondern dass man Konzepte unterschiedlich umsetzen kann. EDIT: Und nicht mal das - Ich habe hier meine Umsetzung dargelegt. Und darum geht es im Moment.

      Was hat das denn mit einem Interface zu tun ??
      #41 ->
      Ein Framework soll per Definition generische Implementierungen zur Verfügung stellen.
      mit dem Unterschied
      daß Du jedes mal noch Dein Framework umbauen mußt wenn neue Anforderungen
      wie Mehrsprachigkeit hinzukommen.
      Das hast Du anscheinend falsch verstanden. Es gibt momentan _eine_ von mir genutzte Request-Klasse und die hat sich bisher als so allgemeingültig herausgestellt, dass sie überall benutzt werden kann. Und wenn sich doch mal Anforderungen ergeben, die ein anderes Request-Handling erfordern, dann schreibt eben eine Klasse, die das Request-Interface(!) implementiert. Da muss im Framework rein gar nichts umgeschrieben werden.



      Wenn ich aber jedes Mal oder fast jedes Mal mein Framework umbauen,
      in den Core eingreifen muß. dann ist das kein Framework mehr, dann ist das Copy/Paste
      von existerienden Projekten.
      Das erweckt bei mir den Eindruck, als ob Du Dir das Framework gar nicht angeschaut hättest. Wie kommst Du auf den Gedanken, dass für verschiedene Applikationen im Framework auch nur irgend etwas umgeschrieben werden müsste?

      Wenn ich jetzt ein neues Projekt starte kopier ich eine der vielen Anwendungen die
      der aktuellen am nächsten kommt, ändere die DB, trag config-Daten ein und mach die
      Anpassungen am Verarbeitungs- und Ausgabecode die eben notwendig sind.
      Genau so läuft es bei mir auch - Wo ist also das Problem?

      Läuft sehr gut, sehr schnell, ist gut dokumentiert und andere Programmierer
      die schon mal etwas anpassen/ändern mußten haben die Übersichtlichkeit etc. gelobt.
      Super - Genau so erging es mir auch, als ich das Framework anderen gezeigt habe.

      Natürlich kann man beispielsweise auch eine Hintertür namens "helper" einbauen und dann unter dem
      Vorwand der Produktivität und weil man schnell was Hinzubasteln kann die Integration
      von Helpern in der Form wie es das beispielsweise das ZF tut rechtfertigen.

      Weiter- oder zielführend ist das nicht und ein schlüssiges Gesamtkonzept anwendbar für
      alle denkbaren Fälle läßt sich daraus nicht ableiten.
      Also sorry - Aber es wird immer offensichtlicher, dass Du Dir das Framework überhaupt nicht angeschaut hast. Hast Du mitbekommen, für was der eine Helper genutzt wurde? Um Strings zu filtern! Nicht um Applikationslogik umzusetzen

      Kommentar


      • #48
        Also auch wenn sich meine Entwicklungserfahrung sicher weiter unter der der anderen Diskussionsteilnehmer ansiedelt, muss ich doch auch etwas dazu sagen.

        Ich finde es schade, dass hier scheinbar mit allen Mitteln versucht wird den gezeigten Code/das gezeigte Framework zu kritisieren. Und das in einem "Ton" den ich völlig fehl am Platz finde.

        Argumente von xm22 werden m.E. ignoriert, bzw. so verdreht, dass man doch wieder ein Haar in der Suppe finden kann.

        Wem das Framework nicht gefällt muss es nicht nutzen.
        Genausowenig wie ich APF, ZF oder Symphony nutzen muss wenn mir das ganze oder Teile des entspr. Frameworks nicht zusagen. Und ich bin mir 100%ig sicher das es in jedem FW irgendwo/irgendetwas gibt das "unsauber" und "gegen Pattern xy" implementiert wurde. Ob sich daraus ein entscheidender Vorteil oder ein gravierender Nachteil ergibt entscheidet letzen Endes der Anwender aufgrund der Anforderungen denen er sich zu stellen hat.
        Hilfe, mein Ball ist umgekippt!

        Kommentar


        • #49
          Na, da hab ich ja was angerichtet.

          Zitat von dr.e. Beitrag anzeigen
          Spannend? Das ist grober Unfug! Dieses Thema hatten wir mal in einem sehr länglichen Thread hier schon besprochen. In Verbindung mit HMVC macht die Abbildung von Controllern und Actions in der URL überhaupt keinen Sinn. Ich bin ebenso der Meinung, dass die sehr verbreitete Meinung, Controller und Actions müssen in die URL und man brauche ein Routing, das dieses dann auf Klassen und Methoden in der Anwendung von MVC mappen ebenso für nicht sinnig.


          Sofern du geschafft hast, das implizit in einer HMVC-Struktur abzubilden, hast du meiner Ansicht nach den Haupt-Preis gewonnen. Denn: du bist jetzt befähigt, ein beliebiges URL-Layout zu präsentieren, ohne 1000 Routen eintragen zu müssen.
          "Spannend" insofern, dass ich mir nicht vorstellen kann, wie das funktionieren soll.

          Egal was man mit seinen URLs macht, irgendwann kommt man beim entsprechenden Einsprungspunkt für die Bearbeitung des Requests raus. Ob das nun durch direktes angeben von Controller und Action, durch irgendwelche Routings oder Mappings oder durch konfigurierbare Shortcuts ist, sei mal dahingestelt.

          Um jetzt auch nochmal meine Vorgehensweise in den Raum zu werfen hier eine ganz ganz kurze Beschreibung (Iterativ entwickelt, ohne vorher irgendwelche Patterns studiert zu haben): Eine Action gibt bei mir entweder einen View zurück oder verweist auf eine weitere Action. Basisklasse eines Views ist ein Control. Ein Control hat eine Methode um sich als HTML auszugeben und kann beliebig viele andere Controls beherbergen. Sprich: Ich kann hierarchische Oberflächen aufbauen. Es gibt beispielsweise auch ein Control, dass wiederum eine Action kapseln kann. Das ganze Spiel kann man also beliebig tief fortsetzen. Das Rendering erfolgt dann situativ, sprich habe ich einen Postback wird das Seitengrundtemplate mit ausgegeben, ist es z.B. ein AJAX Request wird nur der Inhalt ausgegeben. Das ganze ist inspiriert von der GUI Entwicklung im Bereich Desktopprogrammieren. Ob das jetzt irgendeinem Pattern entspricht, keine Ahnung.

          Das Problem ist meiner Ansicht nach doch eher, dass es in PHP keinerlei Vorgaben gibt wie etwas zu machen ist. Patterns sind Lösungen, die erwiesenermaßen funktionieren, aber deshalb ja noch lange nicht verpflichtend. Daraus folgt, dass es keine "Leitmeinung" gibt. Und das führt dann dazu, dass fünf Tutorials / Artikel zu HMVC fünf verschiedene Lösungen demonstrieren. Und daher wird das dauernd diskutiert.

          Kommentar


          • #50
            Spannend? Das ist grober Unfug! Dieses Thema hatten wir mal in einem sehr länglichen Thread hier schon besprochen. In Verbindung mit HMVC macht die Abbildung von Controllern und Actions in der URL überhaupt keinen Sinn.
            Diese Aussage ist mir völlig entgangen und in meinen Augen auch falsch. Da hat mquadrat recht: _Irgendwie_ muss man einen Einsprung in die Applikation erkennen können. Und ob das nun die Nennung eines HMVC-Knotens ist oder das Auslesen eines Parameters, ist gehüpft wie gesprungen. Das hat für mich rein gar nichts mit HMVC oder nicht HMVC zu tun.

            Kommentar


            • #51
              Der Punkt von dr.e in diesem Fall ist, das man beim Aufruf nicht immer weiß wie die gesamte (!) Kette letztendlich aussehen wird. Also nicht nur der Einsprungspunkt, sondern alle Schichten, die im Laufe des Requests durchlaufen werden. Wüsste man das, wäre die Kapselung nicht in Ordnung. Wenn man es also schafft die gesamte Kette bereits in den Aufruf zu packen, hat man irgendwas verkehrt gemacht

              Aber ich stimme dir zu, dass die Art und Weise wie man den Einsprungspunkt findet austauschbar ist.

              Kommentar


              • #52
                Zitat von MaxC Beitrag anzeigen
                Ich finde es schade, dass hier scheinbar mit allen Mitteln versucht wird den gezeigten Code/das gezeigte Framework zu kritisieren. Und das in einem "Ton" den ich völlig fehl am Platz finde.

                Argumente von xm22 werden m.E. ignoriert, bzw. so verdreht, dass man doch wieder ein Haar in der Suppe finden kann.
                Mag sein, daß Dir das so vorkommt.
                Aber die Diskussion zieht sich schon seit einiger Zeit in diversen Threads hin. Lies sie Dir durch und dann siehst wer was wie schreibt.


                Wem das Framework nicht gefällt muss es nicht nutzen.
                geht doch auch gar nicht, weil es nicht öffentlich ist.
                Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                Kommentar


                • #53
                  @Dr.E.: Ich habe mir gerade den einen Thread auf phpforum.de durchgelesen und bin da unter http://phpforum.de/forum/showpost.ph...5&postcount=94 auf folgende Aussage gestoßen:
                  Sofern du deinen Anwendungsfall etwas näher beschreiben möchtest, können wir gerne ein abstraktes Software-Design und anschließend eine praktische Anwendung diskutieren.
                  Und da stellt sich mir jetzt die Frage, wie sich diese Einstellung mit
                  Ich werde mich daher nicht auf ein "Sag mir etwas, was nicht geht und ich zeig dir, dass es doch geht!" einlassen
                  verträgt. Das hört sich etwas nach zweierlei Maß an. Aber das nur am Rande und soll auch die Diskussion nicht beeinflussen..


                  Zitat:
                  Wem das Framework nicht gefällt muss es nicht nutzen.
                  geht doch auch gar nicht, weil es nicht öffentlich ist.
                  Darum geht es ja hier auch nicht...

                  Kommentar


                  • #54
                    Ich frage mich gerade, ob wir den Punkt, an dem wir zum Kern der Diskussion zurückkehren können, bereits überschritten haben.

                    Es ging hier um die Abbildung von HMVC Funktionalität auf die URL, wenn ich das richtig interpretiere. xm22 hat seinen Ansatz vorgestellt und DocE findet das undiskutabel, weil er es für hingeschustert hält, es faktisch also kein HMVC ist. Ich finde, man muss beide Belange trennen, bin also mehr auf der Linie des Docs. Vor allem darf IMHO die URL die Struktur des HMVC-Baums nicht abbilden, weil das für sich allein stehend sowieso nicht sinnvol ist, ansonsten aber die Struktur doppelt beschrieben wird (nämlich einmal applikationsseitig und einmal Request-seitig).

                    *Tschinggg*
                    [COLOR="#F5F5FF"]--[/COLOR]
                    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                    [COLOR="#F5F5FF"]
                    --[/COLOR]

                    Kommentar


                    • #55
                      Ich würde ja sogar behaupten, dass sich alle einig sind, dass ein direktes Abbilden mehr Nach- als Vorteile hat. Die von xm22 beschriebene Struktur KANN so sein, muss es aber nicht. Sprich: es handelt sich einfach um seine Default-Abbildung, er kann aber seine URLs auch beliebig gestalten (Zumindest wenn ich mich nicht verlesen habe).

                      Insofern könnte man es zurückführen auf die Grundfrage "Welche Möglichkeiten gibt es HMVC zu implementieren". Und das man da geteilter Ansicht sein kann, haben ja viele viele andere Themen schon gezeigt. Mit dem neusten Thema "Kohana vs. APF", das gerade losgelaufen ist.

                      Insofern würde ich einfach mal sagen, danke an xm22, das er seinen Code gepostet hat. Den kann man sich anschauen, kann ggf. Hinweise geben oder für sich selber entscheiden, ob man ihn schön / gut / korrekt findet oder eben nicht.

                      Kommentar


                      • #56
                        Ok, letzter Versuch:
                        Vor allem darf IMHO die URL die Struktur des HMVC-Baums nicht abbilden
                        Das tut sie auch nicht. In der URL steht lediglich der Einstiegspunkt in die Applikation. In der URL kann auch semmelbrösel stehen. Trotzdem wird in der Applikation ein bestimmer Knoten angesprochen. Damit, wie die Seite letztendlich zusammen gebaut wird, hat das _nichts_ zu tun. Das entscheidet dann der angesprochene HMVC-Knoten.

                        Kommentar


                        • #57
                          OFFTOPIC

                          Zitat von Koala Beitrag anzeigen
                          Mag sein, daß Dir das so vorkommt.
                          Aber die Diskussion zieht sich schon seit einiger Zeit in diversen Threads hin. Lies sie Dir durch und dann siehst wer was wie schreibt.
                          Nunja, ob sich eine Diskussion bereits länger hinzieht oder nicht sollte m.M.n nicht den Umgangston der User untereinander beeinflussen.

                          Ich habe hier im Forum öfters das Gefühl, dass Fragen zum Software-Design im Allgemeinen und HMVC im Speziellen beinahe so heiß und emotional diskutiert werden als ob es um religiöse Ansichten o.Ä ginge

                          Teilweise interessant zu lesen, teilweise schade weil eine äußerst anspruchsvolle und lehrrreiche Diskussion auf ein ziemlich niedriges Niveau heruntergeschraubt wird.
                          Hilfe, mein Ball ist umgekippt!

                          Kommentar


                          • #58
                            Zitat von Koala Beitrag anzeigen
                            geht doch auch gar nicht, weil es nicht öffentlich ist.
                            War als allgemeine Feststellung gemeint, nicht oder nicht nur bezogen auf das diskutierte FW
                            Hilfe, mein Ball ist umgekippt!

                            Kommentar


                            • #59
                              teilweise schade weil eine äußerst anspruchsvolle und lehrrreiche Diskussion auf ein ziemlich niedriges Niveau heruntergeschraubt wird.
                              Du hast offensichtlich noch kein niedriges Niveau in Foren erlebt.
                              War doch alles noch im Rahmen.
                              Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                              Kommentar


                              • #60
                                Oh doch, hab ich - und war selbst oft genug vorne dabei
                                Aber bei solchen Diskussionen wie hier find ich nen unangebrachten Umgangston eben besonder schade, weil das Thema professionell und hoch ineteressant ist.
                                Hilfe, mein Ball ist umgekippt!

                                Kommentar

                                Lädt...
                                X