Hallo,

ich bastle seit langer Zeit an meinem CMS, welches auch ganz brauchbar
funktioniert. Weil ich auf PHP5 umstelle (schon?... jaja...), möchte ich
es auch gleich "richtig" machen und das Model-View-Controller Zeuch auch
so implementieren.

Das Datenmodell war schnell angelegt. Im Prinzip ein Composite-Objekt
("page"), das die Webseite beschreibt. So funktioniert alles auch ganz
schön. Aber ich muss ja mit der "bösen" Außenwelt in Verbindung treten.

Wie fügt man korrekt Views und Controller ein? Ich könnte mir da
folgendes vorstellen:

1. dem View ein page-Objekt übergeben und sagen "mach mal".

2. Im page-objekt eine Methode, $seite->view(), die dann das
entsprechende View-Objekt aufruft, also eher wie ein Strategy-Pattern.

Welches ist der richtige Ansatz?

Weiterhin muss ich ja im View noch die HTML-Widgets unterbringen, das
hängt aber wieder vom Controller ab.

Wie macht man gewöhnlich sowas?

Servus,
Konni

--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/

Konni Scheller wrote:
ich bastle seit langer Zeit an meinem CMS, welches auch ganz brauchbar
> funktioniert. Weil ich auf PHP5 umstelle (schon?... jaja...), möchte ich
> es auch gleich "richtig" machen und das Model-View-Controller Zeuch auch
> so implementieren.

Hast du dir mal die MVC-Komponente vom Zend-Frramework angesehen? Da
kannst du dir entweder Ideen holen oder vllt. das ganze Ding in dein CMS
einbinden.
Es ist leicht zu verstehen, einfach erweiterbar und anpassbar, kann auch
ohne den Rest vom Framework verwendet werden, ist sehr gut dokumentiert
und kostnix.
Am besten hier anfangen zu lesen:
http://framework.zend.com/manual/en/zend.controller.html#zen d.controller.quickstart

cu
his

Hinrich Sager <hinrichsager [at] gmx.de> wrote:

> Hast du dir mal die MVC-Komponente vom Zend-Frramework angesehen? Da
> kannst du dir entweder Ideen holen oder vllt. das ganze Ding in dein CMS
> einbinden.

Das mit dem Einbinden ist so eine Sache... :-(

Ich habe damit schlechte Erfahrungen gemacht. Manchmal gibt es ein
upgrade, welches dann *nicht* kompatibel zur Vorgängerversion ist (so
mit PEAR QuickForms passiert), und schon geht das Gerödel los.

Ich wollte es eigentlich von Grund auf selbst schreiben, schon mal, um
mich nicht von irgendwelchen Upgrade-Pfaden abhängig zu machen.

> Es ist leicht zu verstehen,

Du meinst sicher "anzuwenden". Verstehen tu ich das nicht auf Anhieb...

> einfach erweiterbar und anpassbar, kann auch
> ohne den Rest vom Framework verwendet werden, ist sehr gut dokumentiert
> und kostnix.
> Am besten hier anfangen zu lesen:
> http://framework.zend.com/manual/en/zend.controller.html

Oje, oje, oje... das ist ja schon wieder viel zu mächtig.

Alleine das Diagramm auf
<http://framework.zend.com/manual/en/figures/zend.controller.basics.png>
zu verstehen, kostet mich ja schon einen Tag :-(

Ich wehr mich nicht ernsthaft dagegen, das durchzulesen, aber ich denke,
da muss es doch etwas einfacheres geben.

Servus,
Konni
(Lesebrille rauskramend und Kästchen malend...)

--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/

Moin Konni,

Konni Scheller wrote:
> Hinrich Sager <hinrichsager [at] gmx.de> wrote:
>
>> Hast du dir mal die MVC-Komponente vom Zend-Frramework angesehen? Da
>> kannst du dir entweder Ideen holen oder vllt. das ganze Ding in dein C=
MS
>> einbinden.
>
> Das mit dem Einbinden ist so eine Sache... :-(
>
> Ich habe damit schlechte Erfahrungen gemacht. Manchmal gibt es ein
> upgrade, welches dann *nicht* kompatibel zur Vorgängerversion ist (so=

> mit PEAR QuickForms passiert), und schon geht das Gerödel los.

Ich verwende xmlform(). Da gibt es recht wenig =DCberraschungen. Kennt
kaum einer, aber jeder der es verwendet ist recht angetan. Ich selbst
auch... Kennst du das?

> Ich wollte es eigentlich von Grund auf selbst schreiben, schon mal, um
> mich nicht von irgendwelchen Upgrade-Pfaden abhängig zu machen.

Coole Einstellung, mache ich (fast) auch immer so. Erfordert nur immer
viel Zeit und Muße, lohnt sich aber in jedem Fall.

> Oje, oje, oje... das ist ja schon wieder viel zu mächtig.

Die Versuche, ORM in meine Projekte Einzubinden, verschlangen ganze 2
Tage und erbrachten die Erkenntnisse, dass der "Rattenschwanz" in
keinster Weise absehbar wurde. Zudem hätte ich einige, seit Jahren
hervoragende Komponenten anpassen müssen, was den Spaß an diesem Kram=

eindeutig vermießt hätte.
Also habe ich es schlicht und ergreifend gelassen, mir mein eigenes
"quasi-ORM"-System gebastelt und lebe sehr gut damit.

Ich denke nicht, dass es bei anderen Systemen besser ist. Nur ganz,
ganz kleine Klassen, die mehr als Funktionsblock angesehen werden
können, werden assimiliert.

Gruß
Anne

Hallo,

Anne Kaeppes wrote:
> Ich verwende xmlform(). Da gibt es recht wenig Überraschungen. Kennt
> kaum einer, aber jeder der es verwendet ist recht angetan. Ich selbst
> auch... Kennst du das?
ein Link wuerde mich erfreuen.

Vielen Dank.
mfg. klaus.

Klaus Herzberg wrote:
> Anne Kaeppes wrote:
>> Ich verwende xmlform(). Da gibt es recht wenig =DCberraschungen. Kennt=

>> kaum einer, aber jeder der es verwendet ist recht angetan. Ich selbst =

>> auch... Kennst du das?

> ein Link wuerde mich erfreuen.

Wenn es denn mal einen geben würde. Das Projekt wird von einer kleinen =

Softwareschmiede betrieben und ich hatte von denen mal ein Projekt
weiterbetreut. Da bin ich auf die Klasse gestoßen und hinterfragte nach=

der technischen Doku und bekam auch gleich die aktuellste Version mit.

Ich muss mal die Kontakt-E-Mail raussuchen...

Gruß
Anne

Anne Kaeppes <nomail [at] invalid> wrote:

> Ich verwende xmlform(). Da gibt es recht wenig Überraschungen. Kennt
> kaum einer, aber jeder der es verwendet ist recht angetan. Ich selbst
> auch... Kennst du das?

Nein. Kannst du das kurz beschreiben?

> > Ich wollte es eigentlich von Grund auf selbst schreiben, schon mal, um
> > mich nicht von irgendwelchen Upgrade-Pfaden abhängig zu machen.
>
> Coole Einstellung, mache ich (fast) auch immer so. Erfordert nur immer
> viel Zeit und Muße, lohnt sich aber in jedem Fall.

Es ist sehr lehrreich, das zu tun. Danach sollte man sich etwas fertiges
ansehen, das verstehen und von vorne beginnen ;)

> Die Versuche, ORM in meine Projekte Einzubinden,

was ist ORM?

> Ich denke nicht, dass es bei anderen Systemen besser ist. Nur ganz,
> ganz kleine Klassen, die mehr als Funktionsblock angesehen werden
> können, werden assimiliert.

So sehe ich das auch.

Bis jetzt bin ich auf einem sehr abstrakten Level. Im Prinzip baue ich
das Datenmodell und einige grundlegende Funktionen zum Manipulieren. Der
Gedanke der Struktur einer Site lässt sich sehr schön abstrahieren, bis
das fertige Gebilde kaum noch zu gebrauchen ist ;)

"Mit prozuderaler Programmierung kann man sich ins Knie schießen. Mit
objektorientierter auch, aber man kann die Kugel wiederverwenden."

Servus,
Konni


Servus,
Konni

--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/

Konni Scheller wrote:
> Hinrich Sager <hinrichsager [at] gmx.de> wrote:

>> Am besten hier anfangen zu lesen:
>> http://framework.zend.com/manual/en/zend.controller.html
>
> Oje, oje, oje... das ist ja schon wieder viel zu mächtig.
>
> Alleine das Diagramm auf
> <http://framework.zend.com/manual/en/figures/zend.controller.basics.png>
> zu verstehen, kostet mich ja schon einen Tag :-(

Die Grafik ist unter pädagogischen Gesichtspunkten an dieser Stelle
sicher nicht das Klügste. Vergiss sie erstmal. Lies einfach und probier
die Beispiele aus. Dann wirst du anbeißen. ;)

cu
his

Konni Scheller wrote:
> Anne Kaeppes <nomail [at] invalid> wrote:
>
>> Ich verwende xmlform(). Da gibt es recht wenig =DCberraschungen. Kennt=

>> kaum einer, aber jeder der es verwendet ist recht angetan. Ich selbst
>> auch... Kennst du das?
>
> Nein. Kannst du das kurz beschreiben?

Im Prinzip werden Formulare mit Hilfe von XML beschrieben. In diesen
Beschreibungen sind nicht nur die notwendigen Formular-Elemente wie
text, buttons etc. sondern bereits solche Kunst-Konstrukte wie
"confirm-buttons", die vorher noch Fragen, ob man wirklich was löschen =

will oder so (Text ist frei definierbar). Zudem sind auch schon
Konstrukte wie xajaxinput-Felder vorhanden. Also im Prinzip alles, was
man so braucht.

Man definiert also das Formular komplett durch und das war es.

Ein komplett fertig definiertes Formular wird in ein Array gespeichert:

$xmlform=3Dnew xmlform($dasarray);
$xmlform->buildform("NameDesFormulars", FehlerCodes, ElementInhalte);

Reicht dann aus...

Die Formularprüfung erfolgt dann mit:

$ElementInhalte=3D$xmlform->checkall("post")

Ob nun Fehler in der Eingabe vorhanden war, ermittelt man mit
if( !$FehlerCodes=3D$xmlform->getinputerror()){
// keine Fehler
} else {
// Doch Fehler
}

Die Variable Fehlercodes wird nun wieder oben in den Aufruf eingebunden
und die Felder werden entsprechend farblich dargestellt, was z.B. über =

die css eingestellt.
Die Validierung der Felder wird bereits in der XML-Definition
vorgegeben (Reguläre Ausdrücke, Maximale Länge der Felder usw.)

Die Fehlermeldungen (Feld ist leer o.ä.) generiert das Programm
automatisch (muss nur abgerufen werden).

Nebenbei bemerkt, ist das ganze Tool komplett mehrsprachig ausgelegt,
dass heisst die Formulare können komplett mehrsprachig beschrieben
werden. Select, Radio, Checkbox können direkt aus SQL-Querys generiert =

werden (ebenfalls mehrsprachig).
Viele Parameter können noch nachträglich dynamisch geändert werden =

(z.B. Auslassen oder ausblenden von FormularElementen,
Formularelemente als readonly deklarieren, Dynamische Abfragen
nachträglich manipulieren oder oder oder...)

Alles in allem bin ich sehr damit zufrieden. Was für mich die ganze
Sache noch interessanter macht ist eine Javascript Erweiterung, welche
die Formular komplett AJaX-Fähig macht. Das heisst in meinen
Anwendungen entfällt das Neuladen der Webformulare komplett.

So das war jetzt aber die absolute Kurzbeschreibung...

Gruß
Anne

Konni Scheller schrieb:

> möchte ich
> es auch gleich "richtig" machen und das Model-View-Controller Zeuch auch
> so implementieren.

Ich habe mit dem Zendframework diesbezüglihc shcon mal experimentiert, aber
irgendwie blicke ich nicht den Vorteil von dem allem. In wiefern ist MVC
vorteilhaft gegenüber einer konventionellen Template-Lösung?

Martin

Konni Scheller schrieb:
> Wie fügt man korrekt Views und Controller ein?
> [...]
> Wie macht man gewöhnlich sowas?

Die übliche Lösung ist wohl ein Observer-Pattern, d.h du richtest im
Modell eine Registrierung für bestimmte Events ein. Etwa so:

class Modell{
function register($callback, $event){...}
}

$callback kann im einfachsten Falle eine Funktion oder auch ein array
(class,method) sein. Event kann ein einfacher Wert oder auch ein array
(key,event) sein. Jetzt können sich view und controller registrieren und
bekommen bei entsprechenden Veränderungen eine Nachricht.

Zusätzlich sind View wund Controller miteinander verlinkt. Also etwa so:

class Controller{

private $modell;
private $view = array();

function modellUpdate(){...}

function __construct(){
$this->modell = new Modell();
$this->view[] = new View($this,$this->modell);
$this->modell.register(
array('Controller','ModellUpdate'),
'update');
}
}
Das View merkt sich den Controller und registriert sich ggf. selbst beim
Modell.

Der Vorzug des Ganzen ist dass es sehr variable ist, d.h. du kannst
beliebig viele MVC miteinander zusammenstecken. Der Nachteil
ist dass du das dann auch tun must und den Ãœberblick behalten :-)

wie die Interaktion zwischen Modell/View/Controller genau aussieht hängt
vom konkreten Anwendungsfall ab. Es gibt da jede Menge möglicher
Varianten.
Schau dir mal "Twisting the Triad" von Dolphin Smalltalk an:
http://www.object-arts.com/content/navigation/support/papers _main.html

HTH, Peter

Martin Lemke schrieb:
> Ich habe mit dem Zendframework diesbezüglich schon mal experimentiert,
> aber irgendwie blicke ich nicht den Vorteil von dem allem. In wiefern
> ist MVC vorteilhaft gegenüber einer konventionellen Template-Lösung?

Ich kenne das Zendframework nicht und weiss auch nicht was du unter einer
konventionellen Template Lösung verstehst.

MVC ist einfach ein objektorientiertes Pattern das den Vorzug hat dass du
die unterschiedlichsten Komponenten beliebig miteinander verdraten
kannst, also z.B. mehrere unterschiedliche Views/Controller für ein
Modell. Da Zugriff und Interaktion standartisiert sind brauchst du bei
Veränderungen immer nur einzelne Komponenten ändern oder bei Veränderung
der Anforderungen neu schreiben.

Peter

Peter Sommerfeld <none [at] nowhere.at> wrote:

> Die übliche Lösung ist wohl ein Observer-Pattern,

Argl! *stirnpatsch* Is ja eigentlich klar. :-)


> Zusätzlich sind View wund Controller miteinander verlinkt. Also etwa so:
>
> class Controller{
>
> private $modell;
> private $view = array();
>
> function modellUpdate(){...}
>
> function __construct(){
> $this->modell = new Modell();
> $this->view[] = new View($this,$this->modell);
> $this->modell.register(
> array('Controller','ModellUpdate'),
> 'update');
> }
> }
> Das View merkt sich den Controller und registriert sich ggf. selbst beim
> Modell.
>
> Der Vorzug des Ganzen ist dass es sehr variable ist, d.h. du kannst
> beliebig viele MVC miteinander zusammenstecken. Der Nachteil
> ist dass du das dann auch tun must und den Überblick behalten :-)

klingt sehr nach dem, was ich wollte :-) Danke!

> wie die Interaktion zwischen Modell/View/Controller genau aussieht hängt
> vom konkreten Anwendungsfall ab. Es gibt da jede Menge möglicher
> Varianten.
> Schau dir mal "Twisting the Triad" von Dolphin Smalltalk an:
> http://www.object-arts.com/content/navigation/support/papers _main.html

Gebookmarkt. Kommt morgen dran.

Servus,
Konni

--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/

Peter Sommerfeld schrieb:
> Martin Lemke schrieb:
>> Ich habe mit dem Zendframework diesbezüglich schon mal experimentiert,
>> aber irgendwie blicke ich nicht den Vorteil von dem allem. In wiefern
>> ist MVC vorteilhaft gegenüber einer konventionellen Template-Lösung?
>
> Ich kenne das Zendframework nicht und weiss auch nicht was du unter einer
> konventionellen Template Lösung verstehst.
>
> MVC ist einfach ein objektorientiertes Pattern das den Vorzug hat dass du
> die unterschiedlichsten Komponenten beliebig miteinander verdraten
> kannst, also z.B. mehrere unterschiedliche Views/Controller für ein
> Modell. Da Zugriff und Interaktion standartisiert sind brauchst du bei
> Veränderungen immer nur einzelne Komponenten ändern oder bei Veränderung
> der Anforderungen neu schreiben.

einfaches Beispiel:

Modell: Du hast ein Modell dass eine Tabelle aufzeigt und verschiedene
Methoden um darauf zugreifen zu können (get($row, $column),
getRowCount(), getColumnCount()).

View: Jetzt kannst du mehrere Views machen die diese Methoden verwenden
um die Daten anzuzeigen, z.B. in HTML oder auch als CSV Format. Diese
greifen dann auf die Standardisierten Methoden von oben zu.

Controller: Der Controller wäre dann eine Select Box oder ähnliches für
den Benutzer, der auswählt in welchem Format er welche Daten haben will.

Vorteile: Nun kannst du weitere Daten anbieten, indem diese ebenfalls
die Schnittstelle für den Zugriff implementieren oder auch neue Formate
anbieten indem neuer Viewer bereit stellst. Egal was änderst (Modell,
View oder Controller) brauchst keine andere Komponente zu verändern.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann <herrmann [at] dragonprojects.de> wrote:

Das MVC in der Theorie ist mir klar, danke.

> Modell: Du hast ein Modell dass eine Tabelle aufzeigt und verschiedene
> Methoden um darauf zugreifen zu können (get($row, $column),
> getRowCount(), getColumnCount()).

Da würde ich jetzt das ganze doch von der konkreten Realisation lösen:
$store->getBook($title) $store->getNumberOfBooks() usw. anstatt das auf
eine Tabelle zu fixieren.

> View: Jetzt kannst du mehrere Views machen die diese Methoden verwenden
> um die Daten anzuzeigen, z.B. in HTML oder auch als CSV Format. Diese
> greifen dann auf die Standardisierten Methoden von oben zu.

Die frage war eben, wie löst man das - und das Stichwort "Observer" hat
mir schon gereicht. :-)

In diesem Fall würde das konkret so aussehen:

$store->registerView($tableView);

und dann bekommt der TableView damit direkten Zugriff auf die
Ausgabeoptionen:

$tableView->render();

oder so.

Servus,
Konni

--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/

Konni Scheller schrieb:
> Da würde ich jetzt das ganze doch von der konkreten Realisation lösen:
> $store->getBook($title) $store->getNumberOfBooks() usw. anstatt das auf
> eine Tabelle zu fixieren.

nein, genau das sollte man ja nicht machen. Wenn du das so machst, musst
du für jede deiner Klassen einen eigenen Viewer machen. Du kannst es
aber auch einfach über eine Schnittstelle lösen und diese Schnittstelle
mit den Methoden in deiner Buchklasse implementieren und kannst dann die
allgemeinen Viewer benutzen. Auf diese Weise haste für jedes Format eine
Viewerklasse, die jede zweidimensionale Datenstruktur ausgeben kann mit
der Schnittstelle.

> Die frage war eben, wie löst man das - und das Stichwort "Observer" hat
> mir schon gereicht. :-)
>
> In diesem Fall würde das konkret so aussehen:
>
> $store->registerView($tableView);
>
> und dann bekommt der TableView damit direkten Zugriff auf die
> Ausgabeoptionen:
>
> $tableView->render();

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.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Hallo,

Am 28.10.2007 22:02 schrieb Peter Sommerfeld:

> Schau dir mal "Twisting the Triad" von Dolphin Smalltalk an:
> http://www.object-arts.com/content/navigation/support/papers _main.html

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].

MfG

Stefan

[1] http://martinfowler.com/
[2] http://martinfowler.com/eaaDev/SupervisingPresenter.html
[3] http://martinfowler.com/eaaDev/PassiveScreen.html
[4] http://martinfowler.com/eaaDev/PresentationModel.html

--
It exists.
- The First Myth of Management

Christoph Herrmann <herrmann [at] dragonprojects.de> 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: <ol>
2-Spalten: <dl>
>=3 Spalten: <table>

--
Scharfe Wochen im Oktober - Meerrettichspezialitäten und mehr
http://www.scharfe-wochen.de/

Stefan Ohrmann <stefan.ohrmann [at] gmx.de> 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/

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

Peter Sommerfeld <none [at] nowhere.at> 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/

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

Konni Scheller schrieb:

> 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. "

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

--
| 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 =
|
------------------------------------------------------------ ------

Peter Sommerfeld <none [at] nowhere.at> 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:

<div id="modulname">
....content...
</div>

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/

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.

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 ;-)

Peter Sommerfeld <none [at] nowhere.at> 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/

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.

Konni Scheller <kscheller [at] ochs.franken.de> 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/

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

Peter Sommerfeld <none [at] nowhere.at> 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/

Harald Stowasser <stowasser [at] freinet.de> 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/

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

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

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

Peter Sommerfeld <none [at] nowhere.at> 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/

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.

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

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

Konni Scheller schrieb:
> Harald Stowasser <stowasser [at] freinet.de> 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.