Wo Zuweisung von Metatags in MVC

[Gast]

Hi,

ich weiß nicht, ob das unter Software-Design fällt, aber ich denke, im weiten Sinne schon.

Und zwar überlege ich jetzt schon einige Zeit, wie man mit HTML-Metadaten in einer MVC-Applikation umgeht. Für mich gibt es drei Wege, die allerdings alle nicht besonders sauber erscheinen:

1. Die Metatags werden im View generiert und entsprechend ausgegeben (Z. B. in einem Template).
2. Die Metatags werden per Controller/Model an das View übergeben.
3. Die Metatags werden in einer Registry o. ä. gesammelt und dann letztendlich im View oder Template oder wo auch immer ausgegeben.

Da die aktuelle Applikation - in diesem Fall basierend auf meinem Framework - das HMVC-Pattern benutzt, tendiere ich zu Punkt 3, da die verschiedenen Bestandteile alle die Möglichkeit benutzen können sollen, quasi Ihren "Senf dazu geben zu können". Was haltet ihr davon?

[lstegelitz]

3. Die Metatags werden in einer Registry o. ä. gesammelt und dann letztendlich im View oder Template oder wo auch immer ausgegeben.

Macht so am meisten Sinn. Ich machs jedenfall so ähnlich, und auch dynamische JS Einbindung funktioniert vom Prinzip her bei mir so (eine Subkomponente kann ein JS registrieren, wenn es das benötigt - die zentrale Steuerung verhindert zudem, daß das JS x-mal eingebunden wird, wenn die Komponente mehrfach auf einer Seite verwendet wird)

[Gast]

Stimmt - Habe ich vergessen zu sagen: Diese "Registry" bezieht sich auf alles, was nachher im Template angezeigt/eingebunden wird (Metatags, Title, css, js, ...)

[Flor1an]

Hey, ich kann dir ja mal erzählen wie das bei mir läuft. Ich nutz das Zend Framework und was ich nutze sind:
- title
- css/js files
- inline javascript
- breadcrumb
- opengraph werte
- metatags
Im Zend gibts im View so genannte View Helper, das sind Objekte mit einer Funktion die aufgerufen werden wenn sie im View genutzt werden, da das Objekt immer nur einmal Instanziert wird kann ich über den ganzen Ablauf hinweg mein Zeug da rein speichern. Dient also im Grunde wie eine Registry, aufrufen tu ich das im View weil das für mich alles Dinge sind die zur Ausgabe gehören. Funktioniert für mich sehr gut weil ich wirklich pro einzelner Seite/View einstellen kann was dann später wirklich alles angezeigt werden soll.

[nikosch]

Metatags und Titel sind genauso Inhalte wie der eigentliche Content. Machs da, wo Du auch den Content verwaltest. Wenn Du gemeinsame MT für verschiedenen Content verwendest, musst Du eben dort eine Abstraktionsebene einführen.
Language und base href z.B. würde ich eher auf Controllerebene ansiedeln. Individuelle Stylesheets und Javascripte sind mit dem Content eng verknüpft, gehören für mich aber auf die Ebene der Modulverwaltung - denn daran kann man die optimal anknüpfen.

[Gast]

Dann ist der Weg, den ich momentan gehe anscheinend ganz akzeptabel. Danke für eure Statements!

[dr.e.]

Da es sich bei HTML-Meta-Daten um - mehr oder weniger - dynamische Daten handelt sehe ich diese definitiv im Controller.

Die Registry wird allzuoft als Daten- oder Instanzen-Store genutzt, was IMHO insbesondere bei ersterem nicht im Sinne des Erfinders ist.

[Flor1an]

Aber gehören solche Dinge wie Titel, Meta-Tags, das Laden von JS/CSS Files und ähnliches nicht komplett zur Ausgabe? Angenommen ich möchte meinen Controller behalten und nen neuen View drüber setzen, z.b. nicht HTML sondern XML oder JSON oder sonstiges, dann hätte ich auch bei allen anderen Arten von Views die Meta Tags oder die Teile die JS/CSS laden. Die gehören aber bei den Views gar nicht dazu. Von daher finde ich es eigentlich geschickter solche Sachen im View selbst zu erledigen damit der View austauschbar bleibt.

[nikosch]

Es geht ja um die Meta-Daten nicht die Meta-Tags selbst. Und ich kann mir schon vorstellen, dass die in anderen Kontexten woanders auch Anwendung finden könnten. Ist ja nur Plain text.

[Koala]

Aber gehören solche Dinge wie Titel, Meta-Tags, das Laden von JS/CSS Files und ähnliches nicht komplett zur Ausgabe? Angenommen ich möchte meinen Controller behalten und nen neuen View drüber setzen, z.b. nicht HTML sondern XML oder JSON oder sonstiges, dann hätte ich auch bei allen anderen Arten von Views die Meta Tags oder die Teile die JS/CSS laden. Die gehören aber bei den Views gar nicht dazu. Von daher finde ich es eigentlich geschickter solche Sachen im View selbst zu erledigen damit der View austauschbar bleibt.

Der Controller entscheidet welche meta-Daten benötigt werden
und welche View geladen wird.

Wenn XML ausgegeben werden soll, dann werden die meta-Daten eben erst gar nicht geladen.

Die View bleibt immer austauschbar, da die View nur meta-Tags ausgibt
wenn meta-Daten vorliegen. (Design-Logik)

[rudygotya]

Ich benutze wie Florian das ZF. 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. Das Set selbst wird über eine layout-Config definiert, head titltes setze ich entweder per xml-Konfiguration im Plugin oder überschreibe diese im Controller (wenn sich z.b. ein title aus einem DB Resultset generiert). Im Controller setz ich so kaum mehr Metadaten, jedoch nicht in der View (auch im Bezug auf JS/CSS).

[Koala]

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 ??).

[rudygotya]

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
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();
                }
        }
    }

[nikosch]

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

[Flor1an]

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.