That actually makes a lot of sense to me and I haven't written one MVC
yet.
Thanks for the break-down!
In relation to what Henrik said about using adaptors,
I see the sub controllers as the adaptors, but they are not actually
adaptors, just sub controllers with targets to the main controller.
Yes?
Best,
Karl
On Feb 27, 2012, at 1:16 AM, Ross Sclafani wrote:
thanks, its just how i do MVC
it really get interesting when you follow a mitosis development
pattern... You start with one model, controller, and view, add
features to each in parallel, and as each class gets too big, you
break them out into subcontrollers, submodels, and subviews. Then
sub-sub. My projects have a triple-tree structure branching out from
the core model, controller, and view classes
finer granularity as you reach further in, and always broken into M,
V, and C:
Models contain properties only. they dispatch a CHANGE Event every
time one of their properties change,.
Views display properties of the model. they listen for the CHANGE
Event, and update their appearance with the new values stored in the
model every time it changes.
Controllers manipulate properties of the model. Whether trigger by
event handlers in the views, or internal timers or network activity,
any command that sets any value of any property of the model is
placed in a controller. Controllers might use other controllers to
trigger changes in submodels outside its subdomain
the project starts off very compact, then grows with its
functionality as required, always growing out from the center so you
never paint yourself into a corner
then later to optimize, you can get specific about which submodel a
particular view is listening to, in turn limiting the number of
change events it receives to those actually represented in the view.
all subcontrollers hold a reference to the root controller, so it is
easy to target any node on the controller tree from anywhere inside
of it.
same with the model tree. some submodel properties can emit the
CHANGE Event only on a local level, and not send the event up the
hierarchy, isolating the scope of view updates
An MVC Example
FLVPlayback is an interesting MVC component:
it holds a NetStream as a model of the video
it holds a Video as a view of the Video
It acts as controller to set the model in motion by connecting it to
a stream
the ui is also a view of the video: the percent elapsed is
represented n the scrub bar, ther is a play button while paused, a
pause button while playing, then there are the time readouts..
if the video its playing,
the user clicks pause in the view,
it tells the controller to pause the stream in the model,
which notifies the views, so the Video is paused, and pause button
becomes a play button.
thats how i do MVC.
data is stored in mvc.models,
data is displayed in mvc.views, and
data is manipulated in mvc.controllers.
Ross P. Sclafani
design / technology / creative
http://ross.sclafani.net
http://www.twitter.com/rosssclafani
http://www.linkedin.com/in/rosssclafani
[347] 204.5714
On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote:
BTW Ross, I thought your example was great.
Karl DeSaulniers
Design Drumm
http://designdrumm.com
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Karl DeSaulniers
Design Drumm
http://designdrumm.com
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
