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

  • xm22
    hat ein Thema erstellt Wo Zuweisung von Metatags in MVC.

    Wo Zuweisung von Metatags in MVC

    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?

  • dr.e.
    antwortet
    *dr.e. is going offline...*

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    Also jetzt wirds albern.

    Einen Kommentar schreiben:


  • lcrash
    antwortet
    Soll es ja nicht, der ErrorController soll also nicht beansprucht werden.

    Einen Kommentar schreiben:


  • dr.e.
    antwortet
    Das ist kein Argument! Sofern es eine Exception ist, die einen globalen "Schaden anrichten" soll, dann wirf sie wenigstens und überlasse es dem globalen Exception-Handling-Mechanismus.

    Einen Kommentar schreiben:


  • lcrash
    antwortet
    Dort wüsste ich genauso wenig was ich dort behandeln könnte.

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    Das selbe was Du im jetzt nicht vorhandenen else-Zweig behandelst?

    Einen Kommentar schreiben:


  • lcrash
    antwortet
    Weil ich meine, dass die Navigation optional bleiben muss. Ich wüsste auch nicht, was ich im catch() behandeln könnte.

    Einen Kommentar schreiben:


  • dr.e.
    antwortet
    @Icrash: warum musst du vor dem Instanziieren von Zend_Config_Xml noch mit file_exists() prüfen? Das sollte doch mindestens eine Exception geben die sich mit catch behandeln lässt.

    Einen Kommentar schreiben:


  • lcrash
    antwortet
    Ich habe eine navigation.xml, in der die Daten sind, die reiche ich als Zend_Config-Objekt an Zend_Navigation durch (über die Bootstrap).

    Die XML ist im selben Format, wie es der Resource-Loader in ZF verlangt:

    Code:
    [...]
    <resources>
        <navigation>
            <pages>
    [...]
    Die Methode dazu:
    PHP-Code:
        protected function _initNavigationConfiguration()
        {
            
    $navigation_config APPLICATION_PATH '/configs/navigation.xml';
            if (
    file_exists($navigation_config)) {
                
    $nav = new Zend_Config_Xml($navigation_config);
                
    $this->setOptions(
                    
    $this->mergeOptions(
                        array(
    'resources' => $nav->toArray())
                    )
                );
                
    // hier erzeuge ich ein neues Zend_Config-Objekt
                // welches in die Registry speichere um auf die
                // Konfiguration später zugreifen zu können
                
    $this->_initConfiguration();
            }
        } 

    Einen Kommentar schreiben:


  • Gast-Avatar
    Ein Gast antwortete
    Zitat von nikosch Beitrag anzeigen
    Navigationen müssen nicht zwingend eine Inhaltsstruktur (komplett) abbilden.
    Diese Zweifel hatte ich auch während des Schreibens im Hinterkopf. Doch könnte man dann diese Seiten in der Navigation auf visible false - so zumindest mein erster Gedanke.

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:


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

    Einen Kommentar schreiben:

Lädt...
X