Re: Saubere Umsetzung des MVC-Modells
am 29.10.2007 20:50:54 von kscheller
Christoph Herrmann wrote:
> Klar, aber dein Table View muss auch auf die Daten zugreifen können. Das
> mag in diesem Falle auch über nicht standardisierte Methoden gehen. Aber
> wenn die Viewer auch noch für andere Klassen verwenden willst, solltest
> eine Schnittstelle nehmen, die bei deinen Datenklassen implementierst.
Ich denke, dass es sehr sehr selten vorkommt (außer bei trivialen
Fällen), dass man Viewer für mehrere Projekte verwenden kann.
Natürlich ist das kein Problem, wenn man eine Tabelle oder eine Liste
darstellt. Tabellenviewer sind schnell zurechtgeklopft, ggf. auch mit
Sortierfunktion via Javascript, ebenso bei Listen (die ja sozusagen
eindimensionale Tabellen sind[1]).
Wenn ich jedoch ein wirklich komplexes Objekt anzeigen und bearbeiten
muss, dann komme ich nicht um spezialisierte Klassen herum.
Meine Meinung, ich bitte um Korrektur, falls ich mich verschätze :-)
Servus,
Konni
[1] Abstrahiert:
1-Spalte:
2-Spalten:
>=3 Spalten:
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 29.10.2007 21:01:35 von kscheller
Stefan Ohrmann wrote:
> Das hättest du aber dazu sagen sollen, dass es sich dabei nicht direkt
> um das MVC-Pattern sondern um das Model-View-Presenter-Pattern handelt,
> dass sich in der Kleinigkeit unterscheide, dass der View keinen Zugriff
> auf das Model hat und vom Presenter befüllt wird. Ich kann dazu auch die
> Webseite von Martin Fowler empfehlen [1] und dort speziell den
> Supervising Presenter [2], den Passive View [3] und das Presentation
> Model [4].
Das klingt hochinteressant und ist möglicherweise noch besser für meinen
Fall geeignet. Da keine Änderung des Datenmodells stattfindet, ohne dass
ein komplette Ausgabe stattfinden muss, ist ein passiver View vielleicht
sogar noch besser.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 29.10.2007 22:25:09 von Peter Sommerfeld
Stefan Ohrmann schrieb:
> Das hättest du aber dazu sagen sollen, dass es sich dabei nicht direkt
> um das MVC-Pattern
Durchaus nicht denn der OP kann selber lesen und auch denken, oder meinst
du nicht?
> sondern um das Model-View-Presenter-Pattern handelt,
> dass sich in der Kleinigkeit unterscheide, dass der View keinen Zugriff
> auf das Model hat und vom Presenter befüllt wird.
Genau: Eine Kleinigkeit. Das ursprüngliche Smalltalk-MVC exestiert eh
nicht mehr denn das war nicht anderes als das Interface zu Mouse und
Keyboard. Heute wird unter MVC eine Menge unterschiedlicher Strukturen
aus 3 oder sogar 4 Komponenten verstanden die die Interaktion des UI
regeln, - meist im Unterschied zum Widget-Modell das aus 2 Komponenten
besteht, dem Modell und dem Widget das View und Controller zusammenfaÃt.
Wie die genau miteinander verdratet sind ist je nach Biblothek oder
Anwendungsfall sinnvoll, das Dolphin-MVP ist davon nur eine. Wir brauchen
uns also nicht an Worten festhalten...
Im übrigen stellt sich mir schon die Frage was diese Ideen im
Zusammenhang von Webservern, PHP etc bedeuten. Aber da habe ich noch
nicht drüber nachgedacht. Vielleicht läÃt uns der OP ja an seinem
Ergebnis teilhaben.
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 01:01:42 von kscheller
Peter Sommerfeld wrote:
> Durchaus nicht denn der OP kann selber lesen und auch denken, oder meinst
> du nicht?
Manchmal kann ich das tatsächlich. :-) Einen Satz zum MVC fand ich
bemerkenswert (die Schlussfolgerung):
"Nearly all of the application logic will reside in the application
model classes. "
Das ist genau das, was mir in der vorigen Version passiert ist. Es ist
das, was der Autor beschreibt: da Controller und View sich nur indirekt
"kennen" (wegen der Flexibilität) konstruierte ich Monsterklassen, die
viel - zu viel - erledigten. Das *funktionierte* einigermaßen, aber
flexibel oder auch nur schön ist das nicht.
> Wie die genau miteinander verdratet sind ist je nach Biblothek oder
> Anwendungsfall sinnvoll, das Dolphin-MVP ist davon nur eine. Wir brauchen
> uns also nicht an Worten festhalten...
Danke.
> Im übrigen stellt sich mir schon die Frage was diese Ideen im
> Zusammenhang von Webservern, PHP etc bedeuten.
Das ist eh etwas anderes. Insbesondere der View wird normalerweise
komplett gerendert. (HTML eben.)
> Aber da habe ich noch
> nicht drüber nachgedacht. Vielleicht läßt uns der OP ja an seinem
> Ergebnis teilhaben.
Ich würde mich sogar freuen, wenn sich jemand an der Entwicklung
beteiligt. Wie schon angedeutet, möchte ich ein CMS basteln, das eben
nicht auf Templates bis zum Abwinken ansetzt, sondern etwas
grundsätzlicher arbeitet. Es soll auch möglich sein, z.B. PDF aus dem
CMS heraus zu erzeugen, oder "Druckversionen" (wer immer das braucht).
Deswegen die Möglichkeit verschiedener "Views".
Falls es interessiert, erläutere ich einmal die Grundgedanken.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 02:31:53 von Peter Sommerfeld
Konni Scheller schrieb:
> Insbesondere der View wird normalerweise
> komplett gerendert. (HTML eben.)
Das kann man m.E. so nicht sagen. Es geht dabei ja u.A. um Dekomposition
des Renderers in unterschiedliche Komponenten die je nach Bedarf
zusammengesteckt werden. Ich spiele gerade mit Ajax rum und da fällt mir
z.B. ein dass man tabellarische Daten im Falle dass der User kein JS
unterstützt die Daten normal als TableView rendern kann oder eben als
weit komfortableren AjaxTableView. Ist nur eine Menge Arbeit sowas... :(
Dennoch: Wenn die Struktur stimmt brauchst du nur die entsprechenden
Komponenten auszutauschen. Man kann ja sehr einfach anfangen und später
den Schnickschnack stückchenweise hinzufügen, - inkrementelle Entwicklung
eben.
> Es soll auch möglich sein, z.B. PDF aus dem CMS
> heraus zu erzeugen, oder "Druckversionen" (wer immer das braucht).
> Deswegen die Möglichkeit verschiedener "Views".
Klar geht das aber da setzt du auf einer zu hohen Abstraktionsebene an da
du dann ja praktisch den gesammten Renderer austauschst. Das Modell
bleibt konstant, der Renderer wird ausgetauscht und einen Controller
brauchst du nicht mehr, - MVC hat aber in meiner Sicht immer mit User-
Interaktion zu tun.
Ich denke man kann 2 Dinge falsch machen: zu abstrakt werden, Frameworks
neigen m.E. dazu, oder eben zu konkret. Ich stelle mir
Softwareentwicklung immer wie einen Fischer-Baukasten vor: eine Menge
unterschiedlichster Teile die man mehr oder minder sinnvoll
zusammenstecken kann. Meist fehlen gerade die Teile die dringend
gebraucht werden... ;-)
> Ich würde mich sogar freuen, wenn sich jemand an der Entwicklung
> beteiligt.
Beteiligen wäre sicherlich viel zu viel, aber Designfragen sind immer
interessanter als der übliche Kleinkram um die Klagemauer PHP. Das lenkt
so schön von den Realitäten ab ;-)
> Falls es interessiert, erläutere ich einmal die Grundgedanken.
Nur zu !
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 04:19:11 von Niels Braczek
Konni Scheller schrieb:
> Manchmal kann ich das tatsächlich. :-) Einen Satz zum MVC fand ich
> bemerkenswert (die Schlussfolgerung):=20
> "Nearly all of the application logic will reside in the application
> model classes. "
Ich werde das Gefühl nicht los, dass zwei sich zT. widersprechende
Auffassungen von MVC kursieren. Die eine (mir vertrautere) assoziiert
mit "Model" das Daten(bank)-Modell und mit "Controller" im Wesentlichen
die Business-Logik, die andere mit "Model" das Business-Modell und mit
"Controller" die Benutzerschnittstelle. Nur in puncto "View" scheinen
diese Auffassungen übereinzustimmen. Weiß da jemand Genaueres?
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 08:06:10 von kscheller
Peter Sommerfeld wrote:
> Ich denke man kann 2 Dinge falsch machen: zu abstrakt werden, Frameworks
> neigen m.E. dazu, oder eben zu konkret.
Ich fürchte, das letzte Mal war ich deutlich zu konkret. Ich hoffe,
diesmal nicht zu abstrakt zu werden.
> Ich stelle mir
> Softwareentwicklung immer wie einen Fischer-Baukasten vor: eine Menge
> unterschiedlichster Teile die man mehr oder minder sinnvoll
> zusammenstecken kann. Meist fehlen gerade die Teile die dringend
> gebraucht werden... ;-)
Da kennt noch jemand fischer technik :)
> Nur zu !
Aaalso...
Ziel ist, dass man eine gesamte Website bauen und verwalten kann. Im
Idealfall soll der Seitenbetreiber das tun können. Dabei konzentriert
sich das System fast ausschließlich auf den Inhalt, das CSS und das
Design selbst sowie die Grafiken sind Sache des Webdesigners.
Der User soll Seiten hinzufügen können, deren Inhaltsteil bearbeiten,
Seiten umstellen und wieder löschen können. Gerne auch mit mehreren
Usern, so dass eine Rechteverwaltung dazukommt.
So eine Seite soll generell aus "Modulen" gebaut werden. Module haben
diverse Eigenschaften (z.B. Autor, Erstellungsdatum, Sprache usw.).
Dabei ist "Module" ein Composite-Objekt, Module können also andere
Module enthalten. In der Testumgebung habe ich die funktion __toString()
für die Ausgabe benutzt die dann folgendes generiert:
....content...
Wobei der Content entweder ein String sein kann oder eben andere Module.
Diese Module bauen also eine Seite - "page"-Objekt. So ein page-Objekt
hat wiederum diverse Eigenschaften. Name, Id (unique), Content-ID (so
werden Sprachzuordnungen realisiert), ein Array aus Stylesheets,
keywords, description, eben alles, was zu einer Webseite gehört.
Page ist ebenfalls ein Composite-Objekt. Pages sind also wie ein Baum
aufgebaut. Hat eine Page ein Kindobjekt, dann wird sie später als
index.html eines Ordners gerendert. Die Kinder sind dann die Seiten in
diesem Ordner. De facto erben Page und Module von einer Klasse namens
"Node", welche die grundlegenden Composite-Methoden zur Verfügung
stellt: addChild(), deleteChild(), moveNode() , getParent(),
searchByName() und so weiter. Eine Besonderheit ist, dass property[] im
Moment von addChild() an die Kinder vererbt wird.
Das grundlegende Prinzip ist, dass in einem ersten Ansatz alle
properties an darunterliegende Seiten/Module/Benutzer weitervererbt
werden. So haben alle Seiten, die in einem Ordner liegen erst einmal
automatisch das gleiche Stylesheet, den gleichen Autor usw. wie die
Indexseite. Das Prinzip ist also, einen Prototypen zu bauen, der dann
ggf. abgeändert wird.
Node wird ebenfalls für die Benutzerverwaltung verwendet - Gruppen sind
auch Compositeobjekte.
Zurück zu den Modulen. Einige dieser Module sollen automatisch generiert
werden. In erster Linie betrifft das die Navigation. Die
Navigationsmodule können verschiedener Art sein, dabei ist mir
eingefallen, Sitemap, Tree, Handbook, Rows, Breadcrumb. Diese Namen
stehen dann für die Art, welche Links in die Seite gerendert werden.
Wenn das jetzt reichlich abstrakt klingt, dann ist das noch so :-) Wenn
es verworren klingt, dann liegt das daran, dass meine kleine Tochter
grad auf mir rumkrabbelt anstatt sich für den Kindergraten anzuziehen
:-)
Ich stelle gelegentlich mal den Quellcode (Quälcode?) zur Verfügung.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 09:21:51 von Peter Sommerfeld
Niels Braczek schrieb:
> Ich werde das Gefühl nicht los, dass zwei sich zT. widersprechende
> Auffassungen von MVC kursieren. Die eine (mir vertrautere) assoziiert
> mit "Model" das Daten(bank)-Modell und mit "Controller" im Wesentlichen
> die Business-Logik, die andere mit "Model" das Business-Modell und mit
> "Controller" die Benutzerschnittstelle. Nur in puncto "View" scheinen
> diese Auffassungen übereinzustimmen. Weià da jemand Genaueres?
Also ich meine das ausschliesslich als Pattern im Sinne von OOP wo der
Begriff in den 80ern auch entstanden ist. Das hat zunächst nichts mit
Datenbanken oder Businesslogik zu tun. Das sind schlicht abstrakte
Klassen ("abstrakt" im abstrakten Sinne).
Natürlich kann hinter dem Modell eine Datenbank stehen aber genau davon
abstrahiert das OOP-Modell da es die Daten nicht als Relation sondern als
Objekt beschreibt, also als Satz von Methoden und damit verbundenen
Protokollen. Wie die Daten gespeichert werden ist View und Controller
egal. OOP-Datenbanken sind wieder eine andere Baustelle.
Der mir wenig vertraute Begriff der Businesslogik entstammt wohl eher der
Applikationslogik im Zusammenhang mit Datenbanken und wird vermutlich
durch eine Menge an kooperierenden Objekten implementiert die in einem
GUI-System ggf. *auch* als Controller agieren können . Das ist m.E. eine
ganz andere Sichtweise. Es ist immer problematisch für unterschiedliche
Dinge aus unterschiedlichen Welten die gleichen Worte zu verwenden.
Peter
PS: Was zum Thema MVC in Wikipädia zu lesen ist, ist m.E. nicht nur
javazentrisch sondern auch recht oberflächlich und geht am Kern der Sache
vorbei.
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 10:07:33 von Peter Sommerfeld
Konni Scheller schrieb:
> Aaalso... [...]
Ein ambitioniertes Vorhaben, ein handgestriktes CMS. Was du beschreibst
ist aber nicht mehr als eine grobe Skizze des Zieles das jetzt in seine
Bestandteile zerlegt werden muss. Ich denke es lassen sich (zumindest) 3
Problemkreise unterscheiden die ein gemeinsames Muster aufweisen und eine
Implementierung als MVC nahelegen: Der Entwurf durch den Designer (css,
php), die Texterstellung durch die Autoren (text, formatierung), das
rendern der endgültigen Website (xhtml oder was auch immer).
In allen 3 Bereichen haben wir es mit einem Modell zu tun in dem
(unterschiedlich formatierte) Text bearbeitet werden so dass du die
gleiche Struktur verwenden kannst.
Und jetzt stehst du vor dem Problem des Anfanges (bootstrapping)
oder:"Wie ziehe ich mich an den eigenen Haaren aus dem Sumpf?" :-) Der
Punkt ist ja dass du dass was du erst erreichen willst, deine
Modulstruktur, sinnvollerweise bei der Entwicklung schon voraussetzen
solltest denn ansonsten arbeitest du mit total unterschiedlichen Systemen
und erhöhst damit die Komplexität erheblich.
Na, dann fang mal an ! (und "keep us informed")
Peter
PS: Mich drängeln auch die Hunde die endlich raus wollen für die ich aber
leider keinen Kindergarten habe ;-)
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 10:58:53 von kscheller
Peter Sommerfeld wrote:
> Der Entwurf durch den Designer (css, php),
Der wird, im Idealfall, einmal gemacht.
> die Texterstellung durch die Autoren (text, formatierung),
Formatierung nur im Notfall :-)
> das
> rendern der endgültigen Website (xhtml oder was auch immer).
Erfolgt im Moment auf Zuruf ("Knopfdruck": Seiten erzeugen). Das
bisherige System ist ein Kraut-und-Rüben-System und wird schon auf
einigen Seiten angewendet:
http://www.schachclub-forchheim.de/
http://www.wintergarten-schlenz.de/
http://www.roterochs.de/
Bei zwei der drei Seiten sind noch externe Contents (Serendipity) mit
eingebunden.
> In allen 3 Bereichen haben wir es mit einem Modell zu tun in dem
> (unterschiedlich formatierte) Text bearbeitet werden so dass du die
> gleiche Struktur verwenden kannst.
Nein. Eigentlich stellte ich mir es anders vor. Der Webdesigner erstellt
ein Grundgerüst für die Seite und das CSS. Das setzt er dann als
Prototyp um und zerlegt diesen in Module. Im Idealfall müssen nur die
inhaltstragenden Module von späteren Autoren bearbeitet werden, der Rest
wird vererbt, gerendert oder aus einem Pool ausgewählt. [1]
Die Geschichte mit der Mehrsprachigkeit hab ich gar noch nicht erwähnt.
Jede Page bekommt eine Content-ID, gleiche ContentIDs gibt es nur bei
"gleichen" Content in verschiedenen Sprachen. Pages in verschiedenen
Sprachen sind also durch die gleiche Content-ID verknüpft und das System
kann im Modul Sprachnavigation die entsprechenden Language-Links
generieren.
> Na, dann fang mal an ! (und "keep us informed")
Ich schau mal, dass ich heute noch Code online stellen kann.
> PS: Mich drängeln auch die Hunde die endlich raus wollen für die ich aber
> leider keinen Kindergarten habe ;-)
Kind ist schöner :-) Meine kleine Lizi hat auf Mamas Mac schon einen
eigenen Account und loggt sich dort ein... Surfen und Podcasts machen
ihr am meisten Spaß. Ich frag mich, wie das erst wird, wenn sie in die
Schule kommt...
Servus,
Konni
[1] Ich mach ja auch webseiten für andere. Und meine Erfahrung ist, dass
Kunden, die die Webseite selber aktualisieren wollen, meistens zu viel
dran rummurksen. Deswegen sollen nur bestimmte Module freigegeben werden
und im übrigen kann der kunde nur zwischen vorgegebenen Stylesheets
auswählen. Das sichert ein weitgehend einheitliches Design.
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 12:12:21 von Harald Stowasser
Niels Braczek schrieb:
> Ich werde das Gefühl nicht los, dass zwei sich zT. widersprechende
> Auffassungen von MVC kursieren. Die eine (mir vertrautere) assoziiert
> mit "Model" das Daten(bank)-Modell und mit "Controller" im Wesentlichen
> die Business-Logik, die andere mit "Model" das Business-Modell und mit
> "Controller" die Benutzerschnittstelle. Nur in puncto "View" scheinen
> diese Auffassungen übereinzustimmen. Weiß da jemand Genaueres?
Das /klasische/ MVC bietet halt die Möglichkeit die Views zu
aktualisieren, wenn sich etwas am Datenbestand ändert. Genau dazu ist
der ganze krimskrams eigentlich da.
In HTTP geht das leider nicht, da es (ohne Ajax) keinen Kanal vom Server
zum Client gibt, wo man den Browser zur Aktualisierung des 'Views'
bringt. Eigentlich gibt es nicht mal widgets die mehrere Views aufnehmen
können.
Der Observer ist im Netz so viel wert wie ein Pickel am Ar^WHintern.
Erst recht in php. Da es hier (noch) kein Applications-scope gibt.
Da irgendwelche Leute MVC so toll fanden, und es ein tolles Buzzword
ist, wurde MVC-Model 2 gebastelt. Was mit der eigentlichen Idee die
hinter MVC steckt nur noch die Trennung von Präsentation und Daten
gemein hat.
Bei uns läuft ein Mehrschichtiges system. Ich nenne es einfach mal OCVT
(ORM,Controller,View,Templates)
Das ORM kennt hierbei den View nicht. Der Controller übernimmt die
Interaktion, und hat vollen Zugriff auf View und ORM.
Der View(Smarty) wieder rum hat nur die Ausgabe zu rendern.
APACHE
/ \
\/ \/
ORM(MODEL)<---Controller--->REQUEST
/\ /
\ \/
View<--->Template--->RESPONSE
Das hat den Nachteil das der Controller relativ komplex wird. Jedoch
fange ich das durch eine sehr mächtige Schnittstelle meiner ORM-Objekte ab.
Nur in manchen Ausnahmen (z.B. Bäumen) ist es notwendig das dass Modell
auch den View kennt.
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 12:28:21 von kscheller
Konni Scheller wrote:
> Ich schau mal, dass ich heute noch Code online stellen kann.
So, da isser:
http://www.webseitenkoch.de/OxCMS/oxcms0.01.zip
Bitte um Kommentare und Kritik... :)
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 12:44:50 von Peter Sommerfeld
Konni Scheller schrieb:
> Peter Sommerfeld wrote:
>
>> Der Entwurf durch den Designer (css, php),
>
> Der wird, im Idealfall, einmal gemacht.
OK, also kein CMS sondern nur eine Laufzeitumgebung und ein Kunden-Editor
für statische Seiten. Das CSS wird vermutlich von dir entwickelt und per
FTP hochgeladen.
Wenn ich dich richtig verstehe geht es dir also um die generierung
relativ einfacher, statischer Seite bei dem das Layout und die
Erscheinungsweise leicht angepaÃt werden kann, ähnlich den von dir
genannten Seiten.
>> die Texterstellung durch die Autoren (text, formatierung),
>
> Formatierung nur im Notfall :-)
Du wirst nicht ganz ohne auskommen: Ãberschriften, Bilder einfügen,
Tabellen etc. Hängt von den Ansprüchen ab.
Ich nehme mal an du willst die Texte als NestedSets in einer DB
abspeichern dann kannst du natürlich die Node-Struktur benutzen um die
Website mit einfachen Mitteln zu strukturieren:
level 1 : Hauptmenu, oberste Ebene
level 2 : Artikel (H1)
level 3 : Abschnitt (H2)
level 4 : Absatz (p)
Oder so ähnlich...
Auf Level 4 kämen in diesem Beispiel ggf. unterschiedliche Formatierungen
und Inhalte rein (Anmerkung, Tabellen etc).
> Die Geschichte mit der Mehrsprachigkeit hab ich gar noch nicht
> erwähnt. [...]
Das lass mal lieber zunächst aussen vor denn was du beschreibst sind
schon Implementierungsdetails und evtl. ergibt sich aus der Struktur
anderes und besseres, - oder auch nicht :-)
Das alles hat mit MVC noch nichts zu tun sondern um was es zunächst geht
ist die Spezifizierung deiner Ansprüche und eine Modularisierung der
Applikation. Es geht ja nicht darum MVC "anzuwenden" sondern etwas
zustande zu bringen.
Ich denke was du zunächst brauchst ist so etwas wie eine parametrisierte
Layout-Engine die ein standartisiertes Basic-Layout interpretiert (Menue
oben, links, rechts ? footer ? etc pp). Das kannst du dann PageController
nennen und unterschiedliche Controller für die verschiedenen Bestandteile
einstecken die wiederum die Views ins leben rufen. Die Modelle wären die
Schnittstellen zur Datenbank bzw. File-System.
Auf der Basis kannst du dann einen Editor für die Benutzer entwickeln.
So, jetzt muss ich aber was ernsthaftes tun !
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 12:55:50 von kscheller
Peter Sommerfeld wrote:
> OK, also kein CMS sondern nur eine Laufzeitumgebung und ein Kunden-Editor
> für statische Seiten. Das CSS wird vermutlich von dir entwickelt und per
> FTP hochgeladen.
Exakt.
> Wenn ich dich richtig verstehe geht es dir also um die generierung
> relativ einfacher, statischer Seite bei dem das Layout und die
> Erscheinungsweise leicht angepaßt werden kann, ähnlich den von dir
> genannten Seiten.
Exakt.
> > Formatierung nur im Notfall :-)
>
> Du wirst nicht ganz ohne auskommen: Überschriften, Bilder einfügen,
> Tabellen etc. Hängt von den Ansprüchen ab.
Natürlich. Ich möchte jedoch die Auswahlmöglichkeiten für die Editoren
stark beschränken. So sollen sie für jedes Element nur einen Satz an
CSS-Klassen auswählen können. Alles aus dem Grund, damit man nicht wild
durch die Gegend formatiert.
> Ich denke was du zunächst brauchst ist so etwas wie eine parametrisierte
> Layout-Engine die ein standartisiertes Basic-Layout interpretiert (Menue
> oben, links, rechts ? footer ? etc pp).
Das ist nun eigentlich eine CSS-Geschichte.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 13:20:26 von kscheller
Harald Stowasser wrote:
> In HTTP geht das leider nicht, da es (ohne Ajax) keinen Kanal vom Server
> zum Client gibt, wo man den Browser zur Aktualisierung des 'Views'
> bringt. Eigentlich gibt es nicht mal widgets die mehrere Views aufnehmen
> können.
>
> Der Observer ist im Netz so viel wert wie ein Pickel am Ar^WHintern.
Du hast ja selbst den Fall angesprochen: Ajax. Es hat was, wenn man zum
Module umsortieren die einfach per Drag & Drop rüberzieht. Und da kommt
das MVC-Modell schon wieder hin.
Man sollte sich also die Möglichkeit nicht gleich verbauen.
> Das ORM kennt hierbei den View nicht. Der Controller übernimmt die
> Interaktion, und hat vollen Zugriff auf View und ORM.
Was issn ORM? Ohne das Wort verstehe ich das nicht.
> Der View(Smarty) wieder rum hat nur die Ausgabe zu rendern.
D.h. die Seiten werden on-the-fly generiert?
> APACHE
> / \
> \/ \/
> ORM(MODEL)<---Controller--->REQUEST
> /\ /
> \ \/
> View<--->Template--->RESPONSE
Danke, ist jetzt klarer.
> Das hat den Nachteil das der Controller relativ komplex wird. Jedoch
> fange ich das durch eine sehr mächtige Schnittstelle meiner ORM-Objekte ab.
>
> Nur in manchen Ausnahmen (z.B. Bäumen) ist es notwendig das dass Modell
> auch den View kennt.
Komisch, mein Modell fußt geradezu auf Bäumen. Jedes Element kümmert
sich nur um seine Ausgabe und reicht den Rest an das darunterliegende
weiter.
Hab ich mir halt so gedacht.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 14:15:03 von Peter Sommerfeld
Harald Stowasser schrieb:
> In HTTP geht das leider nicht, da es (ohne Ajax) keinen Kanal vom Server
> zum Client gibt, wo man den Browser zur Aktualisierung des 'Views'
> bringt.
Du meinst vermutlich dass es keinen Kanal vom Client zu Server gäbe. Das
sehe ich durchaus nicht so. Jedes interaktive Element wie Buttons, Links,
Menus etc das einen POST oder GET request absetzen kann ist ein solcher
Kanal. Ob wie auf dem Desktop ein Systemcall aufgerufen wird oder ein
Webserver dazwischengeschaltet wird ist egal. Natürlich hat das
praktische Konsequenzen, z.B. die Reaktionszeit. Das ist ja u.A. der
Grund warum Ajax interessant ist. Im Prinzip lieÃe sich aber alles was
mit Hilfe von Ajax realisiert wird auch auf dem Server erledigen, - nur
leider viel, viel zu langsam.
> Der Observer ist im Netz so viel wert wie ein Pickel am Ar^WHintern.
> Erst recht in php. Da es hier (noch) kein Applications-scope gibt.
Was hat das mit dem Application-scope zu tun ? Das ist m.E. der globale
Scope und der Rest läÃt sich in PHP5 recht gut handhaben. Es gibt
schlimmeres in PHP, also lass es uns mal nicht schlechter machen als es
eh schon ist ;-)
Im übrigen kann man das Observer-Pattern wie andere auch in der internen
Strukturierung serverseitig recht gut gebrauchen. Oft verzichtet man/ich
aus Laufzeitgründen auf allzustarke interne Differenzierung.
> Nur in manchen Ausnahmen (z.B. Bäumen) ist es notwendig das dass Modell
> auch den View kennt.
Das ist nicht so gut und sicherlich zu vermeiden...
Das ist alles eine Frage der Interpretation. Ich betrachte z.B. die URL
(nach dem Host) als Kommando wie auf einem Terminal und nicht
notwendigerweise als Aufruf einer Seite. Klar liefere ich dann immer eine
ganze Seite aus auf der sich aber evtl. nur Teile verändert haben. Kommt
halt immer darauf an und an BuzzWord sollte man sich wirklich nicht
aufhalten. MVC ist aber schon mehr...
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 14:15:18 von Martin Lemke
Christoph Herrmann schrieb:
> einfaches Beispiel
Danke, das war doch einleuchtend. Formalklauslierte Erläuterungen klingen
schlau, gehen aber zu Lasten von Verständlichkeit. Dein Beispiel war
dagegen anschaulich.
In der Quintessenz bedeutet dies, dass es overkill wäre, wenn man definitiv
nur ein einziges Ausgabeformat erzielen möchte: html. Sehe ich das so
richtig?
Martin
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 14:36:20 von Peter Sommerfeld
Konni Scheller schrieb:
>> Ich denke was du zunächst brauchst ist so etwas wie eine
>> parametrisierte Layout-Engine die ein standartisiertes Basic-Layout
>> interpretiert (Menue oben, links, rechts ? footer ? etc pp).
>
> Das ist nun eigentlich eine CSS-Geschichte.
Das kannst du nicht nur über CSS regeln es sei denn du realisierst nur
ein einziges Layout und wenn sich das ändert schreibst du eine neue
Engine in PHP. Aber über was reden wir dann überhaupt? :-))
Drupal verwendet (wenn ich mich recht erinnere) ein recht praktisches
Schema. Eine Seite besteht aus 5 Teilen, #top, #left,#bottom, #right und
#workspace (Namen von mir, alles IDs).
Kunde A will nun #top das Menue , #right ein Reihe von Links und l#left
einen nur schmalen, leeren Rand.
Kunde B langes Menue #left, #right Fotos und #top nix.
Bei beide standartisierten #bottom mit links next/prev.
Was will Kunde C ???
Klar, #workspace gehört dem Kunden, aber für alles andere bist
sinvollerweise du zuständig.
Andere, evtl. auch bessere Schemata sind natürlich denkbar.
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 15:10:37 von kscheller
Peter Sommerfeld wrote:
> >> Ich denke was du zunächst brauchst ist so etwas wie eine
> >> parametrisierte Layout-Engine die ein standartisiertes Basic-Layout
> >> interpretiert (Menue oben, links, rechts ? footer ? etc pp).
> >
> > Das ist nun eigentlich eine CSS-Geschichte.
>
> Das kannst du nicht nur über CSS regeln
Klar geht das :-) Aber nicht im IE[tm].
> es sei denn du realisierst nur
> ein einziges Layout und wenn sich das ändert schreibst du eine neue
> Engine in PHP. Aber über was reden wir dann überhaupt? :-))
Nein, dafür stelle ich doch die Module dar. Die Module rendern ihren
Inhalt praktisch selbst. Nur die Anordnung wird durch die Page bestimmt.
> Drupal verwendet (wenn ich mich recht erinnere) ein recht praktisches
> Schema. Eine Seite besteht aus 5 Teilen, #top, #left,#bottom, #right und
> #workspace (Namen von mir, alles IDs).
Das wären in dem Fall Module. Siehe meine __toString() Methode der Class
Module.
Im alten System hatte ich so etwas ähnliches, es waren 4 Module. Die
Anordnung war fest: #header, #navigation, #content und #footer.
> Kunde A will nun #top das Menue , #right ein Reihe von Links und l#left
> einen nur schmalen, leeren Rand.
>
> Kunde B langes Menue #left, #right Fotos und #top nix.
>
> Bei beide standartisierten #bottom mit links next/prev.
> Was will Kunde C ???
>
> Klar, #workspace gehört dem Kunden, aber für alles andere bist
> sinvollerweise du zuständig.
Positionierung via CSS, Modulanordnung im CMS.
> Andere, evtl. auch bessere Schemata sind natürlich denkbar.
Aber das kommt schon gut hin.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 16:01:48 von Harald Stowasser
Peter Sommerfeld schrieb:
> Harald Stowasser schrieb:
>> In HTTP geht das leider nicht, da es (ohne Ajax) keinen Kanal vom
>> Server zum Client gibt, wo man den Browser zur Aktualisierung des
>> 'Views' bringt.
>
> Du meinst vermutlich dass es keinen Kanal vom Client zu Server gäbe.
Nein. Es gibt keinen Kanal vom Server zum Client. AuÃer über Ajax-zeug
wo dies meistens über ein relativ einfaches polling realisiert ist.
Der Observer im Model kann der Webeseite nicht einfach so mitteilen das
sich der momentan dargestellte Wert geändert hat.
>> Der Observer ist im Netz so viel wert wie ein Pickel am
>> Ar^WHintern. Erst recht in php. Da es hier (noch) kein
>> Applications-scope gibt.
>
> Was hat das mit dem Application-scope zu tun ?
Im MVC werden dem Model die Views bekannt gemacht. Normalerweise über
einen Observer. Steckt der Puffer für die Observerables in einem
Globalen Container, sollten auch wirklich *alle* views benachrichtigt
werden.
Das Problem bei PHP ist nun, das der angesprochene View eventuell gar
nicht im aktuell laufenden Task ist...
Probleme über Probleme... Darum besser lassen :-)
> Das ist m.E. der globale Scope und der Rest läÃt sich in PHP5 recht
> gut handhaben. Es gibt schlimmeres in PHP, also lass es uns mal nicht
> schlechter machen als es eh schon ist ;-)
Application-scope ist mehr als ein global-Array($GLOBALS) in den mal
irgendwelche Daten rein und raus kopiert.
In 'Application-Servern' wirkt eine static-Variable z.B. Global. Somit
ist ein Singleton auch Global.
In PHP muss man dieses Verhalten wie du schon sagst mit $GLOBALS zurecht
rücken. Zur not mit Mutex und Semaphoren.
> Im übrigen kann man das Observer-Pattern wie andere auch in der
> internen Strukturierung serverseitig recht gut gebrauchen. Oft
> verzichtet man/ich aus Laufzeitgründen auf allzustarke interne
> Differenzierung.
Ein Observer dient zur Weitergabe von *Ãnderungen* an einem Objekt an
von diesem Objekt abhängige Strukturen.
Da sich während eines REQUESTS sich nicht allzuviele Daten ändern, ist
dieses Pattern wohl eher von untergeordneter Bedeutung.
Eine Beispielanwendung für einen Observer währe ein *einfacher* Chatraum
(besser währe hier noch ein Vermittler) Die Clients müssen sich anmelden
und bekommen über den Rückkanal die Aufforderung, die Anzeige zu
aktualisieren.
Allerdings läuft so eine Application nicht Innerhalb eines Requests.
Womit wir wieder bei $GLOBALS, Ajax, Polling und dem ganzen
Rattenschwanz währen ;-)
>> Nur in manchen Ausnahmen (z.B. Bäumen) ist es notwendig das dass
>> Modell auch den View kennt.
>
> Das ist nicht so gut und sicherlich zu vermeiden...
Das ist ne Sache der Performace. Eine Vermeidung kostet Zeit.
AuÃerdem ist das im klassischen MVC sogar Standard. Der Observer steckt
ja im Model, welcher über eine Schwache Typisierung die Update-Nachricht
sendet an die views senden muss.
> Das ist alles eine Frage der Interpretation. Ich betrachte z.B. die
> URL (nach dem Host) als Kommando wie auf einem Terminal und nicht
> notwendigerweise als Aufruf einer Seite.
Ich nenne das Request. ;-)
> Klar liefere ich dann immer eine ganze Seite aus auf der sich aber
> evtl. nur Teile verändert haben.
Request kann z.B. in Ajax auch ein Event-Polling sein. Und muss nicht
mal XML oder HTML sein.
> Kommt halt immer darauf an und an BuzzWord sollte man sich wirklich
> nicht aufhalten. MVC ist aber schon mehr...
:-)
Gruà Harald.
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 16:04:47 von Peter Sommerfeld
Konni Scheller schrieb:
>> Das kannst du nicht nur über CSS regeln
>
> Klar geht das :-) Aber nicht im IE[tm].
Damit entfällt das doch, oder ?
Ich denke es ist keine gute Idee CSS bis zum letzten auszureizen.
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 16:33:32 von Peter Sommerfeld
Konni Scheller schrieb:
> http://www.webseitenkoch.de/OxCMS/oxcms0.01.zip
>
> Bitte um Kommentare und Kritik... :)
Das sieht soweit ich das nach diagonalem überlesen sehen kann nach einem
sauberen Design aus bei dem natürlich noch vieles fehlt. Allerdings frage
ich mich was das mit deiner Asugangsfrage zu tun hat ? :-)
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 17:00:00 von Harald Stowasser
Konni Scheller schrieb:
> Harald Stowasser wrote:
>
>> In HTTP geht das leider nicht, da es (ohne Ajax) keinen Kanal vom Server
>> zum Client gibt, wo man den Browser zur Aktualisierung des 'Views'
>> bringt. Eigentlich gibt es nicht mal widgets die mehrere Views aufnehmen
>> können.
>>
>> Der Observer ist im Netz so viel wert wie ein Pickel am Ar^WHintern.
>
> Du hast ja selbst den Fall angesprochen: Ajax. Es hat was, wenn man zum
> Module umsortieren die einfach per Drag & Drop rüberzieht. Und da kommt
> das MVC-Modell schon wieder hin.
Ja. Mit Ajax geht sowas. Ist aber relativ kompliziert.
Du musst z.B. den Observer von Zeit zu Zeit aufräumen, weil die
Observerable ja schon lang weg sein können ohne sich abzumelden.
> Man sollte sich also die Möglichkeit nicht gleich verbauen.
Jo da stimm ich zu :-)
Die Aussage sollten man eher auf einen Request beschränkt sehen.
>> Das ORM kennt hierbei den View nicht. Der Controller übernimmt die
>> Interaktion, und hat vollen Zugriff auf View und ORM.
>
> Was issn ORM? Ohne das Wort verstehe ich das nicht.
http://de.wikipedia.org/wiki/Object-Relational_Mapping
>> Der View(Smarty) wieder rum hat nur die Ausgabe zu rendern.
>
> D.h. die Seiten werden on-the-fly generiert?
Wie definierst du "on-the-fly generiert".
Der Controller generiert aufgrund des Requests die richtigen Models aus
der Datenbank. Die Klassen dazu wurden vorher mit einem 'ORM-Generator'
erzeugt. Dann schiebt der Controller die Modelle dem View mitsamt
Template zu.
Das heißt:
Das Modell schreibt der 'ORM-Generator'.
Der View ist bei HTML eine fertige Template-Engine (Hier Smarty).
Den Controller schreibt der Programmierer.
Das Template schreibt der Snowb^WWeb-Designer.
>> Nur in manchen Ausnahmen (z.B. Bäumen) ist es notwendig das dass Modell
>> auch den View kennt.
>
> Komisch, mein Modell fußt geradezu auf Bäumen. Jedes Element kümmert
> sich nur um seine Ausgabe und reicht den Rest an das darunterliegende
> weiter.
Mit Modell meinte ich das M von MVC ;-)
Es besteht bei mir nicht die Notwendigkeit das sich die ORM-Objekte
(Model) ihre Views merken.
Außer bei einigen Bäumen, da ich z.B bei der Navigation das ganze
NestedSet aus der DB hole. Und für verschiedene Views auch nur bestimmte
Zweige des Baums benötige.
Ist halt ne Optimierung.
> Hab ich mir halt so gedacht.
Denken ist immer gut ;-)
Gruß
Harald.
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 17:13:23 von Peter Sommerfeld
Harald Stowasser schrieb:
> Peter Sommerfeld schrieb:
>> Du meinst vermutlich dass es keinen Kanal vom Client zu Server gäbe.
>
> Nein. Es gibt keinen Kanal vom Server zum Client. [...] Der Observer
> im Model kann der Webeseite nicht einfach so mitteilen das sich
> der momentan dargestellte Wert geändert hat.
Natürlich gibt es den, ich muss nur leider wegen des zustandslosen HTTP-
Protokolls den Rest der jeweiligen Seite immer noch mitlieferen. Das ist
alles, kostet aber eben enorm viel Zeit und ist daher wg. eines einzelnen
Wertes meist unpraktikabel. Aber wenn es um meinen Kontostand geht nehme
ich das gerne in kauf, - oder auch nicht ;-)
Ausserdem scheinst du hier von etwas anderem zu reden als ich. Das Modell
ist (umd es in der GO4-Terminologie zu sagen) das Subject, steht also nur
unter Beobachtung und ist daher definitiv kein Observer. Es gibt nur an
*alle* registrierten Observer die Mitteilung heraus das sich an seinem
internen Zustand etwas geändert hat und ggf. was. Und im Modell kann sich
nur etwas ändern wenn das vom User in irgendeiner Form initiiert worden
ist. Das ist eine ganz normale 2-Weg Kommunikation.
Du hast insofern recht als der Server nicht von sich aus tätig werden
kann, also z.B. nach Ablauf einer bestimmten Zeit einen Alarm auslösen.
> Im MVC werden dem Model die Views bekannt gemacht. Normalerweise über
> einen Observer. Steckt der Puffer für die Observerables in einem
> Globalen Container, sollten auch wirklich *alle* views benachrichtigt
> werden.
> Das Problem bei PHP ist nun, das der angesprochene View eventuell gar
> nicht im aktuell laufenden Task ist...
Sorry, verstehe ich nicht. Die Website oder Teile davon ist nicht das
View selbst sondern nur eine Externalisierung des Views auf dem Server,
geschrieben in PHP. Natürlich muss der jeweils dynamisch neu generiert
werden oder aus aus einer persistenten Layer entmommne werden (Cache,
Datenbank etc).
> In PHP muss man dieses Verhalten wie du schon sagst mit $GLOBALS zurecht
> rücken. Zur not mit Mutex und Semaphoren.
Das alles hat mit konkurrierenden Prozessen nix zu tun, das ist eine
andere Baustelle die ganz andere Lösungen erfordert.
>> Das ist nicht so gut und sicherlich zu vermeiden...
> Das ist ne Sache der Performace. Eine Vermeidung kostet Zeit.
Klar, das sind so die Kompromisse die man schliessen muss...
Peter
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 18:00:10 von kscheller
Harald Stowasser wrote:
> Mit Ajax geht sowas. Ist aber relativ kompliziert.
> Du musst z.B. den Observer von Zeit zu Zeit aufräumen, weil die
> Observerable ja schon lang weg sein können ohne sich abzumelden.
Stimmt. Die Frage ist, wie man das mitkriegt. :-(
> > Was issn ORM? Ohne das Wort verstehe ich das nicht.
> http://de.wikipedia.org/wiki/Object-Relational_Mapping
Aja. Das hatte ich schon. Allerdings wusste ich nicht, was es war. :-)
> Wie definierst du "on-the-fly generiert".
Im Gegensatz zu statischen Seiten.
> Der Controller generiert aufgrund des Requests die richtigen Models aus
> der Datenbank. Die Klassen dazu wurden vorher mit einem 'ORM-Generator'
> erzeugt. Dann schiebt der Controller die Modelle dem View mitsamt
> Template zu.
>
> Das heißt:
>
> Das Modell schreibt der 'ORM-Generator'.
> Der View ist bei HTML eine fertige Template-Engine (Hier Smarty).
> Den Controller schreibt der Programmierer.
> Das Template schreibt der Snowb^WWeb-Designer.
So in der Art.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 20:07:31 von Michael Fesser
..oO(Harald Stowasser)
>Peter Sommerfeld schrieb:
>
>> Im übrigen kann man das Observer-Pattern wie andere auch in der
>> internen Strukturierung serverseitig recht gut gebrauchen. Oft
>> verzichtet man/ich aus Laufzeitgründen auf allzustarke interne
>> Differenzierung.
>
>Ein Observer dient zur Weitergabe von *Änderungen* an einem Objekt an
>von diesem Objekt abhängige Strukturen.
Richtig.
>Da sich während eines REQUESTS sich nicht allzuviele Daten ändern, ist
>dieses Pattern wohl eher von untergeordneter Bedeutung.
Das kommt auf den internen Ablauf bei der Bearbeitung des Requests an.
In benutze in meinem eigenen Framework z.B. eine Sitemap-Komponente,
welche ein Abbild der gesamten Dokumentenstruktur der Website darstellt.
Teile dieser Sitemap stammen aus einer Datenbank (für die "statischen"
Dokumente, deren Inhalte direkt auf Platte liegen und nicht erst
generiert werden müssen), andere Teile werden erst zur Laufzeit von
weiteren Modulen hinzugefügt.
Wenn ich z.B. das Admin-Modul lade, dann fügt dieses entsprechende
Einträge in die Sitemap ein und macht damit den Admin-Bereich überhaupt
erst per URL zugänglich. Solche Änderungen können durchaus zu unter-
schiedlichen Zeitpunkten auftreten, so daß andere Komponenten, welche
mit den Daten aus der Sitemap arbeiten wollen, sich diese entweder erst
zu einem späteren Zeitpunkt holen dürfen oder aber einfach über die
Änderungen informiert werden und sich selbst aktualisieren. Ich finde
letzteres eleganter.
Aus reiner Bequemlichkeit benutze ich das Observer-Pattern auch noch an
anderen Stellen, einfach weil es eine gewisse Flexibilität bietet.
Micha
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 20:29:17 von Michael Fesser
..oO(Konni Scheller)
>Peter Sommerfeld wrote:
>
>> es sei denn du realisierst nur
>> ein einziges Layout und wenn sich das ändert schreibst du eine neue
>> Engine in PHP. Aber über was reden wir dann überhaupt? :-))
>
>Nein, dafür stelle ich doch die Module dar. Die Module rendern ihren
>Inhalt praktisch selbst. Nur die Anordnung wird durch die Page bestimmt.
In meinem Framework läuft das z.T. ähnlich, auch wenn bei mir Module
eine andere Bedeutung haben.
Was bei mir dargestellt wird, sind spezielle Komponenten, die von einer
TView-Klasse erben und somit die Möglichkeit haben, sich selbst und ggf.
ihre Unterkomponenten zu rendern. Die Möglichkeiten sind dabei nicht nur
auf HTML beschränkt, sondern (zumindest theoretisch, benutzen tue ich
diese Möglichkeit noch nicht) könnten z.B. auch XHTML2 oder nur Plain
Text sein. PDF ist ebenfalls angedacht.
Über allem "Sichtbaren" steht eine TDocument-Komponente, welche
letztlich das repräsentiert, was als Antwort an den Browser gesendet
wird. Im Laufe der Abarbeitung des Requests wird diese Komponente mit
weiteren Views aufgefüllt, z.B. für Navigationsleisten, Formulare und
all diesen Kram. Je nach Bedarf.
Das Layout steckt dabei in einem ganz einfachen Template, welches im
HTML-Sinne den 'Body' repräsentiert. Es enthält neben der grundlegenden
HTML-Struktur auch einfache Platzhalter der Form:
{cmp:menuBar;param=...}
{tpl:breadCrumbBar}
{tpl:content}
Beim Rendern des Dokuments werden diese Platzhalter dann durch die
Ausgaben der jeweiligen Komponenten ersetzt. Dabei führt eine solche
'cmp'-Anweisung dazu, daß diese View-Komponente erst direkt vor dem
Rendern erzeugt und geladen wird (in diesem Fall eine der Klasse
TMenuBar, ggf. mit Parametern), während 'tpl' auf Komponenten zurück-
greift, die bereits vorher im Script erzeugt wurden (hier also welche
mit den internen IDs 'breadCrumbBar' und 'content').
Im Moment gilt dieses eine Template für alle Dokumente einer Website.
Prinzipiell könnte ich das aber auch flexibel gestalten und somit
verschiedenen Bereichen einer Website komplett unterschiedliche Layouts
verpassen.
Micha
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 23:05:42 von Harald Stowasser
Peter Sommerfeld schrieb:
>>> Du meinst vermutlich dass es keinen Kanal vom Client zu Server
>>> gäbe.
>> Nein. Es gibt keinen Kanal vom Server zum Client. [...] Der
>> Observer im Model kann der Webeseite nicht einfach so mitteilen das
>> sich der momentan dargestellte Wert geändert hat.
>
> Natürlich gibt es den, ich muss nur leider wegen des zustandslosen
> HTTP- Protokolls den Rest der jeweiligen Seite immer noch
> mitlieferen.
Ohne Request gibt es keinen Response. Das HTTP sieht nichts anderes vor.
Und keine noch so schlecht konfigurierte Firewall würde überhaupt ein
Paket ohne Anfrage auf einen Client durchlassen. Auch gibt es IMHO
keinen massentauglichen Browser der einen HTTP_Demon mitbringt.
Den Rückkanal kann man mit XMLHttpRequest mittels Polling nachbilden.
Trotzdem geht dabei jede Aktion vom Client aus.
Es gibt auch Applikation Server, die das Prinzip der Continuation
beherrschen. Da wird der Response auf einen XMLHttpRequest bis zum
Timeout zurückgehalten. So kann der Server bei einem Event relativ fix
den Client seine Nachricht schicken.
Das führt jedoch sicherlich für die OP zu weit.
Es gibt keinen Kanal vom Server zum Client.
> Ausserdem scheinst du hier von etwas anderem zu reden als ich. Das
> Modell ist (umd es in der GO4-Terminologie zu sagen) das Subject,
> steht also nur unter Beobachtung und ist daher definitiv kein
> Observer.
Das Modell hält die Daten. Ist als wie du richtig bemerkst das Subjekt
und deshalb der Veröffentlicher. Die Beobachter die das Update-Event
erhalten sind die Views.
Meine Terminologie war ein wenig ungenau. Ich sehe das Observer-Pattern
als ganzes. Wobei ja die Views die eigentlichen Observer sind.
Nichts desto trotz benachrichtigt eben der Veröffentlicher alle
Beobachter bei Zustandsänderungen über einen Nachrichtenkanal.
Die Nachricht geht also vom Modell zum View.
> Es gibt nur an *alle* registrierten Observer die Mitteilung
> heraus das sich an seinem internen Zustand etwas geändert hat und
> ggf. was. Und im Modell kann sich nur etwas ändern wenn das vom User
> in irgendeiner Form initiiert worden ist. Das ist eine ganz normale
> 2-Weg Kommunikation.
Da zwischen Request und Response normalerweise nicht viel Zeit vergehen
sollte macht eine Beobachtung auf veränderte Daten nur bedingt Sinn.
>> Im MVC werden dem Model die Views bekannt gemacht. Normalerweise
>> über einen Observer. Steckt der Puffer für die Observerables in
>> einem Globalen Container, sollten auch wirklich *alle* views
>> benachrichtigt werden. Das Problem bei PHP ist nun, das der
>> angesprochene View eventuell gar nicht im aktuell laufenden Task
>> ist...
>
> Sorry, verstehe ich nicht. Die Website oder Teile davon ist nicht das
> View selbst sondern nur eine Externalisierung des Views auf dem
> Server, geschrieben in PHP. Natürlich muss der jeweils dynamisch neu
> generiert werden oder aus aus einer persistenten Layer entmommne
> werden (Cache, Datenbank etc).
Das ist je nach Sichtweise anders. In Ajax darfst du ruhig das jeweilige
Widget als View sehen. Solches MVC wird hierbei mit PHP schwer. Da
eventuelle Modelle dem aktuellen Request gar nicht bekannt sind. Ein
Hantieren mit den 'Globalisierten' gestaltet sich dabei doch recht
schwierig.
Und MVC während eines Zyklus ist wie ich schon mal bemerkt habe nur
bedingt brauchbar. Der View ist dann ein HTTP-Renderer der die Daten zu
einem bestimmten Zeitpunkt *einmal* in den Ausgabepuffer schiebt. Wüsste
jetzt nicht welchen Vorteil es mir nach dem Rendern noch bringt das sich
die Datenquelle geändert hat.
>> In PHP muss man dieses Verhalten wie du schon sagst mit $GLOBALS
>> zurecht rücken. Zur not mit Mutex und Semaphoren.
>
> Das alles hat mit konkurrierenden Prozessen nix zu tun, das ist eine
> andere Baustelle die ganz andere Lösungen erfordert.
Falsch. Genau auf diese Probleme wirst du stoÃen wenn du kein
"Applikation-Level" besitzt. Aber ein Modell haben willst welches auch
zwischen mehreren Requests existiert.
Bei Modellen die nur während eines Zyklus existieren. Gibt es das
Problem freilich nicht. Aber dann braucht man auch keinen Observer :-)
GruÃ
Harald.
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 23:06:09 von kscheller
Michael Fesser wrote:
> Das Layout steckt dabei in einem ganz einfachen Template, welches im
> HTML-Sinne den 'Body' repräsentiert.
Kannst Du ggf. in diesen Templates einstellen, ob Du HTML oder XHTML
willst? Wirkt sich das auf alle ![]()
-Tags aus, die dann bei HTML zu
![]()
-Tags werden? ;) Wenn ja, wie hast du das gemacht?
Ich dachte daran, in einem Page-Objekt zu speichern, ob es XHTML oder
HTML ist und explizit eine auswahl der Document-Types zuzulassen.
> Im Moment gilt dieses eine Template für alle Dokumente einer Website.
> Prinzipiell könnte ich das aber auch flexibel gestalten und somit
> verschiedenen Bereichen einer Website komplett unterschiedliche Layouts
> verpassen.
Das hab ich sowieso vor. Dank der Vererbung klappt das schmerzfrei.
Mittlerweile denke ich über domainübergreifende Systeme nach...
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 30.10.2007 23:28:39 von kscheller
Harald Stowasser wrote:
> Genau auf diese Probleme wirst du stoßen wenn du kein
> "Applikation-Level" besitzt. Aber ein Modell haben willst welches auch
> zwischen mehreren Requests existiert.
Arghl. Das ist ja wie in der Mathematik. Könntest du mir kurz erklären,
was mit "Application-level" gemeint ist?
Hört sich nach irgendwas superglobalem an.
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 00:21:13 von Harald Stowasser
Konni Scheller schrieb:
> Harald Stowasser wrote:
>
>> Genau auf diese Probleme wirst du stoßen wenn du kein
>> "Applikation-Level" besitzt. Aber ein Modell haben willst welches auch
>> zwischen mehreren Requests existiert.
>
> Arghl. Das ist ja wie in der Mathematik. Könntest du mir kurz erklären,
> was mit "Application-level" gemeint ist?
:-)
> Hört sich nach irgendwas superglobalem an.
Jo genau so ist es auch. Bei PHP werden die Scripte einfach nur vom
$server aufgerufen. So ähnlich wie du mit einem Doppelklick auch ein
Programm startest.
Die Scripte haben normalerweise nichts miteinander zu schaffen.
Es gibt mittlerweile zwar ein paar Container wie Shared-Memory
(http://de.php.net/shmop), Memcache oder $GLOBAL die helfen. Aber eine
richtige Applikationsschicht ersetzen die nicht.
Ein /Application-Server/ arbeitet ganz anders. Auch wenn gerade kein
Request zur Verarbeitung ansteht, läuft dort mindestens ein Prozess. Es
werden zwar mehrere Threads ausgeführt, die können trotzdem auf eine
einfachere Interprocess-Communication zugreifen.
Den Begriff /Applicationsschicht/ lehne übrigens einfach an die
Terminologie von JSP an:
Verfügbare Namensbereiche sind dort: application, session und request.
Beispiele:
Wenn man in PHP ein Singleton schreibt, wird dieses jedoch trotzdem von
mehreren Prozessen Instanziert. Es existiert also in Wirklichkeit
*nicht* nur einmal.
In Java-Tommcat ist jedoch ein Singleton währen der gesamten Laufzeit
des Servers auch wirklich nur einmal instanziert.
In PHP wird ein Static-member wird nach dem Ausliefern des Response
zerstört. Bei Java-Tommcat bleibt der Wert im Speicher, und steht beim
Nächsten Aufruf der Seite(oder was auch immer) wieder zur Verfügung.
Bei Zope ist die Applicationsschicht sogar eine komplette
Objektorientierte Datenbank (Bobobase aka ZODB). Du musst dich dabei
dann nicht mal groß ums Speichern kümmern.
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 00:37:07 von Michael Fesser
..oO(Konni Scheller)
>Michael Fesser wrote:
>
>> Das Layout steckt dabei in einem ganz einfachen Template, welches im
>> HTML-Sinne den 'Body' repräsentiert.
>
>Kannst Du ggf. in diesen Templates einstellen, ob Du HTML oder XHTML
>willst?
Nee. Für HTML und XHTML gäbs dann wohl zwei verschiedene Templates.
>Wirkt sich das auf alle ![]()
-Tags aus, die dann bei HTML zu
>![]()
-Tags werden? ;) Wenn ja, wie hast du das gemacht?
>
>Ich dachte daran, in einem Page-Objekt zu speichern, ob es XHTML oder
>HTML ist und explizit eine auswahl der Document-Types zuzulassen.
So in der Art ist das hier auch vorgesehen (aber bisher halt mangels
Notwendigkeit nicht vollständig implementiert). Die Idee ist, im Normal-
fall eine automatische Auswahl anhand des Accept-Headers zu treffen,
aber auch die Möglichkeit zu haben, per Dateiendung explizit einen
bestimmten Typ zu erzwingen. Also etwa so:
http://example.com/foo/bar (automatisch)
http://example.com/foo/bar.html
http://example.com/foo/bar.xhtml
http://example.com/foo/bar.txt
>> Im Moment gilt dieses eine Template für alle Dokumente einer Website.
>> Prinzipiell könnte ich das aber auch flexibel gestalten und somit
>> verschiedenen Bereichen einer Website komplett unterschiedliche Layouts
>> verpassen.
>
>Das hab ich sowieso vor. Dank der Vererbung klappt das schmerzfrei.
>
>Mittlerweile denke ich über domainübergreifende Systeme nach...
Ich hab meine ganze Codebasis schon vor einiger Zeit gesplittet in einen
projektunabhängigen 'lib'-Teil und einen projektspezifischen. Sämtliche
neuen Komponenten, Module usw. werden nach Möglichkeit so gestrickt, daß
sie unter 'lib' gespeichert werden können und sich somit leicht wieder-
verwenden lassen. Dazu zählen insbesondere solche Dinge wie die diversen
Admin-Tools, Account-/Benutzerverwaltung, Sessionverwaltung, etliche
vordefinierte Views und natürlich die ganzen Komponenten für die Appli-
kation selbst (Klassenlader, Sitemap, Datenbank, Logs etc.)
Micha
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 00:58:12 von bk
Ich weiss, wird sind hier nicht in einer Ruby-Newsgroup,
aber Ruby on Rails setzt seit Beginn strikte auf MVC.
Zur Idee von MVC (kreiert von Trygver 1979), cf.
http://folk.uio.no/trygver/
Denny Carl, Praxiswissen, Ruby on Rails (O'Reilly)
bringt das MVC so auf den Punkt:
# Model
Kümmert sich um Beschaffung, Bereitstellung, Verarbeitung und
Speicherung von Daten (wird oft auch als Geschäftslogik bezeichnet)
[for handling data and business logic]
# View
Präsentationslogik: Darstellung der Model-Daten.
Bietet u.a. dem User Elemente zur Bedienung der Software, die zB
Aktionen auslösen, damit neue Daten vom Model geliefert werden.
[for handling graphical user interface objects and presentation logic]
# Controller
Koordination zwischen Model und View.
Die Programmsteuerungslogik.
Controller fordert Daten vom Model an und leitet sie gegebenenfalls
aufbereitet an einen View weiter, der sie darstellt.
Der Controller empfängt zudem Daten, beispielsweise aus einem Formular
des Views, und leitet sie an den Model-Teil weiter
[for handling the user interface and application logic]
beda
> Niels Braczek schrieb:
>> Ich werde das Gefühl nicht los, dass zwei sich zT. widersprechende
>> Auffassungen von MVC kursieren. Die eine (mir vertrautere) assoziiert
>> mit "Model" das Daten(bank)-Modell und mit "Controller" im Wesentlichen
>> die Business-Logik, die andere mit "Model" das Business-Modell und mit
>> "Controller" die Benutzerschnittstelle. Nur in puncto "View" scheinen
>> diese Auffassungen übereinzustimmen. Weià da jemand Genaueres?
>
> Also ich meine das ausschliesslich als Pattern im Sinne von OOP wo der
> Begriff in den 80ern auch entstanden ist. Das hat zunächst nichts mit
> Datenbanken oder Businesslogik zu tun. Das sind schlicht abstrakte
> Klassen ("abstrakt" im abstrakten Sinne).
>
> Natürlich kann hinter dem Modell eine Datenbank stehen aber genau davon
> abstrahiert das OOP-Modell da es die Daten nicht als Relation sondern als
> Objekt beschreibt, also als Satz von Methoden und damit verbundenen
> Protokollen. Wie die Daten gespeichert werden ist View und Controller
> egal. OOP-Datenbanken sind wieder eine andere Baustelle.
>
> Der mir wenig vertraute Begriff der Businesslogik entstammt wohl eher der
> Applikationslogik im Zusammenhang mit Datenbanken und wird vermutlich
> durch eine Menge an kooperierenden Objekten implementiert die in einem
> GUI-System ggf. *auch* als Controller agieren können . Das ist m.E. eine
> ganz andere Sichtweise. Es ist immer problematisch für unterschiedliche
> Dinge aus unterschiedlichen Welten die gleichen Worte zu verwenden.
>
> Peter
>
> PS: Was zum Thema MVC in Wikipädia zu lesen ist, ist m.E. nicht nur
> javazentrisch sondern auch recht oberflächlich und geht am Kern der Sache
> vorbei.
>
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 02:17:54 von Peter Sommerfeld
Harald Stowasser schrieb:
> Beispiele:
> Wenn man in PHP ein Singleton schreibt, wird dieses jedoch trotzdem von
> mehreren Prozessen Instanziert. Es existiert also in Wirklichkeit
> *nicht* nur einmal.
> In Java-Tommcat ist jedoch ein Singleton währen der gesamten Laufzeit
> des Servers auch wirklich nur einmal instanziert.
>
> In PHP wird ein Static-member wird nach dem Ausliefern des Response
> zerstört. Bei Java-Tommcat bleibt der Wert im Speicher, und steht beim
> Nächsten Aufruf der Seite(oder was auch immer) wieder zur Verfügung.
>
> Bei Zope ist die Applicationsschicht sogar eine komplette
> Objektorientierte Datenbank (Bobobase aka ZODB). Du musst dich dabei
> dann nicht mal groà ums Speichern kümmern.
Das alles hat nur nichts mit PHP, Java oder was sonst zu tun sondern ist
ein Problem der Prozessynchronisation. Du vergleichst hier Ãpfel mit
einem fertigen Apfelkuchen.
PHP ist eine Sprache wie Python auch in dem ursprünglich mal Zope
implementiert worden ist (ich weiss nicht ob das immer noch so ist). Und
auch in Python gibt es kein Singletons die das Prozessende überleben es
sei denn (!) man serialisiert sie in eine Datenbank oder hält sie im
Speicher *und* reguliert den Zugriff der verschiedene Prozesse über einen
geeigneten Scheduler. Ein Singleton im Sinne von OOP ist etwas ganz
anderes als das was du hier als Singleton bezeichnest. Warum also die
gleichen Bezeichner verwenden?
Natürlich lieÃe sich ein solcher Applikationsserver auch in PHP + einer
Datenbank und evtl. etwas unterstützendem C-Code entwickeln (gibt es so
etwas?). Ob man das tun sollte ist natürlich eine ganz andere Frage. Es
gibt schon schwerwiegende Gründe warum die Prozessychronisation bei
nahezu allen Programmiersprachen herausgehalten wird. Mir fallen da im
Moment nur Simula, Occam, Erlang und in gewissem Sinne Lua ein wo das
anders ist, aber es gibt noch einige, wenige andere.
Peter
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 02:47:39 von Peter Sommerfeld
Peter Sommerfeld schrieb:
> Konni Scheller schrieb:
>
>> http://www.webseitenkoch.de/OxCMS/oxcms0.01.zip
>>
>> Bitte um Kommentare und Kritik... :)
>
> Das sieht soweit ich das nach diagonalem überlesen sehen kann nach einem
> sauberen Design aus bei dem natürlich noch vieles fehlt.
Konni,
ich habe das vorhin etwas kurz abgehandelt daher noch ein kurzer Nachtrag:
Ich verstehe deine Ausgangsfrage jetzt so ob ein MVC-Struktur im
Unterschied zu deinem gegenwärtigen Entwurf wesentliche Vorteile bringen
würde. Ich denke das dein Entwurf den groÃen Vorzug relativer Einfachheit
und Gradlinigkeit hat und für das was du offenbar damit im Sinne hast und
noch eine ganze Menge mehr allemal geeignet ist. Komplexere Strukturen
machen m.E. erst bei komplexeren Anforderungen Sinn denn man muss auch
immer einen Preis dafür zahlen, - Laufzeitoverhead, Entwicklungszeit etc.
Danke für die Diskussion, es hat mich angeregt über mir vertrautere
Methoden im Umfeld von PHP/Webservern nachzudenken.
Peter
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 09:18:58 von Harald Stowasser
Peter Sommerfeld schrieb:
> Harald Stowasser schrieb:
>> Beispiele: Wenn man in PHP ein Singleton schreibt, wird dieses
>> jedoch trotzdem von mehreren Prozessen Instanziert. Es existiert
>> also in Wirklichkeit *nicht* nur einmal. In Java-Tommcat ist jedoch
>> ein Singleton währen der gesamten Laufzeit des Servers auch
>> wirklich nur einmal instanziert.
>>
>> In PHP wird ein Static-member wird nach dem Ausliefern des Response
>> zerstört. Bei Java-Tommcat bleibt der Wert im Speicher, und steht
>> beim Nächsten Aufruf der Seite(oder was auch immer) wieder zur
>> Verfügung.
>>
>> Bei Zope ist die Applicationsschicht sogar eine komplette
>> Objektorientierte Datenbank (Bobobase aka ZODB). Du musst dich
>> dabei dann nicht mal groà ums Speichern kümmern.
>
> Das alles hat nur nichts mit PHP, Java oder was sonst zu tun sondern
> ist ein Problem der Prozessynchronisation. Du vergleichst hier Ãpfel
> mit einem fertigen Apfelkuchen.
Nö, ich verglich Systeme miteinander, die HTML ausliefern. Das ist doch
wohl legitim?
Prozessychronisation ist ein Problem(chen) hat jedoch nur Sekundär mit
dem Thema zu tun.
In Java gibts z.B. synchronized welches eine Prozessynchronisation sehr
vereinfacht:
public synchronized static Singleton getInstance() {
if(singleton == null) singleton = new Singleton();
return singleton;
}
> PHP ist eine Sprache wie Python auch in dem ursprünglich mal Zope
> implementiert worden ist (ich weiss nicht ob das immer noch so ist).
Ja das ist so und wird sich auch so schnell nicht ändern ;-)
> Und auch in Python gibt es kein Singletons die das Prozessende
> überleben es sei denn (!) man serialisiert sie in eine Datenbank oder
> hält sie im Speicher *und* reguliert den Zugriff der verschiedene
> Prozesse über einen geeigneten Scheduler.
Auch in Java sollten Singletons das Prozessende nicht überleben. Der
unterschied zwischen /Serverscripts/ und einem Application-Server ist ja
gerade das der Prozess *nicht* mit dem Response endet.
Und man hat damit mehr Möglichkeiten.
In Zope/Python ist die Serialisierung in die DB transparent.
> Ein Singleton im Sinne von OOP ist etwas ganz anderes als das was du
> hier als Singleton bezeichnest. Warum also die gleichen Bezeichner
> verwenden?
Nö. Wie kommst du da drauf? Ein Singleton ist ein Singleton wo sollte
ich da was verwechselt haben?
> Natürlich lieÃe sich ein solcher Applikationsserver auch in PHP +
> einer Datenbank und evtl. etwas unterstützendem C-Code entwickeln
> (gibt es so etwas?).
http://www.php-faq.de/q/q-php4-application-server.html
> Ob man das tun sollte ist natürlich eine ganz
> andere Frage. Es gibt schon schwerwiegende Gründe warum die
> Prozessychronisation bei nahezu allen Programmiersprachen
> herausgehalten wird. Mir fallen da im Moment nur Simula, Occam,
> Erlang und in gewissem Sinne Lua ein wo das anders ist, aber es gibt
> noch einige, wenige andere.
Ich kenne keine moderne Programmiersprache, in der man keine
Prozessychronisation Implementieren kann.
In Pascal, Ada, Java oder C# sind Mutexe sogar *bestandteil* der Sprache.
Für fast alle Sprachen gibt es Bibliotheken, die ein Mutex-System
implementieren, häufig ist dies sogar Teil der Standard-API bzw. der
Laufzeitumgebung.
Für Prozessychronisation in PHP ist http://de.php.net/sem eine gute
anlaufstelle.
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 09:21:07 von Harald Stowasser
Konni Scheller schrieb:
> Harald Stowasser wrote:
>
>> Mit Ajax geht sowas. Ist aber relativ kompliziert.
>> Du musst z.B. den Observer von Zeit zu Zeit aufräumen, weil die
>> Observerable ja schon lang weg sein können ohne sich abzumelden.
>
> Stimmt. Die Frage ist, wie man das mitkriegt. :-(
Ping-Pong spielen:
http://de.wikipedia.org/wiki/Ping-Pong-Verfahren
>> Wie definierst du "on-the-fly generiert".
>
> Im Gegensatz zu statischen Seiten.
Dann bist du hier in der richtigen Gruppe :-)
Gruß
Harald
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 10:18:03 von Peter Sommerfeld
Harald Stowasser schrieb:
> Nö, ich verglich Systeme miteinander, die HTML ausliefern. Das ist doch
> wohl legitim?
Klar, unser Bauer nebenan liefert auch Kartoffeln aus, tonnenweise.
Dennoch ist das eine ganz andere Liga als der Einzelhandel mit seinen 3kg
Packerln.
> Auch in Java sollten Singletons das Prozessende nicht überleben. Der
> unterschied zwischen /Serverscripts/ und einem Application-Server ist ja
> gerade das der Prozess *nicht* mit dem Response endet. Und man hat damit
> mehr Möglichkeiten.
Unstrittig. Kostet aber auch eine Menge mehr. Nicht das dickste Auto ist
immer das angemessene, YMMV.
> Nö. Wie kommst du da drauf? Ein Singleton ist ein Singleton wo sollte
> ich da was verwechselt haben?
Den Kontext.
> Ich kenne keine moderne Programmiersprache, in der man keine
> Prozessychronisation Implementieren kann.
>
> In Pascal, Ada, Java oder C# sind Mutexe sogar *bestandteil* der
> Sprache.
Das sind nur kleine Bausteinchen mit denen man das *implementieren* kann,
und auch muss so man denn eine ernsthafte Synchronisation von Prozessen
haben will.
Aber lass mal, wir reden über verschiedene Baustellen. Ich stimme dir ja
zu das ein Applikationsserver eine gute Sache ist wenn man die Feature
braucht und den Preis bezahlen will. Nur hat das mit OOP, MVC und der
Ausgangsfrage des OP wenig zu tun...
Peter
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 10:41:42 von kscheller
Harald Stowasser wrote:
> Ping-Pong spielen:
> http://de.wikipedia.org/wiki/Ping-Pong-Verfahren
;)
> >> Wie definierst du "on-the-fly generiert".
> >
> > Im Gegensatz zu statischen Seiten.
>
> Dann bist du hier in der richtigen Gruppe :-)
Wenn ich mit PHP statische Seiten (lokal) erzeuge und die dann hochlade,
ist das doch auch OnTopic? ;)
Servus,
Konni
--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 11:01:08 von Harald Stowasser
Peter Sommerfeld schrieb:
>> Nö, ich verglich Systeme miteinander, die HTML ausliefern. Das ist doch
>> wohl legitim?
>
> Klar, unser Bauer nebenan liefert auch Kartoffeln aus, tonnenweise.
> Dennoch ist das eine ganz andere Liga als der Einzelhandel mit seinen 3kg
> Packerln.
Ja.
Sicherlich kannst du den Bauer nebenan fragen ob er dir eine Tüte mit
Kartoffeln voll machen will. Zwischen Nachbaren sollte sowas doch gehen :-)
>> Auch in Java sollten Singletons das Prozessende nicht überleben. Der
>> unterschied zwischen /Serverscripts/ und einem Application-Server ist ja
>> gerade das der Prozess *nicht* mit dem Response endet. Und man hat damit
>> mehr Möglichkeiten.
>
> Unstrittig. Kostet aber auch eine Menge mehr. Nicht das dickste Auto ist
> immer das angemessene, YMMV.
Ja.
>> Nö. Wie kommst du da drauf? Ein Singleton ist ein Singleton wo sollte
>> ich da was verwechselt haben?
>
> Den Kontext.
Singelton war nur ein Beispiel um zu verdeutlichen was ich unter
Application-Level verstehe.
Dort sind die Unterschiede sehr signifikant.
> Aber lass mal, wir reden über verschiedene Baustellen. Ich stimme dir ja
> zu das ein Applikationsserver eine gute Sache ist wenn man die Feature
> braucht und den Preis bezahlen will. Nur hat das mit OOP, MVC und der
> Ausgangsfrage des OP wenig zu tun...
Konni hat in <1i6tl6l.1vz8hdbrz80tzN%kscheller@ochs.franken.de> danach
gefragt.
Mein geschreibsel liest sich wohl möglich wie PHP-Bashing. Das war
sicher nicht meine Absicht.
Eigentlich neige ich eher dazu *alle* Programmiersprachen zu Bashen. :-)
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 13:10:51 von Christoph Herrmann
Martin Lemke schrieb:
> In der Quintessenz bedeutet dies, dass es overkill wäre, wenn man definitiv
> nur ein einziges Ausgabeformat erzielen möchte: html. Sehe ich das so
> richtig?
nein nicht unbedingt. Es kommt drauf an was du brauchst. Wenn du weißt,
dass niemals ein anderes Format unterstützen willst, wäre eine
allgemeine Lösung nur Overhead. Nur ich lasse mir gerne die Möglichkeit
offen ganz einfach andere Formate zusätzlich einzubinden.
--
Mit freundlichen Grüßen,
Christoph Herrmann
http://dragonprojects.de/
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 13:28:25 von Peter Sommerfeld
Harald Stowasser schrieb:
> Eigentlich neige ich eher dazu *alle* Programmiersprachen zu Bashen. :-)
DAS ist natürlich auch eine Möglichkeit !
Peter
Re: Saubere Umsetzung des MVC-Modells
am 31.10.2007 21:22:37 von Stefan Ohrmann
Hallo,
Am 30.10.2007 12:12 schrieb Harald Stowasser:
> Nur in manchen Ausnahmen (z.B. Bäumen) ist es notwendig das dass Modell
> auch den View kennt.
Warum?
MfG
Stefan
--
Some programming languages manage to absorb change but withstand progress.