Das weiss ich nicht. Eine Service-Schicht ist mir bis dato unbekannt (oder sprichst du von DI Containern?)

Ich weiss momentan nicht vor und nicht zurück. Der Gedanke eines komplett Logikfreien Templates reizt mich, aber die Vorteile werden von den Nachteilen regelrecht zerdrückt, und ich weiss nicht, wie ich dieses Dilemma lösen kann.

@Trainmaster: "Service-Schicht" ist ein Buzzword, das hier konkret nichts zu suchen hat. Das ist wie "Nutze eine Zahnbürste zum Zähneputzen". Erst eine Aussage über welche Bürste und welche Zahnpasta führt zum Ziel.

Das mag nach einem Vorteil klingen, aber meiner Erfahrung triffst du du diese Art der Wiederverwendung nicht allzuoft. Sollte sie notwendig sein, kannst du gleichartiges Aussehen durch Auslagern von Template-Fragmenten erreichen. Das APF unterstützt das beispielsweise mit dem <core:appendnode/>-Tag, der Inhalte eines Templates in den "aufrufenden" Knoten injiziert als wären diese dort definiert.
Weiterhin hast du in Web-Anwendungen immer noch CSS zur bedingten Formatierung (z.B. gleiche Inhalte jedoch in einer anderen Kaskade) zur Verfügung.

Schau dir mal http://adventurephpfra.svn.sourcefor...11&view=markup an. Dieser Controller baut ein Formular auf, validiert dieses und speichert die Inhalte mit Hilfe eines Service. Gleichzeitig kann es bei Validierung eine Fehlermeldung anzeigen (siehe "Anweisung" oben) und zum richtigen Ziel-View weiterleiten.
Unter http://adventurephpfra.svn.sourcefor...83&view=markup findest du noch einen Controller, der eine Liste von Benutzern, deren Rollen und Gruppen ausgibt. Dieser beinhaltet im Wesentlichen den Transport der Inhalte zum View, der im Bereich der Rollen und Gruppen noch besser gemacht werden kann, jedoch aus Gründen der schnellen Implementierung so wie angezeigt ausgeführt ist. Die bessere Lösung wäre eine Iterator-Komponente zu befüllen, wie das unter http://adventurephpfra.svn.sourcefor...83&view=markup zu sehen ist.

Das sehe ich anders. Was du beispielsweise (= Liste von Benutzern, deren Rollen und Gruppen generieren) als Controller beschreibst, könnte bei mir gleichermaßen ein Service sein. Aber wollen wir uns nicht an der Interpretation von Begrifflichkeiten aufhängen ...

Da hast du Recht.

Quasi nichts anderes als das einbinden eines Templates aus einer anderen heraus..?


Ich weiss nicht, was ich davon halten soll. Eine Helfermethode im Controller generiert HTML - genau das wollte ich tunlichst vermeiden. Bei mir gibt es nur zwei Optionen: Entweder, wiederholende Elemente werden im Template selber iteriert (was bedeutet, dass die View etwas Logik ausführen kann), oder aber die View selbst enthält kein Stück Logik und alle DOM-Anpassungen (wie z.B. Schleifen oder isset()-Fragen) werden aus dem Controller heraus oder via "ViewBridge" eingepflügt, via DOM-Manipulator.

@Trainmaster:
Wir sprechen doch von MVC - korrekt? Falls ja, ist das Listen von Rollen und Gruppen eine "Aktion", die unweigerlich zur Darstellung von Inhalten für den End-Anwender führt. Damit ist diese "Aktion" eine Controller-Funktion und kein Service im klassischen Sinne einer Service-Orientierung.

@dsentker:
Korrekt.

Ich hatte das Beispiel ja aufgeführt um ein Negativ-Beispiel zu zeigen und wie es besser gemacht werden soll. Die Ausgabe via Iterator ist demnach die präferierte Lösung.

Hierzu präferiere ich, dass die View-relevante Logik so gekapselt ist, dass sie vom Controller nur noch angestossen werden muss und selbstständig die Ausgabe erledigt. Die Logik - wobei Iteration als Logik zu bezeichnen schon fast Haarspalterei ist - kann dann sehr schön wiederverwendet werden. Steuerst du komplett vom Controller, bist du an Vererbung (Mehrfachvererbung gibt es in PHP nicht!) und komische Konstrukte wie Traits für die Wiederverwendung gebunden.

Beantwortet das deine Frage?

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.

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.

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.

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ß

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.

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.

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.