Ankündigung

Einklappen
Keine Ankündigung bisher.

Wo Zuweisung von Metatags in MVC

Einklappen

Neue Werbung 2019

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

  • #16
    gehört aber thematisch zum Controller.

    Auch der Frontcontroller ist ein Controller.

    Du schreibst ja selbst (habs mal zusammengekürzt):
    Mein ... Plugin registriert sich beim ... Controller. Das Plugin bedient dann die ... View-Helper,
    Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

    Kommentar


    • #17
      Ganz genau.
      --

      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


      --

      Kommentar


      • #18
        Davon abgesehen, dass solche "Hooks" konzeptionell nur eine Krücke mangels "echter" Front-Controller-Actions oder HMVC sind, ist es auf jeden Fall Controller-Logik. Im View kann je gerne auf diese Daten zugegriffen werden, es bleibt aber Controller-Logik

        Ich würde an dieser Stelle dogar so weit gehen und fordern, dass die Meta-Informationen in einem Model oder View-Model stehen müssen, die von einer Front-Controller-Action entsprechend initialisiert werden. Gerade solche Informationen - sofern man HMVC oder Taglibs zur Verfügung hat - sind doch prädestiniert dafür in einem "Haupt-Template" ausgegeben zu werden, das dann wiederum mehrere Bereiche inkludiert, die sich um die "eigentlichen" Inhalte des HTML-Dokuments kümmern.
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design before you start to write code!
        2. Discuss and review it together with experts!
        3. Choose good tools (-> Adventure PHP Framework (APF))!
        4. Write clean and reusable software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


        • #19
          Für mich war der Terminus Controller einfach auf ActionController bezogen - ich denk mal, Florian gings genauso. So gesehen ist es natürlich Controller-Logik, allerdings als Plugin des FrontControllers und nicht im ActionController. Natürlich ist es ein einfacher Hook / pseudeo-Event.

          Wie bereits gesagt ist das eine sehr einfache Lösung, jedoch findet man sich schnell zurecht und hat den Code gekapselt.

          Ich würde an dieser Stelle dogar so weit gehen und fordern, dass die Meta-Informationen in einem Model oder View-Model stehen müssen, die von einer Front-Controller-Action entsprechend initialisiert werden.
          Kommt auch wieder auf die Komplexität der Anwendung an. titles/description leg ich in einem Fall einfach per xml-Datei fest, a la
          Code:
          <?xml version="1.0" encoding="UTF-8"?>
          <root>
              <default
                  title="title == fallbacktitle, wenn für action nicht defined"
                  description="meta description"
              >
                  <index>
                      <faq
                          title="FAQ - title
                          desc="..."
                      />
                  </index>
          Den File Inhalt kann ich per Zend Cache vorhalten, mein "Model" ist in dem Fall der XML Container und ich muss niemanden an die DB ranlassen. Andere Inhalte werden bei mir bspw. per Zend Config (yaml, ini,..) gesetzt, der Inhalt kann - ums salopp zu formulieren - von jedem mit 2 Gramm Hirn ersetzt werden.

          Gerade solche Informationen - sofern man HMVC oder Taglibs zur Verfügung hat - sind doch prädestiniert dafür in einem "Haupt-Template" ausgegeben zu werden, das dann wiederum mehrere Bereiche inkludiert, die sich um die "eigentlichen" Inhalte des HTML-Dokuments kümmern.
          Genau das passiert bei mir per Zend Layout. Natürlich kann ein Zend Partial Helper viel zu unflexibel für logische Strukturen sein, v.a. schau ich dabei darauf, nicht am FrontController vorbei parallele Strukturen etablieren.
          Ich steh aber auch dazu, das "anfangs" vor 2 Jahren von hinten durch den Poppers missbraucht zu haben, mittlerweile kapsel ich das auch um einiges sauberer. Du hast vollkommen Recht, dass das Controlling im ZF schnell an seine Grenzen stößt und man teilweise drum herum bauen muss. Ich glaub dir gerne, dass das APF flexibler und auch mit einer saubereren Struktur auf Anforderungen reagieren kann bzw. nicht so "aufgebohrt" werden muss, ich wollte auch nur zeigen, wie ich das im ZF (für mich möglichst einfach und mMn. dennoch sauber) löse. Dadurch, dass es ein registriertes Plugin ist, hat es jedoch nichts mit dem eigentlichen ActionController zu tun.

          Was mich vom APF abhält, sind zum einen die geringere Verbreitung/Anforderungen der Kunden, das ZF zu verwenden, zum Anderen die taglibs - bsp aus dem Gästebuch-Tutorial des APF:
          Code:
          <@controller namespace="modules::guestbook::pres::documentcontroller" class="guestbook_v1_controller" file="guestbook_v1_controller" @>
          <font style="font-size: 26px; font-weight: bold;"><html:placeholder name="Name" /></font>
          <br />
          <br />
          <html:placeholder name="Description" />
          <br />
          <core:importdesign namespace="modules::guestbook::pres::templates" template="[gbview=display]" incparam="gbview" />
          Da benutze ich persönlich viel lieber php direkt als template-Sprache, aber das ist mein persönlicher Geschmack.

          Was ich bis heute nicht verstehe, wieso in den APF Beispielen so viel mit Referenzen gearbeitet wird (was mich auch immer abschreckt). Ist das ein historisches Überbleibsel oder Gewohnheit? Oder geht das auch ohne? Das Framework scheint auf den ersten und zweiten Blick auch eine sehr steile Lernkurve zu haben. Würde ich mehr Flexibilität benötigen, würde ich viel eher zu symfony greifen.

          Lieber Christian, die Kritik bitte nicht persönlich nehmen, das war einfach nur mein Eindruck - ich habe höchsten Respekt vor deinem OpenSource-Engagement und deinen "Kampf für sauberen Code/Strukturen". Falls der APF-Teil nicht hier rein gehört, kann ich das auch gerne rauseditieren und du darfst mich per PM zerlegen

          Viele Grüße und einen schönen Abend


          Basti
          I like cooking my family and my pets.
          Use commas. Don't be a psycho.
          Blog - CoverflowJS

          Kommentar


          • #20
            Hallo rudygotoya,

            ich wollte jetzt garnicht auf eine Diskussion "ZF vs. APF" hinaus, sondern lediglich eine Forderung aus Sicht des "guten Software-Designs" heraus stellen. Ich nehme das auch keinesfalls als Angriff o.ä., ich finde es umgekehrt sogar schön auf diesem Niveau diskutieren zu können. Trotzdem ein paar Worte zu deinem Post:

            Den File Inhalt kann ich per Zend Cache vorhalten, mein "Model" ist in dem Fall der XML Container und ich muss niemanden an die DB ranlassen.
            Das ist legal, solange die(se) Meta-Tags konstant sind und nicht von Inhalten aus der Datenbank (z.B. CMS) sind. Bei letzteren schickt es sich - da sind wir uns einig - ein Front-Controller-Action/Plugin für die Initialisierung des "Models" zu haben.

            Genau das passiert bei mir per Zend Layout.
            Für Meta-Tags ist das eine absolut legale Vorgehensweise. In Kombination mit einem FC-Plugin sogar sauber.

            Was mich vom APF abhält, sind zum einen die geringere Verbreitung/Anforderungen der Kunden, das ZF zu verwenden, zum Anderen die taglibs - bsp aus dem Gästebuch-Tutorial des APF
            PHP eben nicht als Template-Sprache einzusetzen ist ein Paradigma des APF. Als Gründe sind Sicherheit, Kapselung und Wiederverwendbarkeit anzuführen. Punkt 1 klärt sich selbst, Punkt 2 sorgt dafür, dass der View nicht mit zuviel Logik vollgestopft ist und Punkt 3 lässt sich eben durch die Taglibs erzeugen. Ein Tag kann in jeder beliebigen Stelle wieder eingesetzt werden und kapselt sauber (Attribute und Content des Tags + seine Funktion) eine Funktionalität innerhalb des DOM-Baumes. Formulierst du das als Template-Code (Stichwort: IF-Konstrukte, ...) bist du ganz schnell bei copy&paste-Programming.

            Negativ fällt dabei vielleicht auf, dass der Entwickler gezwungen wird, Template-Logik zu vermeiden, andererseits kannst du dir deinen if-Tag auch schnell selbst schreiben.

            Was ich bis heute nicht verstehe, wieso in den APF Beispielen so viel mit Referenzen gearbeitet wird (was mich auch immer abschreckt). Ist das ein historisches Überbleibsel oder Gewohnheit? Oder geht das auch ohne?
            Ob du nun ein & notierst oder nicht, in PHP5 arbeitest du automatisch mit Referenzen. Insofern ist das also grundsätzlich schon mal kein "Übel" oder keine "Altlast", sondern Konzept (von PHP und dem APF).
            Ferner ist es hinsichtlich der Performance und der Verwendung ungünstig bis unmöglich in einer DOM-Baum-Struktur ohne Referenzen (implizit oder explizit) zu arbeiten, da du sonst Manipulationen an einem DOM-Objekt - z.B. in einem Controller oder einer Taglib - verlierst. Nehmen wir das Beispiel Formulare. Hier bietet dir das APF eine komplette Abstraktion in der Klasse html_taglib_form. Diese Instanz des DOM-Baums kannst du dir in einem Controller referenzieren und diverse Manipulationen vornehmen (z.B. Hinzufügen von Feldern, ...). Ist die Instanz im Controller eine Kopie, so wird das Formular bei der Ausgabe (=Transformation) des DOM-Baumes dein neues Feld nicht ausgeben.
            Anderes Beispiel: verwendest du einen Service mehrfach, so möchtest du ja innerhalb eines Bereiches einer Software auch immer wieder die gleiche Instanz haben und eine Veränderung des Zustands des Services soll beim nächsten Aufruf ebenfalls wieder sichtbar sein. Deshalb gibt dir der ServiceManager auch immer eine Referenz auf den Service und keine Kopie zurück.
            Vielleicht ist diese Vorgehensweise ungewohnt für dich, aber es hat durchaus Konzept.

            Das Framework scheint auf den ersten und zweiten Blick auch eine sehr steile Lernkurve zu haben. Würde ich mehr Flexibilität benötigen, würde ich viel eher zu symfony greifen.
            Die Steigung ist natürlich immer relativ zum Betrachter festzulegen. Habe das APF letzte Woche einem JAVA-Entwickler-Kollegen vorgestellt und er hat die Struktur des DOM-Baums sofort verstanden. Kann sicher auch daran liegen, dass solche Konzepte im JAVA-Bereich verbreiteter sind.
            Was du verwendest ist natürlich deine Entscheidung. Gerade im Templating-Bereich und der Flexibilität, die du mit dem APF hast, würde ich mich freuen, wenn du mal einen weiteren Blick darauf wirfst solltest du nach einer flexibleren Lösung zum ZF suchen.
            Viele Grüße,
            Dr.E.

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            1. Think about software design before you start to write code!
            2. Discuss and review it together with experts!
            3. Choose good tools (-> Adventure PHP Framework (APF))!
            4. Write clean and reusable software only!
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Kommentar


            • #21
              Ich habe mir den Thread gerade durchgelesen (War etwas beschäftigt bisher). Ich sehe, dass sich die Problematik für mein Anliegen etwas zu sehr in Richtung mvc verschoben hat.

              Ich schildere das mal etwas präziser (Geht hier um mein Framework - Bitte keine Diskussion um die grundlegende Implementierung; Das hatten wir schon zur Genüge ):

              Es gibt sog. Nodes, die jeweils eine MVC-Triade (Nennt man das so?) darstellen. Die Ausgabe dieser Nodes ist jeweils ein String, wie auch bei normalen MVC-Frameworks. Natürlich sollten die Nodes auch die Möglichkeit haben, in einem Template ausgegeben zu werden. Dem generischen Ansatz halber sind diese Templates ebenfalls Nodes. Bsp.:

              Es gibt eine Node zur Darstellung von CMS-Seiten "cms.page". Die soll innerhalb eines HTML-Gerüsts (Welches die Template-Node wäre) angezeigt werden. Dafür habe ich einen Mechandismus implementiert, welcher beim Rendern der cms.page-Node die Ausgabe in die Template-Node injiziert und der Ausgabe zurück gibt.

              So weit so gut. Nun kann ja aber eine Seite mehrere Nodes beinhalten, die z. T. eigene JS- und/oder CSS-Dateien und/oder Meta-Informationen benötigen/ausgeben wollen.

              Da ja diese Dinge von der Template-Node ausgegeben werden müssen, benötige ich ja eine zentrale "Sammelstelle" für diese Informationen. Und dafür hatte ich eben eine Art spezialisierte Registry implementiert. Allerdings ist da eben die Sache, dass mir das nicht so super perfekt gefällt. Mich interessiert eure Meinung zu diesem speziellen Fall.

              EDIT: So, wie sich die Screezehead-Extension vom APF für mich darstellt, kommt sie anscheinend nur im Template zum Einsatz ohne die Möglichkeit, die auszugebenden Informationen zu beenflussen. Sehe ich da was falsch?

              Kommentar


              • #22
                Ich hätte nie gedacht, dass sowas einfaches und meistens unwichtiges wie Meta-Tags mehrere Seiten in einem Forum füllen können.

                Ich würde einmal meine Herangehensweise erklären (und ich spreche in den Worten von ZF).

                Wenn es ein sehr statischer Meta-Tag sein soll, würde ich ihn im Layout direkt angeben:
                PHP-Code:
                <head><?php print $this->headMeta()->prependName('Generator''My very cool CMS system'); ?></head>
                Wenn ich ein wenig die Möglichkeit bieten möchte Meta-Tags zu konfigurieren, dann würde ich das in der application.ini (also meiner Konfiguration) erlauben:
                Code:
                resources.meta.foobar.type = "name"
                resources.meta.foobar.keyValue = "keywords"
                resources.meta.foobar.content = "Kartoffeln, Bananen, Äpfel"
                Dafür entweder einen Resource-Loader oder das ganze in der Bootstrap einlesen und an das View weiterleiten (Tipp: in Zukunft geht resources.view.assign.name = "key" (http://framework.zend.com/issues/browse/ZF-10042))

                Wenn es komplett konfigurierbar sein soll, dann würde ich einen FrontController-Plugin dafür entwickeln, der die Daten direkt aus einer Datenbank holt (nein kein Model) und diese an das View durchreicht.

                Kommentar


                • #23
                  EDIT: So, wie sich die Screezehead-Extension vom APF für mich darstellt, kommt sie anscheinend nur im Template zum Einsatz ohne die Möglichkeit, die auszugebenden Informationen zu beenflussen. Sehe ich da was falsch?
                  Das war mal so, früher war das Problem, dass zu spät hinzugefügte Angaben nicht mehr abgearbeitet wurden. Dies wurde allerdings geändert, sodass man nun immer die Möglichkeit hat, die Informationen zu beeinflussen (man kann Informationen sowohl in einem Template als auch in einem Controller oder einer Frontcontroller Action hinzufügen)

                  Kommentar


                  • #24
                    meistens unwichtiges wie Meta-Tags
                    Es geht ja nicht nur darum - Das war nur ein Bsp. für Header-Informationen.

                    man kann Informationen sowohl in einem Template als auch in einem Controller oder einer Frontcontroller Action hinzufügen
                    Dann scheint das ja aber auch auf eine Art Registry hinauszulaufen, oder?

                    Kommentar


                    • #25
                      @crash
                      wie es das ZF macht hatten wir schon.
                      Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                      Kommentar


                      • #26
                        in die Template-Node injiziert
                        Node ist doch nur ein Knoten, ein Punkt innerhalb eines Gerüsts.
                        Da kann man doch nichts reininjizieren, jedenfalls nicht die Ausgabe.

                        http://en.wikipedia.org/wiki/Node_%2...ter_science%29
                        Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                        Kommentar


                        • #27
                          Dann scheint das ja aber auch auf eine Art Registry hinauszulaufen, oder?
                          Ja, eigentlich schon. Die hinzugefügten Informationen werden als Nodes im HtmlHeaderManager abgelegt und später dann über einen OutputFilter ausgegeben. (Vorher wurden die Nodes in der Transformationsphase einer taglib ausgegeben, sodass man nichts mehr daran ändern konnte, sobald die taglib transformiert war)

                          Kommentar


                          • #28
                            Node ist doch nur ein Knoten, ein Punkt innerhalb eines Gerüsts.
                            Warum. Es gibt noch ein anderen Framework (Weiß leider den Namen nicht mehr), das ähnlich funktioniert - Da nannte sich das "Tiles" (Von Kacheln). Vielleicht wäre das eine bessere Bezeichnung gewesen.

                            Beim zweiten Bsp. auf der verlinkten Seite sieht man doch, dass ein Knoten Daten enthalten kann.

                            Um es zu verdeutlichen. Es funktioniert recht simpel. Man holt sich eine Instanz einer Node-Klasse
                            PHP-Code:
                            $node $app->getNode('template.irgendwas'); 
                            Dann kann man Daten injizieren
                            PHP-Code:
                            $node->assign('key''value');
                            ... 
                            Auf diese Art und Weise wird das auch der Inhalt injiziert, der innerhalb des Templates ausgegeben wird.

                            @KarlEgon: Ah, alles klar - Das klingt so ziemlich nach meiner Vorgehensweise, außer, dass die Ausgabe/Umwandlung an einer anderen Stelle statt findet.

                            Kommentar


                            • #29
                              Ich arbeite mich auch gerade ins ZF ein. Die Meta-Tags etc. setze ich zur Zeit im Layout-Script, was nach der Kernaussage dieses Threads thematisch falsch ist.
                              Die Idee als Front-Controller-Plugin finde ich gut und werde ich auch so umsetzen. Nur die Konfiguration über separate Dateien kann ich nicht nachvollziehen.

                              Zitat von lcrash Beitrag anzeigen
                              Wenn ich ein wenig die Möglichkeit bieten möchte Meta-Tags zu konfigurieren, dann würde ich das in der application.ini (also meiner Konfiguration) erlauben:
                              Code:
                              resources.meta.foobar.type = "name"
                              resources.meta.foobar.keyValue = "keywords"
                              resources.meta.foobar.content = "Kartoffeln, Bananen, Äpfel"
                              Zitat von rudygotya Beitrag anzeigen
                              Kommt auch wieder auf die Komplexität der Anwendung an. titles/description leg ich in einem Fall einfach per xml-Datei fest, a la
                              Code:
                              <?xml version="1.0" encoding="UTF-8"?>
                              <root>
                                  <default
                                      title="title == fallbacktitle, wenn für action nicht defined"
                                      description="meta description"
                                  >
                                      <index>
                                          <faq
                                              title="FAQ - title
                                              desc="..."
                                          />
                                      </index>
                              Diese Dinge sind doch eng mit der Navigation verknüpft. Warum definiert ihr hier separate Konfigurationen?
                              Die Navigation erstelle ich aus einer XML-Datei. Diese könnte man doch mit speziellen Tags für die zusätzlichem Meta-Informationen erweitern. Den Titel könnte man doch auch wunderbar per Breadcrumbs-Funktionalität generieren.

                              Hat das einen Grund, warum ihr diese Einstellungen auslagert bzw. wie generiert ihr eure Navigation?

                              Kommentar


                              • #30
                                Eigentlich sind sie eng mit dem Inhalt verknüpft. Navigationen müssen nicht zwingend eine Inhaltsstruktur (komplett) abbilden.
                                --

                                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                                Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                                --

                                Kommentar

                                Lädt...
                                X