xm22

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?

Mister Ad

lstegelitz

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)

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

xm22

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.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

xm22

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.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Koala

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)

__________________
Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.