nicht angemeldet
MVC Verständnisproblem
Hi,
der Controller bekommt die Daten vom Model und verarbeitet sie. Soweit habe ich das auch verstanden.
In "Beispiel-Anwendungen" sieht man aber selten wo eine komplexere Verarbeitung von Daten statt findet.
Was ist, wenn ich nicht einfach Daten vom Model 1 zu 1 übernehme und dan die Views weitergebe? Sollte das alles im Controller stattfinden oder in einer getrennten Klasse?
MfG Naps
-
Hello,
Was ist, wenn ich nicht einfach Daten vom Model 1 zu 1 übernehme und dan die Views weitergebe? Sollte das alles im Controller stattfinden oder in einer getrennten Klasse?
Guckst Du z.B. hier:
https://de.wikipedia.org/wiki/Model_View_Controller
Ich kann es leider nicht besser erklären.MVC ist für mich noch eins der Entwurfsmuster, die man tatsächlich auch in der Praxis anwenden kann und wiedererkennbar anwendet.
Die anderen sind dann teilweise eher wissenschaftlicher Natur :-)
https://de.wikipedia.org/wiki/Entwurfsmuster#Liste_von_MusternLiebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Tach!
der Controller bekommt die Daten vom Model und verarbeitet sie. Soweit habe ich das auch verstanden.
Der Controller steuert nur, er delegiert die Aufgaben zu passenden Komponenten. Das Model ist nicht nur eine Schnittstelle zur Datenhaltung sondern kann auch die Geschäftslogik enthalten, also Berechnungen anstellen. Weiterhin ist nicht gesagt, dass man seine Code dann nur in diese drei Teile aufteilen darf. Man kann durchaus auch noch weitere Komponenten erstellen und vom Controller oder dem Model aus ansprechen.
In "Beispiel-Anwendungen" sieht man aber selten wo eine komplexere Verarbeitung von Daten statt findet.
Das ist üblicherweise so individuell, dass es da nicht unbedingt eine Regel (oder gar ein Gesetz) dazu gibt. Am Ende musst du deine Anwendung fertigbekommen. Ob sie dabei exakt dem einen der anderen Muster, der einen oder anderen Theorie entspricht, ist nicht kriegsentscheidend. Hauptsache sie bleibt einfach zu warten und gegebenenfalls zu erweitern.
dedlfix.
-
hi,
Was ist, wenn ich nicht einfach Daten vom Model 1 zu 1 übernehme und dan die Views weitergebe? Sollte das alles im Controller stattfinden oder in einer getrennten Klasse?
Interessant wird hier das decorator pattern. Es ist umstritten aber es ermöglicht, dass Controller-Classes an beliebige View-Classes gebunden werden, die View-Class wird zur Laufzeit mit Controller-Funktionalitäten ausgestattet bzw. erweitert; Beispiel:
Du hast eine ViewClass (nennen wir sie 'ViewClass'), die bisher nur irgendwelche Dokumente (URLs /foo.html, /bar.html...) ausgibt. Eines der Dokumente liegt auf /foo.html und soll ein Feedback-Formular bekommen. Klarer Fall: Hierzu sind Eingaben zu verarbeiten, was /foo.html nicht kann, die zuständige ViewClass 'ViewClass' hat keinen Controller. Lösung: /foo.html bekommt ein zusätzliches Attribut verpasst:
control=feedback
feedback ist eine Klasse, die erst in dem Moment, wenn Eingaben über /foo.html ankommen, weiß:
Aha, ich gehöre ab sofort zur ViewClass. Die Instanz der ViewClass, deren Erstellung zu diesem Zeitpunkt bereits in der Vergangenheit liegt, steht, aufgrund des decorator-patterns in ALLEN Methoden der class 'feedback' zur Verfügung, Beispiel:# class 'feedback' sub control{ my $self = shift; # Instanz der ViewClass if($self->param('senden')){ # $self ruft eine seiner Methoden auf ('param') } # sende feedback else{ return $self->errorP(title => 'Eingabefehler', descr => 'Unbekannter Parameter') } }Andere Lösung (herkömmlich, !decorator): class feedback extends VieClass
Aber hier müsstest Du von vornherein die Instanz über ViewClass::feedback erstellen.Horst
-
Hallo,
Was ist, wenn ich nicht einfach Daten vom Model 1 zu 1 übernehme und dan die Views weitergebe? Sollte das alles im Controller stattfinden oder in einer getrennten Klasse?
Generell würde ich in das Model möglichst wenig Geschäftslogik packen. Ins Model gehören IMO einfache Zugriffsfunktionen für die Daten und meinetwegen noch einfache Konvertierungsfunktionen (die bestimmte Daten so aufbereiten, dass sie in der Form vorliegen, wie sie der Controller braucht).
Business-Logik ist eher in der Controller-Schicht zu Hause.
Ob Du das aber alles im Controller abdecken willst, hängt ein bisschen davon ab, wie umfangreich die Berechnungen sind, und ob Du sie nur in einem Controller benötigst oder in mehreren.Beispiel: Du baust ein Blog-System, und hast folglich
- Ein "UserModel" welches Daten von Benutzern (Name, Email, Passwort usw.) bereit stellt
- Einen "UserController", welcher Benutzer anlegen, löschen usw. kann
- Ein "BlogArticleModel" mit den Daten eines Blog-Eintrages
- Einen "BlogArticleController" zum Erstellen, Verwalten und löschen von Einträgen.
Angenommen, der "BlogArticleController" soll das Anlegen von Artikeln nur erlauben, wenn der Benutzer eingeloggt ist. Wo baut man die Methoden zur Zugriffsprüfung ein, möglichst ohne Abhängigkeiten von Komponenten zu erzeugen, die nichts miteinander zu tun haben?
In so einem Fall würde ich eine eigene Klasse vorsehen, welche auf das UserModel zugreift, und in der Zugriffsprügungen stattfinden. Diese Klasse kann dann von beliebigen Controllern genutzt werden.
In großen Systemen wird so etwas oft als "Dienst" realisiert - jede Klasse kann über einen bestimmten Mechanismus einen Dienst aufrufen, der die benötigte Funktionalität bereit stellt (in unserem Beispiel also sowas wie einen "Authentifizierungs-Dienst", der den Benutzer authentifiziert). Dienste können dann ihrerseits wieder andere Dienste aufrufen.
Bei einer solchen Service-orientierten Architektur übernehmen im Extremfall die Controller nur noch die Aufgabe, die Request-Parameter korrekt entgegen zu nehmen und dann an die entsprechenden Dienste zur Verarbeitung weiter zu geben.Aber wie gesagt, so ein Architekturmonster braucht man nur bei großen Systemen. Im Kleinen hilft es schon, sich kleine Helper-Klassen zu bauen.
hope that helps,
Jörg
-
Hello,
Was ist, wenn ich nicht einfach Daten vom Model 1 zu 1 übernehme und dan die Views weitergebe? Sollte das alles im Controller stattfinden oder in einer getrennten Klasse?
Generell würde ich in das Model möglichst wenig Geschäftslogik packen. Ins Model gehören IMO einfache Zugriffsfunktionen für die Daten und meinetwegen noch einfache Konvertierungsfunktionen (die bestimmte Daten so aufbereiten, dass sie in der Form vorliegen, wie sie der Controller braucht).
Business-Logik ist eher in der Controller-Schicht zu Hause.
Veto!
Was meinst Du, wozu Datenbanken sowas wie Trigger, Stored Routines, Strored Procedures, Zugriffsrechte, Benutzervariablen, usw. haben?
Man kann einen Großteil der Geschäftslogik im Model unterbringen, sodass man das Gesamtkunstwerk auch mit unterschiedlichen Controllern oder Views, sogar auf unterschiedlichen Plattformen, gemeinsam nutzen kann.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Was meinst Du, wozu Datenbanken sowas wie Trigger, Stored Routines, Strored Procedures, Zugriffsrechte, Benutzervariablen, usw. haben?
In erster Linie aus historischen Gründen. Damals galten andere Paradigmen der Anwendungsentwicklung.
In heutigen MVC-Webanwendungen – zumindest bei denjenigen, von denen hier die Rede ist – wird solche Logik in aller Regel im Anwendungscode implementiert. Von der Datenbank wird durch objekt-relationale Mapper abstrahiert.
Performance-kritische Datenbankabfragen werden weiterhin in der jeweiligen Abfragesprache geschrieben. Oder es kommen weitere Services ins Spiel, um die Logik in der Datenbank zu reduzieren.
Man kann einen Großteil der Geschäftslogik im Model unterbringen, sodass man das Gesamtkunstwerk auch mit unterschiedlichen Controllern oder Views, sogar auf unterschiedlichen Plattformen, gemeinsam nutzen kann.
»Gesamtkunstwerk« ist das richtige Wort…
Der Code der meisten für Webanwendungen verwendeten Hochsprachen läuft ebenfalls auf unterschiedlichen Plattformen.
Mathias
-
Hello,
In erster Linie aus historischen Gründen. Damals galten andere Paradigmen der Anwendungsentwicklung.
In heutigen MVC-Webanwendungen – zumindest bei denjenigen, von denen hier die Rede ist – wird solche Logik in aller Regel im Anwendungscode implementiert. Von der Datenbank wird durch objekt-relationale Mapper abstrahiert.
Man legt die Geschäftsregeln und das Datenbankmodell nicht deshalb ins Model (das ist selten identisch mit den Datenbankmodell), weil das "historisch gewachsen" ist, sondern weil man versucht das Model als Kern zu kapseln. Im Prinzip müssen sich in der Praxis daher alle anderen Module um das Model gruppieren und nicht etwa um den Controller.
Die Kapselung hat zur Folge, dass eine hierarchische Struktur bei der Entwicklung und späteren Benutzung eingehalten werden kann. Das Model ist sozusagen das "Heiligtum" des Unternehmens. Dort hinein haben nur Wenige den vollen Eingriff. Zugriffe darauf müssen über streng definierte und kontrollierte Schnittstellen stattfinden.
Wenn in einer Bank eine neue Schaltersoftware eingeführt wird, bleibt das Heiligtum (Model, Datenbank) möglichst unangetastet. Das spielt sich dann im View und im Controller ab. Ist natürlich jetzt arg vereinfacht, aber so kann man besser verstehen, WARUM heute die Geschäftsregeln wieder möglichst alle ins Model verlagert werden.
Wenn sogar die Wikipedia das so schreibt, muss es doch stimmen *höhöhö* ;-D
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Wenn ich hier von MVC und Models spreche, dann als konkrete Struktur von Webanwendungen. Dafür gibt entsprechende Frameworks in PHP, Python, Ruby, Java usw. Nach denen wurde hier gefragt, denke ich mal. Das Model ist darin meist eine ORM-Klasse, das durch Vererbung bestimmte Methoden mit sich bringt.
Du beschreibst MVC als Architektur für die gesamte IT eines Unternehmens, wobei sämtliche Kernlogik im Model versammelt ist. Das kann ich nachvollziehen, wenn man das Model als darstellungsunabhängige Datenlogik definiert.
Das ist aber nicht die *eine* Modelklasse aus den oben genannten Frameworks. Beispielsweise in Ruby on Rails bringen Active-Record-Models eine Fülle von Aufgaben mit sich. In den letzten Jahren ist man davon abkommen, möglichst viel Logik in dieser einen Klasse unterzubringen. Wie ich (und dedlfix und mrjerk zuvor) geschrieben habe, teilt man die Logik auf in mehrere kleinere Komponenten. Als Gesamtheit bilden die meinetwegen das »Model« der IT-Architektur, denn sie sind isoliert, wiederverwendbar und bieten definierte öffentliche Schnittstellen.
Falls es jemanden interessiert, gute Artikel aus der Rails-Welt zu MVC:
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
http://pivotallabs.com/object-oriented-rails-writing-better-controllers/
http://sporto.github.io/blog/2012/11/15/a-pattern-for-service-objects-in-rails/
http://signalvnoise.com/posts/3372-put-chubby-models-on-a-diet-with-concerns
http://blog.steveklabnik.com/posts/2012-05-07-mixins--a-refactoring-anti-patternMathias
-
-
-
Moin,
Man kann einen Großteil der Geschäftslogik im Model unterbringen, sodass man das Gesamtkunstwerk auch mit unterschiedlichen Controllern oder Views, sogar auf unterschiedlichen Plattformen, gemeinsam nutzen kann.
Ich verstehe Deine Argumentation. Ich glaube aber trotzdem, dass zu viel Geschäftslogik in der Datenbank eher hinderlich ist.
Durch MVC will man ja (u.a.) Abhängigkeiten der Schichten untereinander möglichst vermeiden.
Durch Implementierung der Geschäftslogik in der Datenbank macht man sich aber abhängig von der konkret verwendeten Datenbank, es wird unüberschaubarer, weil man nicht weiss, welcher Teil einer fachlichen Logik in der Datenbank und welcher in den darüber liegenden Software-Schichten unter gebracht ist, und für bestimmte Anwendungsfälle, die nicht direkt in der DB (als stored Procedure o.ä.) implementiert werden können, braucht man dann doch wieder entsprechende Applikationslogik, was widerrum das Risiko erhöht, dass man einzelne Komponenten doppelt schreiben muss (für die Datenbank und die Applikationsschicht).Trigger, Constraints, Stored Procedures usw. sind IMO eine feine Sache, wenn es um das reine Datenmanagement geht, denn dies ist ohnehin abhängig von der verwendeten Datenbank. Etwas wie "Lösche alle Blog-Artikel von User X, sobald dieser gelöscht wird" kann in einer Oracle-Datenbank und einer MongoDB komplett unterschiedlich aussehen, und ist daher auch direkt in der Datenbank zu implementieren (oder falls das nicht geht, in der Model-Schicht). Es würde für die Abstraktion nichts bringen, so eine Funktion in die höheren Schichten (also z.b. in einen Controller) zu ziehen, da man sie ohnehin ändern muss, sobald man das Model austauschen möchte.
-> An dieser Stelle interessiert den Controller nur, dass er einen User und alle seine Datenobjekte löschen kann - wie das passiert, darum kümmert sich das Model (oder direkt die Datenbank, wenn sie entsprechende Mechanismen bereit stellt).Wenn es aber um Fachlichkeiten geht, die losgelöst von der Datenhaltung sind (Beispiel: "Berechne den Gesamtpreis aller Produkte im Warenkorb plus Steuer"), ist es IMO sinnvoller, das auch losgelöst davon zu implementieren. Natürlich kann es aus Performance-Gründen notwendig sein, das trotzdem direkt in der DB zu machen, dann muss man das Paradigma an der Stelle verletzen - aber architektonisch sauberer wäre m.E. der andere Weg.
Ist aber natürlich auch nur meine persönliche Meinung.
Viele Grüße,
Jörg
-
-
Hallo,
In "Beispiel-Anwendungen" sieht man aber selten wo eine komplexere Verarbeitung von Daten statt findet.
Die findet weder in Controllern, Models noch Views statt, sondern meist in separaten Service-Objekten, die auch separat Unit-getestet werden können. Sie operieren höchstens auf einem Model, das z.B. als Abhängigkeit in den Konstruktor oder einen Setter hineingegeben wird. Oder du gibst Rohdaten hinein und es kommt ein Model heraus.
Aus Sicht von Views werden häufig Decorator benutzt, um auf vorformatierte Modeldaten zuzugreifen.
Dasselbe gilt für komplexere Datenbank-Abfragen und -Manipulationen. Bei ORM bieten Model-Klassen oftmals statische Methoden an, die zum einfachen oder komplexen Abfragen von Datensätzen dienen. Sobald das komplexer wird, sollte eine separate Klasse verwendet werden.
MVC ist nur das Grundpattern von Webanwendungen, man kann nicht alles in diese drei Kategorien quetschen. Es sind weitere Objekttypen und Pattern nötig.
Mathias
-
Ola,
das Problem am MVC Model ist dass die einzelnen Bestandteile nicht sauber definiert sind. Es bleibt ein Interpretationsspielraum. So liest man immer wieder verschiedene Ansätze. Hab schon gelesen das Model sei PHP, View sei HTML und der Controller sei Javascript.
Ich sehe das Model als die Daten, der Controller ist die Datenverknüpfung bzw. Verarbeitung und der View sind die Templates, die bei der Darstellung helfen. Javascript wäre eine vierte Ebene.Im Endeffekt sind Software Patterns oder Definitionen total irrelevant. Wenn du es jedoch mit Funktionen schaffst einen sauberen und wiederverwendbaren Code hin zu bekommen, dann brauchst du keine Software Pattern.
Gruß
klarer Sehen
T-Rex-
Oha,
das Problem am MVC Model ist dass die einzelnen Bestandteile nicht sauber definiert sind. Es bleibt ein Interpretationsspielraum. So liest man immer wieder verschiedene Ansätze. Hab schon gelesen das Model sei PHP, View sei HTML und der Controller sei Javascript.
Interessant wirds, wenn eine Viewclass verschiedene Moddels darstellen kann und schon haben wir den Salat: Das ist pure OOP-Praxis, alles was ein Moddl braucht, steckt in den Attributen und wir haben wiederverwertbaren Code ;)
Ich sehe das Model als die Daten, der Controller ist die Datenverknüpfung bzw. Verarbeitung und der View sind die Templates, die bei der Darstellung helfen.
Auch das Template könnte in einem der Atribute namentlich benannt werden.
Javascript wäre eine vierte Ebene.
Warum nicht die gesamte Businesslogik per JS abwickeln, der Server wird nur noch gebraucht, wenn es was Wichtiges zum Speichern oder anderen Clients mitzuteilen gibt.
Im Endeffekt sind Software Patterns oder Definitionen total irrelevant. Wenn du es jedoch mit Funktionen schaffst einen sauberen und wiederverwendbaren Code hin zu bekommen, dann brauchst du keine Software Pattern.
FullAck!
-
Tach!
das Problem am MVC Model ist dass die einzelnen Bestandteile nicht sauber definiert sind. Es bleibt ein Interpretationsspielraum. So liest man immer wieder verschiedene Ansätze. Hab schon gelesen das Model sei PHP, View sei HTML und der Controller sei Javascript.
Wenn der Controller in Javascript geschrieben ist, dann handelt es sich in dem Fall wohl um eine SPA (Single Page Application) die sich vorwiegend im Browser abspielt und die Serverseite nur zur Datenspeicherung verwendet. Allerdings kann die Serverseite ihrerseits auch wieder das MVC-Model verwenden, besonders dann, wenn die API etwas umfangreicher geworden ist. Die serverseitigen Views geben dann zum Beispiel XML oder JSON statt fertigem HTML aus.
Ich sehe das Model als die Daten, der Controller ist die Datenverknüpfung bzw. Verarbeitung und der View sind die Templates, die bei der Darstellung helfen. Javascript wäre eine vierte Ebene.
Oder auch nicht. Dieser Satz sieht mir jedenfalls wieder nach klassischer Web-Anwendung aus, die Javascript für mehr oder weniger nur Effekte und kleine Hilfsmittel auf dem Client verwendet.
Im Endeffekt sind Software Patterns oder Definitionen total irrelevant. Wenn du es jedoch mit Funktionen schaffst einen sauberen und wiederverwendbaren Code hin zu bekommen, dann brauchst du keine Software Pattern.
Ja, man muss dann nicht nur die Geschäftslogik in Code formulieren sondern auch noch Gedanken um die Architektur machen, die man sich beim Anwenden von bewährten Models größtenteils sparen kann. Vorausgesetzt man hat schon genügend Erfahrung mit deren Umgang gesammelt.
dedlfix.
-
hi,
Im Endeffekt sind Software Patterns oder Definitionen total irrelevant. Wenn du es jedoch mit Funktionen schaffst einen sauberen und wiederverwendbaren Code hin zu bekommen, dann brauchst du keine Software Pattern.
Experience patterns ;)
Mein Framework ist historisch gewachsen und nicht aufgrund irgendwelcher Muster entstanden. Was mich bei dieser Entwicklung angetrieben hat, ist die Erfahrung mit Frameworks der Anderen und die ständige Suche nach Verbesserungen und kostengünstigeren Lösungen. So ist mein FW nur historisch "gewachsen", von Code her ist es jedoch "geschrumpft" im Laufe der Jahre.
Nichtsdestoweniger zolle ich all denen, die als Software-Architekten unterwegs sind, jeden Respekt, sie haben es verdient.
Entwurfsmuster sind, abstrakt gesehen: Erfahrungen, von denen Andere profitieren können. Auch ich gebe seit Jahren meine Erfahrungen weiter, einst i-netlab.de heut rolfrost.de
Und ich denke, dass sich auch mein Framework durchaus sehen lassen kann, so habe ich gestern hier mal aufgeschrieben, wie es aufgebaut ist und wie es funktioniert.
Neue Entwurfsmuster wirst Du darin nicht finden, sehr wohl aber wirst Du in meiner FW-Architektur bekannte Muster wiederfinden, auch das decorator patterns, was heute den letzten Schliff bekommen hat ;)
Den Dinos zum Gruß!
--
Spätestens ab Mitte 50 mutiert ein gewöhnlicher Dino zum Sehnix-Saurus: Er braucht eine Brille!
-
-
Hi,
der Controller bekommt die Daten vom Model und verarbeitet sie. Soweit habe ich das auch verstanden.
In "Beispiel-Anwendungen" sieht man aber selten wo eine komplexere Verarbeitung von Daten statt findet.Was ist, wenn ich nicht einfach Daten vom Model 1 zu 1 übernehme und dan die Views weitergebe? Sollte das alles im Controller stattfinden oder in einer getrennten Klasse?
Du setzt falsch an.
MVC kommt nicht aus dem Nichts. Es wurde erdacht und entwickelt, weil man etwas festgestellt hat: bei der Entwicklung von Software passiert es oft, dass sich manche fachlich/inhaltlichen Teile der Software (oder besser gesagt: "Anforderungsbereiche") öfter ändern als andere. Ein konkretes Beispiel wäre eine Website mit Userverwaltung, bei der sich zwar die Menüseite der einzelnen User (wo diese ihr Profil sehen können, ihr Passwort ändern können etc.) komplett ändern soll und anders aussehen soll - die Datenhaltung (was wird wie und wo gespeichert) aber gleich bleiben kann.
Durch eine MVC Architektur trennt man diese drei Aspekte voneinander (auf irgendeine Weise) und sorgt dafür, dass bei Änderung oder Eneuerung oder sogar komplettem Austausch einer dieser drei Aspekte nicht auch beide anderen Aspekte "angefasst" werden müssen.Die Idee, Dinge voneinander zu trennen, die sich unterschiedlich oder unterschiedlich oft verändern, ist ziemlich alt. OOP ist nichts anderes als das, nur im Vergleich zu MVC auf einer niedrigeren Ebene.
Wenn du also deine Software programmierst, solltest du dich regelmäßig fragen: "wenn ich diesen Teil hier später mal ändere, was muss ich dann möglicherweise noch alles anpassen?" Solltest du feststellen, dass du möglicherweise Dinge ändern werden musst, die sich im Vergleich zum gerade angeguckten Teil selten ändern oder "eigentlich" nicht geändert werden bräuchten (unter rein fachlichen Gesichtspunkten), dann tust du etwas, was später potenziell Probleme verursachen wird.
Es gibt also kein festes Prinzip. Es hängt immer vom jeweiligen Anwendungsfall ab. Aber: in den meisten Fällen ist MVC eine gute Orientierungshilfe.
-
hi,
http://framework.zend.com/manual/1.12/de/learning.quickstart.intro.html ... oder guck es dir bei anderen php-frameworks an, symfony, cake, yii und wie sie alle heißen.
m.e. ist es ganz simpel: der controller regelt die requests, holt demensprechend die daten über die model-klasse und gibt die nötigen daten dann (als array oder direkt als variablen) an die view.
im (p)html steht dann irgendwo
<?php echo $view->meineVariable?>und ähnliches ...;mfg
tami
-
Hello,
im (p)html steht dann irgendwo
<?php echo $view->meineVariable?>und ähnliches ...;ähnliches:
$control->fill_variables_array();
$view->load_template();
$view->replace_placeholders();Wenn schon MVC und OOP, dann auch strikte Trennung von aktiven und passiven Elementen im View. Dann kann man die passiven nämlich von Hinz & Kunz bearbeiten lassen, ohne dass die Stabilität der Anwendung oder gar des ganzen Hosts in Gefahr gerät.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
hi,
im (p)html steht dann irgendwo
<?php echo $view->meineVariable?>und ähnliches ...;ähnliches:
$control->fill_variables_array();
$view->load_template();
$view->replace_placeholders();Wenn schon MVC und OOP, dann auch strikte Trennung von aktiven und passiven Elementen im View. Dann kann man die passiven nämlich von Hinz & Kunz bearbeiten lassen, ohne dass die Stabilität der Anwendung oder gar des ganzen Hosts in Gefahr gerät.
http://framework.zend.com/manual/2.0/en/modules/zend.view.quick-start.html
mfg
tami
-
-
-
Hi,
danke erstmals für die vielen hilfreichen Antworten.
Ein anderes "Problem" ist mir noch untergekommen:Wie regelt ihr den Zugriff über Ajax?
Einfach eine Ajax - Methode im selben Controller oder einen eigenen Controller nur für alle Ajax - Requests?Im Prinzip ist es doch nichts anderes als eine HTML Seite (also Viel Ebene) nur halt im XML oder JSON Format!?
Mag Naps
-
Tach!
Wie regelt ihr den Zugriff über Ajax?
Einfach eine Ajax - Methode im selben Controller oder einen eigenen Controller nur für alle Ajax - Requests?Oder. Das kommt ganz drauf an, was du machen willst. Braucht der Ajax-Request die privaten Methoden des Controllers, und ist es nur ein Zubrot, dann kommt der da mit rein. Ist es eine eigenständige API, dann wäre ein eigener Controller sinnvoll. Weitere Überlegungen und Voraussetzungen führen unter Umständen auch noch zu anderen Lösungen.
dedlfix.
-
hi,
Wie regelt ihr den Zugriff über Ajax?
Einfach eine Ajax - Methode im selben Controller oder einen eigenen Controller nur für alle Ajax - Requests?
Meine Philosophie: Request ist Request. Will eine meiner Seiten einen Ajax-Request machen, ist dafür genau dieselbe Klasse zuständig, die auch die Seite selbst ausliefert.
I.d.R. wird die Seite ausgeliefert für einen Request ohne Parameter, also /foo.html ist der Request. Zuständig für die Response sei die Klasse Foo. Sind Parameter im Spiel wird eine Methode namens control() aufgerufen. Der Request mit XHR (Ajax) wird also einen Parameter mitsenden, womit in der Methode control() feststeht, wie die Response auszusehen hat, bspw., wird dazu auch ein anderer Header gesendet (text/plain oder text/xml anstelle text/html).
Etwas komplizierter wirds, wenn /foo.html eine Anwendung ist, wo ohnehin schon Parameter im Spiel sind. Damit nun nicht die ganze Paramter-Kontrollstruktur doppelt programmiert werden muss, wird vor dem Zusammenstellen der Response ein zusätzlicher Request-Header befragt:
x-serialized: prop
habe ich den genannt, und der wird nur gesendet, wenn der Request vom XHR ausgeht. Ist dieser Header gesetzt, werden keine kompletten Seiten als Response geliefert, sondern es wird nur der STASH (Datenversteck, ein Attribut des Response-Objekts, Instanz der Klasse Foo) serialisiert. Das kann dann XML, JSON oder sonstwas sein, wo Du wolle.
Im Prinzip ist es doch nichts anderes als eine HTML Seite (also Viel Ebene) nur halt im XML oder JSON Format!?
Genau: Ein XHR-Request will nur die Daten, nicht die kompletten Seiten.
-