Ankündigung

Einklappen
Keine Ankündigung bisher.

Link Generator

Einklappen

Neue Werbung 2019

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

  • Link Generator

    Hi,

    ich stehe gerade vor einem Problem und komme da nicht recht weiter. Es geht darum, dass ich für mein Framework ein Objekt haben möchte, mit dem ich URLs generieren möchte. Da gibt es natürlich einen standardmäßig genutzten, aber mam soll auch eigene implementieren können. Das nahe liegendste ist da für mich, ein Interface zu nutzen. Das Problem dabei ist jetzt, dass die Methode zum Generieren der Links (assembleLink) unterschiedliche Parameter entgegen nehmen können soll.

    Jetzt habe ich drei Möglichkeiten, die mir aber alle nicht so sonderlich gefallen:
    - Statt einem Interface eine abstrakte Klasse, bei der dann die Methode assembleUrl überschrieben werden kann.
    - Statt einzelner Parameter ein Array übergeben
    - Grundsätzlich in Methoden-Deklaration alle möglichen Parameter aufnehmen (Was allerdings für mich die schlechteste Methode wäre, da ich ja nicht weiß, was da alles kommen könnte)

    Mein Favorit wäre jetzt das Interface + Array, aber vielleicht hat sonst noch jemand eine Idee.

  • #2
    Von wievielen verschiedenen Parametern reden wir denn?

    Kommentar


    • #3
      Warum will man eigene Links implementieren? Sehe da keinen Sinn drin, Link ist Link und dass in einem vorgegeben Format innerhalb deines Frameworks.

      Hast du einen Router? Dann könnte der Link-Generator einfach nur für die aktuelle Route (oder eine anderen) den Link zusammensetzen.

      Kommentar


      • #4
        Von wievielen verschiedenen Parametern reden wir denn?
        K. A. - Das ist halt nicht absehbar.
        Link ist Link und dass in einem vorgegeben Format innerhalb deines Frameworks.
        Gerade nicht - Dafür will ich ja verschiedene Generatoren implementieren. Einerseits sollen sie Links nach einem bestimmten Schema erzeugen, auf der anderen Seite sollen sie sie auch auflösen können - Ähnlich wie die Routen beim ZF.

        Kommentar


        • #5
          - Statt einem Interface eine abstrakte Klasse, bei der dann die Methode assembleUrl überschrieben werden kann.
          Hilft Dir auch nichts. Nen strict Error kassierst Du trotzdem
          - Statt einzelner Parameter ein Array übergeben
          Kommt daruf an, was das für Parameter sind.
          - Grundsätzlich in Methoden-Deklaration alle möglichen Parameter aufnehmen (Was allerdings für mich die schlechteste
          Dann musst Du aber alle anfallenden Parameter vorbelegen (optional gestalten) - wiederum strict

          func_get_args wäre auch noch ne Möglichkeit, aber ein sauberes Interface bekommst Du so nicht.

          Oder Du gestalteste die Abfragemethode einheitlich und baust statt dessen konkrete Init-Methoden oder individuelle Konstruktoren ein.
          [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


          • #6
            func_get_args wäre auch noch ne Möglichkeit
            Näää... Das ist auch nicht besser als meine "Ideen"
            Oder Du gestalteste die Abfragemethode einheitlich und baust statt dessen konkrete Init-Methoden oder individuelle Konstruktoren ein.
            Wie meinst Du das? Parameter in den Konstruktor des Link-Generators? Wäre allerdings auch etwas unpraktisch, da man dann jedes Mal ein neues Objekt davon instanziieren müsste. Also quasi so etwa:
            PHP-Code:
                $link = new LinkGeneratorIrgendwas($param1$param2'...');
                echo 
            $link
            Andererseits könnte man das auch wie ein Prepared Statement machen, dass man Parameter der Instanz ändern kann.. Das klingt sogar ziemlich gut..
            PHP-Code:
                $link = new LinkGeneratorIrgendwas($param1$param2'...');
                echo 
            $link->assemble();
                
            $link->setParam1('...');
                echo 
            $link->assemble(); 
            Dann könnte man das assemble auch gleich ganz weglassen und die toString-Funktion nutzen. Ich glaube, das ist ein ziemlich guter Ansatz..

            EDIT: Oder noch ein bisschen leckerer - Man bekommt ein URL-Objekt zurück.

            Kommentar


            • #7
              Hast du dir schon mal das Konzept des APF angesehen? --> http://adventure-php-framework.org/Seite/138-Links. Dort hast du eine Abstraktion der Link-Generierung. Schwierigkeit für dein Framework ist jedoch, dass du keine Abstraktion der URL vorgesehen hast (siehe unsere Diskussionen in den vergangenen Monaten). Damit ist das Konzept nicht ganz so einfach umsetzbar. Zielführend ist es IMHO aber trotzdem.
              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


              • #8
                Stimmt, ganz so funktioniert es nicht. Allerdings habe ich es jetzt ähnlich gelöst (Glaube ich zumindest). Es gibt einmal einen URL-Genrator, dessen Daten einerseits per Settern gesetzt werden können, der aber auch anhand einer vorhandenen URL geladenen werden kann.
                PHP-Code:
                $generator = new LinkGenerator();
                $generator->loadFromUrlString('...');
                //oder auch
                $generator->loadFromUrlString(Url::fromCurrent()); 
                Dann kann man auch auf die vorhandenen Parameter zurück greifen.

                Was mir bei der APF-Lösung seltsam vorkommt, ist, dass der Link-Generator ein fertiges URL-Objekt übergeben bekommt. Warum das? Bei mir liefert der Link-Generator ein fertiges URL-Objekt zurück, dass dann ausgegeben werden kann..

                Kommentar


                • #9
                  Hi xm22,

                  PHP-Code:
                  $generator->loadFromUrlString(Url::fromCurrent()); 
                  Das macht für mich einen etwas seltsamen Eindruck - rein von der Modellierung her. Du möchtest mit dem Generator doch etwas generieren. Warum ist hier ein load im Methoden-Namen enthalten?

                  Was mir bei der APF-Lösung seltsam vorkommt, ist, dass der Link-Generator ein fertiges URL-Objekt übergeben bekommt. Warum das?
                  Bei der Generierung einer URL geht es doch im Wesentlichen um die Formatierung einer URL als String. Die reine Repräsentation ist für die (spätere) Ausgabe doch irrelevant. Warum? Der HTML-Quelltext ist eine reine String-Repräsentation, die über unterschiedliche Komponenten erzeugt wird. Was die Arbeit mit einem solchen Formatter angeht, so darf und soll die API typisiert sein. Weiterhin geht es um das Thema Abstraktion von Url-Layouts (siehe http://wiki.adventure-php-framework....en_URL-Layouts). Damit ist es wichtig, eine Url als solche unabhängig von der String-Repräsentation zu definieren und intern auch mit dieser zu arbeiten. Innerhalb einer Applikation sollst du keine Kenntnis des URL-Layouts haben (müssen), denn nur dann ereichst du eine Abstraktion. Aus diesen Grund arbeiten alle Applikationen mit einem abstrakten (im Sinne von "abstrahierend") Objekt, das eine URL gemäß RFC repräsentiert. Mehr muss und soll diese nicht "können", denn sonst generierst du dir wieder Abhängigkeiten.

                  Da du dieses Verhalten als seltsam betrachtest, verstehe ich nicht, warum du die oben zittierte Zeile aufführst. Betrachtest du deinen Gedankengang weiter, dürftest du dem Generator kein Url-Objekt übergeben, sondern höchstens eigene Parameter für Host, Port, Parameter etc. Das sieht deine Signatur aber nicht vor.

                  Bei mir liefert der Link-Generator ein fertiges URL-Objekt zurück, dass dann ausgegeben werden kann..
                  Und was macht diese Rückgabe aus? Nur der Signatur wegen ein Url-Objekt zurückzugeben macht IMHO keinen Sinn, wenn hinterher auch nur
                  PHP-Code:
                  $url->toString() 
                  explizit oder implizit aufgerufen wird.

                  Lies dir mal den Wiki-Beitrag genauer durch, dann wirst du verstehen, worum es bei diesem Thema eigentlich gehen sollte.
                  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


                  • #10
                    PHP-Code:
                    $generator->loadFromUrlString(Url::fromCurrent());

                    Das macht für mich einen etwas seltsamen Eindruck - rein von der Modellierung her. Du möchtest mit dem Generator doch etwas generieren. Warum ist hier ein load im Methoden-Namen enthalten?
                    Das ist so gedacht: Der Genrator wird normalerweise instanziiert und dann mit entsprechenden Werten gefüllt (z. B. angesprochene Node, URL-Parameter, etc.) Daraus generiert er ein URL-Objekt, dass, wie beim APF, im Prinzip lediglich dazu dient, Daten (Scheme, Host, Pfad, Port, etc.) aufnehmen zu können, um eine URL generieren. Also eigentlich nichts weiter als ein Container mit ein paar Hilfsfunktionen.
                    Der Generator selbst verfügt über zwei Wege:
                    1. Aus Daten eine URL zu erzeugen
                    2. Aus einer URL Daten zu extrahieren
                    Das erfüllt die loadFromString-Funktion.

                    Mittlerweile hat sich das Ganze aber etwas geändert. Der Generator ist mittlerweile zum UrlResolver geworden, da das von der Namensgebung her besser zum Zweck passt. Der eigentliche Ablauf ist jedoch der selbe: Man kann dem Resolver ein URL-Objekt übergeben und er extrahiert daraus Daten, die z. B. der Front-Controller für das Dispatching benutzen kann.

                    Kommentar


                    • #11
                      ... was aber immer noch nicht den Austausch eines Url-Layouts unterstützt.
                      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


                      • #12
                        ... was aber immer noch nicht den Austausch eines Url-Layouts unterstützt.
                        Komplett nicht, das ist richtig. Aber zum großen Teil schon. Ob zum Beispiel in einem Blog ein Artikel oder eine Kategorie angezeigt werden soll, kann der URL-Resolver durchaus anhand der vorhandenen Parameter auslesen. Was richtig ist, ist, dass er dann quasi die richtige Entscheidung für den Einstiegspunkt der Applikation treffen muss. Heißt also, dass

                        .../article.show/id/1

                        äquivalent zu

                        .../article/1

                        sein könnte. Das ist dann abhängig von der Implementierung des jeweiligen URL-Resolvers. Wo ich Dir recht gebe, ist, dass es allerdings kaum eine generische Lösung für den Resolver geben wird.

                        Allerdings hat meine Erfahrung gezeigt, dass die Angabe des Einstiegspunktes der URL i. d. R. als gegeben angesehen werden kann. Das heißt, man kann z. B. eine URL angeben:
                        .../artikel/id/1
                        Wobei "artikel" z. B. für die Node "article.show" stehen würde.
                        Wo das nicht sein darf, kann man dann durchaus mit festeren "Routen" arbeiten.

                        Kommentar


                        • #13
                          Vielleicht darf ich mal vorsichtig auf das Thema Over-Engineering kommen. Wenn ich eine View erstellte, möchte ich nicht drei Zeilen benutzen nur um einen Link zu generieren. Es sollte zumindest an eine (statische) Klasse gedacht werden, die fungiernd als Facade die komplexen Link-Generierungen abnimmt, etwa
                          PHP-Code:
                          Anchor::generate('auth/login'); 

                          Kommentar


                          • #14
                            Dann kannst Du auch gleich eine Funktion verwenden.
                            was aber immer noch nicht den Austausch eines Url-Layouts unterstützt.
                            [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


                            • #15
                              @dsentker: wie kommst du auf over-engeneering? Eine statische Methode wie du sie aufgezeigt hast ist schlechter OO-Stil und hat für mich nichts mit der Modellierung eines Url-Layouts/-Schema zu tun (siehe nikosch' Kommentar).
                              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

                              Lädt...
                              X