dsentker

Das schließt aber auch das Zuweisen von Variablen an die Templates ein, oder? Das "nur noch anstoßen" ist ja die Lösung, die einen gewissen Teil von Logik (und sei es mal nur das Iterieren) in das Template selbst verfrachtet - oder in der von mir zur Diskussion gestellten "View Bridge".

Was spricht dagegen, sein Layout in Bereiche zu kapseln? Es muss ja nur einmal ein "HauptLayout" erstellt werden, und Kindsklassen können dann das überschreiben, was in ihren Bereich fällt. Die allgemeine Layout-View sieht dann etwa so aus:

In dem Controller "Auth" beispielsweise ruft die Action "login" dann die ViewBrdige "loginView" auf. Diese erbt von der o.g. Klasse und überschreibt die relevanten Dinge:
Wirklich ausgereift ist das noch nicht (!), aber so oder so ähnlich könnte man Templates komplett ohne interne Logik erstellen. Auf diese Weise können Einzelne Views CSS- oder JS-Komponenten registrieren lassen und diese dann in der obersten Ebene einbinden lassen.

__________________

Mister Ad

dr.e.

Meine Vorgehensweise (siehe APF) schließt das Füllen von Platzhaltern in Controllern explizit ein. Insofern ist eine View Bridge hier ebenfalls überflüssig, da die View-Komponente die Ausgabe daraus entsprechend generieren kann. "Views ohne Logik" ist ja keine Forderung nach einer "dummen" View, sondern einer View ohne Business-Logik! Die "dumme" Generierung von HTML aus dem Wert eines Platzhalter ist dabei völlig legitim.

Dieser Ansatz sieht sehr nach ZF, CakePHP & Co. aus, da diese kein mehrschichtiges MVC unterstützen. Hier bist du gezwungen, Abhängigkeiten von View-Bausteinen oder Bereichen deiner Applikation in deinem konkreten Controller aufzulösen. Beispiel: dein Controller für den Content-Bereich muss auch das Menü und den Header und den Footer darstellen. Exakt diese Vorgehensweise bildet dein Controller-Beispiel ab und verletzt damit das SoC (separation of concerns) Paradigma.

Umgekehrt formuliert: du möchtest dich in deiner Login-Komponente nicht auch noch im das Menü, den Footer o.ä. kümmern, denn das ist Aufgabe der Navigation und des Footers etc.

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

Trainmaster

In gewisser Weise schon, das ist korrekt. Allerdings bin ich nach wie vor anderer Meinung. Um nochmals auf dein Beispiel einzugehen argumentiere ich damit, dass das Listen von Gruppen und Rollen nicht zwangsläufig eine Controller-Aktion sein muss. Spätestens dann, wenn auf der Website an mehreren Stellen die "Liste Gruppen und Rollen"-Funktionalität benötigt wird, ist das für mich ein Fall für die Service-Schicht. Und zur Darstellung von Inhalten für den End-Anwender führt es nur dann, wenn der Controller die entsprechenden Maßnahmen ergreift. Ein exklusives Recht, das nur dem Controller zusteht. Damit würde ich auch im Wesentlichen den Unterschied zwischen Controllern und Services erklären.

archer42

Mal ein wenig Off-Topic mein Beitrag.
Hoffe der Thread kann die kurze Nebenfrage (er)tragen.

Ich verstehe persönlich eigentlich nicht, wieso ein Designer da überhaupt an den CSS/HTML Code rangeht/ranmuss?
Ist es nicht sinnvoller, sich von dem Designer eine Photoshopvorlage mit leichter Vorstrukturierung + Farbcodes geben zu lassen und das wird dann einfach vom Programmierer implementiert?

Gruß

dsentker

Ja du hast Recht, rein theretisch sollte es einen Controller für die Navigation geben, einen Controller für den Footer [etc] da jeder dieser Segmente seine eigene Logik enthält (Einfaches Beispiel: Kontaktformular im Footer). Da macht HMVC dann sicherlich Sinn. Ich sollte mich also mehr auf die Aufteilung der Controller konzentrieren und nicht auf die Aufteilung der Aufteilung der Views

Bei uns läuft es so, manchmal ist sogar der Entwickler gleichzeitig der Designer, er macht alles. Ich kann aber auch die andere Situation nachvollziehen, also das in größeren Unternehmen ein Team das Design erstellt, das andere Team wandelt dies in HTML um und wiederum ein drittes Team ist für die Programmierung zuständig. Ich halte es aber generell für falsch, den Designern zu unterstellen, sie wären zu doof, um PHP-Code in die Templates einzufügen. Damit argumentiert ja auch Smarty: Ob der Designer nun PHP-Basics lernt oder die Smarty-Syntax, ist unerheblich.

__________________

Koala

Es geht nicht um Designer sondern um WEBdesigner.
Die setzen die psd-Vorlagen in html/css um (und erstellen sie manchmal auch selbst).

Was hat denn das Umsetzen von psd in html/css mit Programmieren zu tun ?

Ich kenn Programmierer die können wunderbar Datenbanken designen und Ablaufdiagramme erstellen,
erzeugen aber jämmerlich miesen html/css-Code.

Das können doch wirklich Leute besser die sich tagtäglich mit den verschiedenen Browser-Varianten
und deren CSS-Umsetzung herumschlagen.

mein Designer würde mich erschlagen.
Da wird nichts "leicht" vorstrukturiert, sondern pixelgenau vorgegeben.

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

mquadrat

Früher nichts, heute einiges. Die AJAX Aufrufziele müssen da sein, die Behandlung der Rückgaben, die Trigger für Animationen, etc etc. Entfällt natürlich bei 08/15 Seiten, die keine große Interaktion zwischen Front- und Backend haben.

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de