[MVC] Variablen im Model über View setzen?

[hedonistics]

Haller Flasher,

habe eine kurze Frage bezüglich MVC.
Ist es erlaubt über die View mittels setter-Methoden im Model Eigenschaften zu setzen oder sollte man dies über den Controller machen?

Ich meine, wenn es um einfache Setzung von Variablen geht, finde ich den Weg über die View->Controller->Model bischen umständlich. Irgendwie gefällt mir da dann die Variante besser Eigenschaften über die View im Model festzulegen.

Habe das ganze jetzt im View gemacht, bin mir aber nicht sicher ob man das so machen kann. Bin für jeden Rat dankbar...

Gruß,
Hedo

[hazy fantazy]

Im klassichen MVC sollte das der Controller machen. Allerdings ist es oft so, dass View und Controller eins sind. Da macht die Unterscheidung keinen Sinn. Ich glaube, am wichtigsten beim MVC ist, das der View sich automatisch updated, wenn das Model geändert wird. Da der View das Model sowieso kennen muss, sehe ich deshalb eigentlich kein Problem damit, das Model vom View aus zu verändern.

mfg. h

[michael]

erlaubt ist was funktioniert, ob man das dann noch MVC nennen kann, bleibt zu diskutieren.
es birgt gefahren die größer weden, je nach komplexität und erweiterungsfähigkeit des
projekts und ob mehrere programmierer daran beteiligt sind.

ein schön getrenntes observer/subscriber verhältnis von
view und model wird zerstört. der view muss mehr über das model wissen
als nötig (nämlich auch noch die setter models kennen),
der view-code wird komplizierter.

der view wird dadurch mit dem model verkoppelt, wenn du ihn irgendwann
mit einem anderen model verwenden willst/musst, ist er unbrauchbar.

der controller soll schließlich entscheiden was benutzereingaben
des views für das model bedeuten. das ist seine aufgabe,
dafür kann man ihn anpassen ung ggf. austauschen.
er soll den view vom model entkoppeln, was du verhinderst.


gruß
michael

ps: verschoben, in diesen bereich passt es prima.

[bokel]

In einem Projekt habe ich mal eine Art Bindingklasse geschrieben. Dadurch habe ich erreicht, dass View und Model total unabhaengig voneinander waren. View und Model hatten verschiedene Bindings zur Verfuegung. Wenn ein View erzeugt worden ist, hat er sich beim Controller angemeldet und der hat dann die Bindings des Views mit denen des Modells verknuepft. Eigentlich war das eine schicke Sache, muss ich bei Gelegenheit nochmal rauskramen.

mfg. r

[hedonistics]

Danke erstmal für die Antworten...

Bin gerade dabei einen "erweiterten" flv player als mvc zu bauen. Erweitert deswegen, da später Funktionen hinzukommen, die es bisher so noch nicht gegeben hat.

Als MVC benutzte ich die Vorlage von Moock: EA 2.0. Jede View beinhaltet eine buildUI() und update() Methode. Teilweise hab ich aber noch kleine Probleme, bei denen ihr mir vielleicht helfen könnt.

1.) PlayerView ist dafür zuständig eine eigene VideoKomponente auf der Bühne anzulegen inkl. des VideoMonitors (eingebettetes Video). Für mich gehört diese VideoKomponente in eine View, da sie jar zur Darstellung des FLV-Datei benötigt wird. Richtig? Da mein PlayerModel nun allerdings noch keine Referenz zum VideoMonitor erhalten hat, übergebe ich gleichzeitig in buildUI() dem Model die diese, so dass ich dort später den netStream über "VideoMonitor.attachVideo(netStream)" anhängen kann (setze die referenz hier über die view über setter-Methode im Model). Kann man das so machen oder sollte man dies eher über den Controller setzen?

2.) Da mein Player eine XML Datei ausliest, möchte ich eine Ladereihenfolge erstellen. Zunächst soll ein Preloader für das zu ladenen XML-Dokument, anschließend ein Preloader für das buffering der flv-datei angezeigt werde.
Habe das nun so gelöst, das ich eine weitere View (XMLView) erstellt habe. Hier wird in der update() Methode der Ladestatus des Preloaders aktualisiert, indem ich im Model über getter-Methode den aktuellen Prozentwert des zuladenen XML-Dokumentes abfrage.
In meinem PlayerView befindet sich ebenfalls in der update() Methode ein Preloader, der aber erst dann angezeigt wird, sobald im Model die boolsche Variable XMLLoaded auf true ist. Das einzige was mich dabei stört, ist dass selbst wenn die Preloader nicht mehr benötigt werden, die Aufrufe in beiden update() Methoden bestehen bleiben und eventuell Performance schlucken? Oder ist das nicht erwähnenswert? Übrigens werden die Preloader mit removeMovieClip() entfernt.

Wichtig hierbei ist zu wissen, dass mein Model ein updateObservers alle 40 ms (25FPS) ausgibt, sobald das flv datei abgespielt wird, um die aktuelle Zeit anzuzeigen etc. Mich stört einfach, dass in den update() Methoden beider Views Aufrufe gestartet werden, die eigentlich nicht sooft ausgeführt werden müssten, sondern nur einmal, wie z.B. der preloader bzw. solange bis 100%.

Ich hoffe ich konnte mich halbwegs verständlich ausdrücken. Das ganze ist ja immer ein bischen schwer zu beschreiben und mit Klassen möchte ich euch nicht konfrontieren, da das nicht dazu beiträgt das ganze zu vereinfachen

ps: da fällt mir ein die daten die ich per aus dem xml dokument lade, lege ich ja im model ab oder?

Besten Dank im vorraus,
hedo

[michael]

so richtig begriffen hab ich deine struktur noch nicht.

du möchtest also einen flv-player programmieren.

dafür packst das videoobjekt, anzeigen und bedienelemente in den view, soweit so gut.
dann packst den netstream in das model und gibts vom view aus dem model eine referenz
auf das videobjekt?

was genau tut dein controller?

[hedonistics]

Soweit hast du alles richtig verstanden. Meine View gibt eine Referenz vom VideoObjekt ans Model, damit ich dort mein attachVideo ausführen kann. In der View attache ich die videokomponente per as.

Mein Controller an sich gibtUserinput weiter.
z.B. wird sobald der stop Button in der View gedrückt wird im controller die Funktion stopMedia() aufgerufen, die wiederum stopMedia() im Model aufruft (nennt sich doch wrapping oder?)

Ebenso beim mute Button oder bei der seekbar. Bei der seekbar wird bei onPress im Controller seeking(n:Number) aufgerufen. Von der View erhält der Controller den _xmouse Position auf der seekBar, reicht dieses Wert an seeking(n:Number) im Model weiter und die setzt dann über netStream.seek(n) die neue Position des Abspielkopfes...

Bis du der meinung, dass die NetConnection/NetStream Geschichte mit in die View kommt? Ich bin davon ausgegangen, dass das zum Model gehört, da man ja eventuell später die NetConnection schließen möchte oder eine neue aufbauen möchte....

[michael]

ja, da fängt dann irgendwann der glaubenskrieg an.

ich glaube würde der einfachheit halber den stream mit in den view packen.
die URL zum (stream die aus dem xml kommen?) ins model, dann kannst du auch wenn du den stream wechseln willst, vom model aus die streamurl updaten und der view erledigt den rest. allerdings machts dann nahezu keinen sinn mehr starten und stoppen des streams an den controller weiterzuleiten.

bin nicht sicher ob du dir mit striktem mvc bei einem
flv-player einen große gefallen tust.

[hedonistics]

Hi Michael,

bei deinem Aufbau, kann ich ja das MVC vergessen und am bessten gleich eine einzelne Klasse "Videoplayer.as" schreiben . Wenn ich das richtig verstehe würde sich dann in deiner View auch die Logik für das Abspielen von flv dateien befinden oder wie? Dann hat es sich ja erledigt mit dem MVC bei dir?

Da fällt mir noch ein Verständnisproblem ein. Micheal du hast gesagt:

ein schön getrenntes observer/subscriber verhältnis von
view und model wird zerstört. der view muss mehr über das model wissen
als nötig (nämlich auch noch die setter models kennen),
der view-code wird komplizierter.
der view wird dadurch mit dem model verkoppelt, wenn du ihn irgendwann
mit einem anderen model verwenden willst/musst, ist er unbrauchbar.

Meine Frage...
Wenn ich das nun alles brav über den Controller der View gemacht habe, warum wird dann die View nicht unbrauchbar, wenn ich ein anderes Model verwende? Schließlich kann ich ja nicht davon ausgehen, dass die im Controller gewrappten Methoden im neuen Model vorhanden sind? Oder ist mir da was entgangen?

Im übrigen verwende ich für die updates von Model kein updateObject (push-Methode), sondern die pull-Methode über get/set Methoden. Gefällt mir irgendwie besser, da ich ich nicht möchte, dass jede View alle geänderten Daten erhält, sondern nur die, die für die entsprechende View wichtig sind.

Und noch ein letzes...
Ist es eigentlich sinnig, eine eigene View für einen Preloader anzulegen? Ich möchte ja nun verschiede Ladestati anzeigen, z.b "Loading XML", "Buffering Video", "Loading XXX" usw. Das könnte man ja alles schon in eine View legen und im Model abfragen, ob gewissen Daten am Laden sind oder nicht? Und sofern dann einmal alles geladen ist, wäre ja das schöne, dass man diese View vom Model removen könnte und somit Performance spart?


Gruß,
Jan

[bokel]

Das Beispiel mit den Bindings habe ich nicht mehr gefunden. Aber hier ist ein Fragment, dass ähnlich funktioniert. Der Controller kennt beide, View und Model, wobei View und Model ansonsten völlig unabhängig voneinander sind. Im Grunde ist es dann wohl ein MVP und kein MVC. Mir ging es her nur darum zu zeigen wie Model, View und Controller zusammenhängen, bis zu einer vollständigen Anwendung fehlt noch eine ganze Menge.

mfg. r

[mojave]

Hi,
Ich habe mir nicht alles durchgelesen nur ist mir zur Fragestellung ein Beispiel eingefallen:

Ich denke: Vorraussetzung für die Notwendigkeit eines Controllers ist das Projekt mit Anforderungen.

Erklärung an einem sehr simplen Beispiel:
nehmen wir an ziel ist es einen videoplayer programmieren. also eine applikation die ausschließlich das abspielen von flv dateien ermöglichen soll.

die view bietet nach belieben buttons und anzeige.

die methoden im model sind eindeutig und auch eindeutig benannt:
loadVideo() play() stop() usw. (vielleicht sogar playVideo() und stopVideo() usw.)

hier würde ein controller wenig sinn machen, denn er würde lediglich delegieren.

wenn es nun jedoch darum geht einen Mediaplayer zu realisieren, der sound, video und swf abspielt und unabhängig von abgespieltem Medium dieselben methoden wie play und stop usw bereitstellen soll sieht die sache schon anders aus.
die verschiedenen medien bzw. klassen erfordern für denselben effekt verschiedene befehle: video.pause(false) != sound.play()
und hier bekommt der Controller seine rolle zugewiesen.
zu entscheiden.

[MaticPel]

Also ich kenn es so, dass einfach zu jedem View auch ein Controller gehört.
Egal ob es nun ein spezieller oder ein DefaultController ist.

Dann bleibt man dem Prinzip treu, dass der View zwar etwas vom Model bekommt, aber dem Model nichts befiehlt, sondern den Controller beauftragt dem Model zu sagen was zu tun ist.

[malthoff]

Controller sind unter anderem dafür da, Programmlogik (wie Userinteraktion) aus
den Views heraus zuhalten, auch wenn danach im Grunde nur delegiert wird.

Wird der Aufbau der Applikation noch größer, bietet es sich außerdem an,
für unterschiedliche Fälle, unterschiedliche Kontroller zu haben - rein um die
Übersicht zu wahren. (bsp. ein MainController, der anhand von Bedingungen
an seine SubController weiterleitet).

Gerade, wenn mehr Leute an der Sache programmieren,ein entscheidender Vorteil.

Beispiel: Ein Illustrator ähnliches Tool, wo es für jeden
möglichen Modus (Drehen, Skalieren, Bewegen, etc) einen Controller gibt.
Da die Schnittstellen dazu in jedem Controller gleich aussahen (nicht nur
deswegen), konnte sich jeder Programmierer einen Modus programmieren.

gruß,
dr.ache