Ankündigung

Einklappen
Keine Ankündigung bisher.

Wo Zuweisung von Metatags in MVC

Einklappen

Neue Werbung 2019

Einklappen
X
Einklappen
  • Seite von 3
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
Vorherige 1 2 3 Weiter
  • Koala
    antwortet
    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

    Einen Kommentar schreiben:

  • Koala
    antwortet
    @crash
    wie es das ZF macht hatten wir schon.

    Einen Kommentar schreiben:

  • Gast-Avatar
    Ein Gast antwortete
    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?

    Einen Kommentar schreiben:

  • KarlEgon
    antwortet
    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)

    Einen Kommentar schreiben:

  • lcrash
    antwortet
    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.

    Einen Kommentar schreiben:

  • Gast-Avatar
    Ein Gast antwortete
    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?

    Einen Kommentar schreiben:

  • dr.e.
    antwortet
    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.

    Einen Kommentar schreiben:

  • rudygotya
    antwortet
    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

    Einen Kommentar schreiben:

  • dr.e.
    antwortet
    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.

    Einen Kommentar schreiben:

  • nikosch
    antwortet
    Ganz genau.

    Einen Kommentar schreiben:

  • Koala
    antwortet
    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,

    Einen Kommentar schreiben:

  • Flor1an
    antwortet
    Der Code steht auch nicht im Controller. Der ist komplett eigenständig und hängt im Dispatch Vorgang des ganzen Frameworks drin, wird also vor oder nach dem Controller ausgeführt.

    Einen Kommentar schreiben:

  • nikosch
    antwortet
    Trotzdem wirds ja im Controller ausgeführt, nicht in der View-Logik?

    Einen Kommentar schreiben:

  • rudygotya
    antwortet
    Ne, eigtl nicht. Das Plugin-System des ZF-FrontControllers bietet dir Pseudo-Events, bei denen du dich einklinken kannst. Mein Layout-Plugin registriert sich beim Bootstrapping im FrontController, dort klinkt es sich dann (vorsicht, buzz) im Dispatch-Loop ein. Das Plugin bedient dann wieder die zuständigen View-Helper, die die Headlinks,... setzen. Keine Magie, eigentlich eine sehr einfache Lösung. Dazu ist das hübsch gekapselt.

    Die Doku zum Pluginsystem findest du hier, falls du das nachlesen möchtest, ist ganz hübsch erklärt.

    Hier bissi pseudo-Code:

    PHP-Code:
    <?php
    class Namespace_Plugin_SetLayout extends Zend_Controller_Plugin_Abstract {

            /**
         * @param Zend_Controller_Request_Abstract $request
         * @return void
         */
            public function dispatchLoopStartup( Zend_Controller_Request_Abstract $request ) {
                $this->_setEnv();
                // header setzen
                $this->_setHeadMeta();
                $this->_setHeadLinks();
            
                $this->_jQuery = $jquery = $this->_view->jQuery();
                $jquery->enable();
                $jquery->setVersion( '1.5.2' );
                $jquery->useCdn();

                $controller = $request ->getControllerName();
                $module =
                    $request->getModuleName() === NULL
                        ? 'default'
                        : $request->getModuleName();
            
                $this->_addHeaderFiles( 'any' );
            
            switch (    $module) {
                case     'admin' :
                        $this->_view->headTitle($module . "/" . $controller ."/");
                default:
                        $this->_view->headTitle( "fixer prefix title" )->setSeparator(' / ');
                    if( !    $request->isXmlHttpRequest() ) {
                            $this->_setDefaultEnv();
                    } else {
                            $this->_setMobileEnv();
                    }
            }
        }

    Einen Kommentar schreiben:

  • Koala
    antwortet
    Im Controller setz ich so kaum mehr Metadaten, jedoch nicht in der View
    Ich lade je nach Layout (je nach Modul und Art der Anfrage) ein Plugin, das ein konfigurierbares Set an gemeinsamen Metadaten generiert und den View Helpern (headScript, headMeta, ..) übergibt.
    Dann entspricht Dein Plugin doch einem Controller (ActionHelper ??).

    Einen Kommentar schreiben:

Vorherige 1 2 3 Weiter
Lädt...
X