[Codemonkey]

Okay

[Codemonkey]

This will take a while...

[Codemonkey]

Are you ready? Grab a coffee and a snack if you want.

[Codemonkey]

Here goes...

Originally posted by sentinels
err... any MVC i've ever worked with never had the controller updating anything. all the controller would do is handle requests from the view, create command objects to pass to a service, and potentially dispatch an event to inform any listening view(s) that the model has been updated once the service has returned a result. the delegate or command should be the object updating the model and informing the controller that the model has been updated.

That may be the case with Cairngorm, but you don't have to have command objects with MVC and you are describing one with a passive model as well, which is not what the gallery demo is about (for basics). You're still right tho.

Originally posted by Nutrox
I have been thinking about how a music player with a GUI would fit into MVC, and I was thinking about something like this:

PlayerModel (observable) - Contains the player's state, volume/pan, and play list data etc.

PlayerEngine (observer) - Contains and manages the actual Sound object.

PlayerUI (observer/view) - Contains and manages the GUI.

PlayerController (controller) - Handles the interaction feedback from PlayerUI and updates PlayerModel via command objects.

That's actually a pretty cool approach. I had to think about the PlayerEngine being an observer for a second, but I think it would work pretty well. It would not actually be a view, just an observer sitting next to the views, which is cool.

Originally posted by Nutrox
Oh, one more thing. Can a view only have one controller assigned to it

A view generally has only one controller, but this does not have to be the case. It also depends on how the controller is set up.

For example, the controller might just be an observer on all the view's controls and handle the events directly. Then you have a 1-on-1 relationship. This is a nested observer application where the controller acts as observer to catch interaction at the lowest level, or at least at the level where events are broadcast by the components/controls in the view.

Another setup is where the view acts as observer to its own components' events and filters which events are delegated to the controller and which events are handled by the views which then possibly results in some call to the controller. Here there does not have to be a 1-on-1 relationship, because the view can decide which controller to call upon for which event or action.

Keep in mind though that the view has no power over the controller; it doesn't create or remove a controller for itself. In classic MVC a view has a reference to a controller but only through an interface, which means the view won't know which implementation of the controller it has. You could for example replace a NormalGameController with a PausedGameController where most implemented methods actually don't do anything with the model (if the pause logic is not contained within the model itself but managed by the controller in the first place).

That said, a view might well have multiple controller references of interface types that all have their own responsibilities towards the model. There's no reason why you need only one controller which actually only receives very low cohesion.

Originally posted by Nutrox
or can a view watch multiple models?

A view can have multiple models from which they can draw information and receive updates from, because in its heart the model-view relationship is that of Observer. Is it advisable? Nothing against it and no convention here that I know of.

One thing to consider though is the fact that multiple models are not tailored with knowledge of each other; they can demand different kinds of treatment to get information from, through updates and sometimes you want to make sure they update the shared view coherently and consistently the same way. In addition, both models may overlap in the data being provided and you need to apply logic to sort out what information you want to keep from an update.

In such a case, I would consider creating an 'adapter model' (arbitrary term) that receives both kinds of updates and creates neat little filtered update packages and sends these to its own views (the real views). So:
"model 1 or 2 sends update"->"adapter model transforms and also sends update"->"views receive consistent updates from intermediate model"

This is only necessary in more extreme cases where you have existing views and models and you need to add a model or couple views to other models. In Enterprise environments this is an entirely possible scenario though.

Originally posted by Nutrox
I was thinking that instead of having getters/setters hardwired in a View you could create a special object which ( a ) encapsulates collections of related getters/setter, and ( b ) talks to the Controller in that same way a View does. That way the Model would still hold all of the data and the Controller would still be the only thing that updates the Model.

Is this making any sense, or am I completely crazy?

Not at all, it's actually a very descent approach and in fact you'll be proud to hear this is actually a design pattern of its own

Facade (more info)

Though the intention of the Facade pattern is to simplify some subsystem(s) into a simplified interface (access point), your intention isn't all that different: you simplify the system by collecting all setters/getters in one easily accessibly place (style). You simply added a set / get mechanism on top if it which is unique to flash.

It sounds perfectly fine to me.

Here's another scenario: Have the controller contain all these properties and setters/getters instead of the style object, and the MVC becomes a variation on the Supervising Controller/Presenter pattern

Originally posted by Nutrox
@CM

Another question regarding the way you have coded the MVC classes/interfaces: In your implementation of MVC you have things setup so that the View can only have one Model and one Controller added to it. In that situation, would it not be better to a getter/setter for the model and control references instead of using getModel() setModel() etc?

It's not clear to me what the best place is to actually wire the models with views with controllers (the binding phase) and whether this is a one time event or if this can be dynamically assigned variably in runtime.

That said, I'm not sure if it's a good idea to give views the power to fetch their own preferred model. That's because a view is 'plugged' into a model and after that only has a one-way line of communication. Having getters for models would give the view a different kind of role where they would already need some logic to determine which model to get (depending on how complex the environment is; multiple models and stuff).

To actually answer your question, you are right in assuming getModel() and setModel() are rudimentary and only applicable to a single model. As we determined earlier you can have multiple models (and controllers for that model) and they both should be able to be obtained by a view. So specific getters for all models? Then you would have getSoundModel(), getGameModel(), getStyleController() and so on. Or you could dump em in an associative array and fetch them by name (or some constant).

What I certainly wouldn't do without good reason is make the model a singleton. Models don't inherently have to be singletons, you could for example have multiple racecars on a track that are all encapsulated MVC-based components.

Originally posted by Nutrox
If you were allowing multiple Models to be added to a View then the use of addModel() removeModel() methods would obviously make sense, but I don't see the point of using getModel() setModel() when only one Model can be added to the View.

Is the use of getModel() and setModel() just something that has sneaked across from Java, or is that the 'normal' way to do things in MVC?

Not from Java, but from Moock's implementation of the Clock example in his book. In his version a controller can have only one view and model. and his observer version can only have one observable.

This makes sense for the simplistic academic exercise, but if you need to move on to more realistic real life applications of the MVC pattern you´ll often find yourself needing just a bit more in various places. And as you are now finding out, MVC allows for a multitude of tweaking.

Originally posted by Nutrox
How is this looking... 0-9-4.zip

The classes and interfaces don't have comments at the moment, but I have included documentation for them for quick viewing. It is based heavily on the framework Codemonkey uploaded.

The next step will be trying to base an MP3 player on that framework. I will upload that when it is working.

Looking good, but in the IController, I wouldn't make the model and view properties public. For that, I would use an abstract class to hide it away a little bit and make it visible only to subclasses.

On a side node, I like how you used identifiers for the Commands in the controller. One way of implementing the command objects then would be to construct/initialize them with a controller which they could register themselves with (in the model?). The same reference to the controller can also be used to reuse other commands and so create a chain of commands without the commands themselves know about it (the controller creates those commands after all).

- Cm.

PS. as long as you think my answers are coherent enough to follow, ask away

[Nutrox]

Great feedback as usual mate.

I will check out that supervising controller stuff, although I've only just got my head around the whole MVC and Command patterns so I might leave it for a while.

Regarding the IController interface, I do understand what you are saying there. My initial thought was that any controller implementing the interface would (afaik) need to allow public access to the to model and view properties anyway. I take it that isn't always the case then?

Oh, and I will throw a ModelAdaptor class into that code soon.
 

[Nutrox]

Originally posted by Codemonkey
...
On a side node, I like how you used identifiers for the Commands in the controller. One way of implementing the command objects then would be to construct/initialize them with a controller which they could register themselves with (in the model?).

The way that I intend to register the commands is within the controller. Here is an example:

package
{
    import com.neondust.core.Controller;
 
    import commands.CommandOne;
    import commands.CommandTwo;
 
    public class ExampleController extends Controller
    {
        public static const SOME_COMMAND:String = "someCommand";
        public static const ANOTHER_COMMAND:String = "anotherCommand";
 
        public function ExampleController()
        {
            addCommand( SOME_COMMAND, new CommandOne() );
            addCommand( ANOTHER_COMMAND, new CommandTwo() );
        }
    }
} 

The commands are then executed using something like this:

controller.executeCommand( controller.SOME_COMMAND, data ); 

I pinched the idea from Adobe's Cairngorm framework.

[Nutrox]

Here is an update... 0-9-5.zip

The methods sendError() and sendResult() have been added to the IService interface. You can see how they are used in the Service.as class if you are curious, but it a nutshell, they are helper methods.

I have also added a new interface, IFacade, and a new class, Facade. Facade is an observer and I decided that it can only have one Model and one Controller registered to it, unlike a View which can have multiple Models.

FYI: A Facade would be used for something like component style.* properties as we discussed up there^ somewhere.



Edit: 0-9-5 has been uploaded again and now contains DataObject, the existing interfaces and classes have been updated accordingly.
 

[Nutrox]

Would it be better to create an IInfoData interface or InfoData base class, and use that instead of an anonymous Object?

So instead of this:

function update( caller:IObservable, data:Object ):void 

You would have this:

function update( caller:IObservable, data:InfoData ):void 

Using Object just feels a bit too loose to me, unless of course the data should be able to be be sent as XML, Array, or anything else.

[sentinels]

i usually use value objects to pass data back and forth between my classes.

[Nutrox]

Originally posted by sentinels
i usually use value objects to pass data back and forth between my classes.

That does seem like a better thing to do IMO, Object is just too generic I think. I have created an abstract DataObject base class (aka value object).

[Nutrox]

@CM

I'm having a bit of trouble creating a ModelAdaptor class. I understand the theory, but I'm not sure how it would be constructed.

Any chance of a quick example?

Also, would the View need addAdaptor() and removeAdaptor() methods now?

[sentinels]

i don't think you'd need an abstract class for value objects. since these objects are generally specific to the data, you would normally pass the specific value object you need/request.

[Codemonkey]

Originally posted by Nutrox
Regarding the IController interface, I do understand what you are saying there. My initial thought was that any controller implementing the interface would (afaik) need to allow public access to the to model and view properties anyway. I take it that isn't always the case then?

Not sure about that, but it would mean a view is able to obtain a reference to the model through its controller... which it shouldn't be allowed to do (breaking the loose coupling that way).

Originally posted by Nutrox
Also, would the View need addAdaptor() and removeAdaptor() methods now?

It's not really an adapter to the view, rather just a model it relies on. The views also don't know there are actually other [multiple] models underneath it.

So to the views it is still addModel and removeModel, except it's a different model that happens to adapt other models to a certain interface (the interface being expressed through updates).
---

I'll get back to you about the rest tonight.

[Codemonkey]

Originally posted by Nutrox
Would it be better to create an IInfoData interface or InfoData base class, and use that instead of an anonymous Object?

So instead of this:

[...]

You would have this:

[...]

Using Object just feels a bit too loose to me, unless of course the data should be able to be besent as XML, Array, or anything else.

Yep, I've had the same issue with this and introduced a common interface for infoobjects. The problem here though is that if you do have multiple models, all their update notifications need to extend/implement that superclass, which means an interface can't be specific to a model or a model's update.

It's a good way to 'mark' an update object with a marker interface so that only objects with that interface are send in an update, but that's about it. There are no common functions other than metadata like 'update type' or statistical data like 'updates so far'. You'll always need to cast it to a specific type of infoobject. You can do that per type of update or you can define a generic update per model that contains all the properties of the model which are filled as necessary for the specific update (ie. only fill in currentImage if the update contains type UPDATE_LOADING_IMAGE).

The updates have always been a bit problematic, because you have a one-to-many relationship between a model its updates, and a view needs to distinguish between the various types of updates. So far I've done that by having all updates extend a baseclass that contains a bitflag with the update meta information (type of update).

[Nutrox]

Originally posted by Codemonkey
Not sure about that, but it would mean a view is able to obtain a reference to the model through its controller... which it shouldn't be allowed to do (breaking the loose coupling that way).

I'm confused now.

In your View interface you have public getModel, setModel, getControllers, and setController methods. In your Controller interface you have public getModel, setModel, getView, and setView methods.

Wouldn't those methods be just as accessible as getters/setters? Your View is still able to get a reference to the Model from the reference passed to it, or from the Controller (getModel is public).

The only way I can see around that would be to remove the get/set Model methods from the View, and remove the get/set View methods from the Controller, then register like this:

model.registerView( view )
view.registerController( controller )
controller.registerModel( model )

M->V->C->M->V->C->

That way the View cannot access it's model at all until/unless a model reference is passed to it via the update() method. In the same way, the Controller would not be able to access the View unless a reference was passed to it via it's executeCommand() method.

[Codemonkey]

Yup, these days I would probably do it like that as well. I just reused to view interface from Moock's book at the time. Today, I wouldn't apply the same approach.

[sentinels]

wha? that makes no sense to me. a model should not care about which view and/or controller is accessing it. the model should just be a class that receives results from a service, manipulates the data for the application, stores it and provides hooks (getters) to access it. the view should be notified when a result has been returned from a request (through the controller), then goes to the model to fetch the necessary data. all the controller acts as is a means for the view to send requests to and receives notification on service results. don't know why you would need any of the above methods, except maybe registerController, but even then i'd rather instantiate the controller directly and pass it a reference to my view. either that, or use a central event framework (like cairngorm does) and use specific events to register to specific requests.

[Codemonkey]

I don't understand why you hammer on these services so much, those have nothing to do with MVC itself, which is what this thread is about.

The controller in this situation acts as liason between the view and the model to pass on requests. The model then provides updates to the views.

Originally posted by sentinels
wha? that makes no sense to me. a model should not care about which view and/or controller is accessing it.

[..]

don't know why you would need any of the above methods, except maybe registerController, but even then i'd rather instantiate the controller directly and pass it a reference to my view.

Firstpart: I don't know why you think the model knows about its views, but the method is there to adhere to the Observer pattern. The views are listeners here.

Second part: Isn't that exactly what is going on?

[Nutrox]

I have to say that I don't see a problem doing things this way either.

Even though observers are being added to the model (observable) the model doesn't care what observers are added to it. When the model is updated it just rolls through it's list of observers and invokes the update() method in each one.

The view doesn't access the model directly, all update info is passed to the update() method when it is invoked by the model. That gives us the M->V (or Observer) pattern.

The same goes for the controller really. View doesn't care what controller is added to it, all View cares about is being able to invoked the controller's executeCommand() method which in turn does what is needed to update the model (using commands/services/whatever).

That is how I'm seeing things from a noob perspective anyway.

[Nutrox]

Here is another update: 0-9-6.zip
You can view the source files here.

How is it looking?

I'm structuring the classes in a way that I feel comfortable with now, so one or two things might look out of place from regular MVC frameworks.

[sentinels]

Originally posted by Codemonkey
I don't understand why you hammer on these services so much, those have nothing to do with MVC itself, which is what this thread is about.

'services' to me is a general term used to describe the fetching of data from either a flat file, xml, sql, wherever. at any rate, i should probably take a look at your original package before making further comments.

[Nutrox]

Another question.

I have been thinking about the neatest way to initialise a basic MVC setup, and have come to the conclusion that everything can be initialised nicely simply by passing a model reference to a view.

The way I understand things at the moment, a controller is designed to update a specific model (directly or via commands) and to handle events from a specific view. In other words, a controller knows which model it should update and it knows which view will be sending it events (if it didn't it would never be able to directly invoke methods in the view).

So with that in mind, the view could create an instance of the controller it needs when initialised, and it could set the controller's model reference when a model is passed to the view. An instance of the controller would not need to be created outside of the view.

var m:Model = new Model();
var v:View = new View();
v.setModel( m );
 
// ..OR..
 
var m:Model = new Model();
var v:View = new View( m ); 

The view's setModel() method will register the view with the model, and set the controller's model reference.

private var model:Model = null;
private var controller:Controller = null;
 
//
// Creates the controller and optionally
// sets the model.
//
public function View( m:Model=null )
{
    // View must be subclassed.
    if( Object(this).constructor == View )
    {
        throw new Error( "..." );
    }
 
    controller = new Controller();
    controller.view = this;
 
    setModel( m );
}
 
//
// Sets the view's model.
//
public final function setModel( m:Model ):void
{
    if( model != null )
    {
        model.removeView( this );
        model = null;
    }
 
    if( m != null )
    {
        model = m;
        model.addView( this );
    }
 
    controller.model = model;
}
 
//
// Allows the model to update the view.
// Needs to be overridden by a subclass.
//
function update( data:Object ):void
{}
 
//
// Allows the controller to be accessed by
// a subclass, and prevents the controller
// reference from being set by a subclass.
//
protected final function getController():Controller
{
    return controller;
} 

Is this a viable approach to MVC initialisation?

The model is kept private in the base view class because I'm not keen on the view (subclasses in this case) updating the model directly even though view->model updates seem to be allowed in MVC.

The model updates the view in the normal way via the model's updateViews() method (or notifyObservers). The view calls the controller in the normal way. The controller updates the model in the normal way.

// In a view
MyController(getController()).setMusicVolume( 0.5 ); 

Can anyone see any obvious problems doing things this way?

[Codemonkey]

Originally posted by Nutrox
Is this a viable approach to MVC initialisation?

There are some issues with this approach.

First, a view-controller relationship is not 1-on-1 per se. It can actually be a many-to-many, depending on the range of tasks that can be performed in your applications such that they might better be distributed over multiple controllers (promotes cohesion). So from a generic perspective, don't assume one controller per view or one view per controller. In your specific application ofcourse you are free to mold it somewhat. As a view can have multiple controllers, the same way one controller can have multiple views... like some sort of master controller. This again depends on the complexity of the view and the controller.

Second, a view can't determine its controller. It's exactly the opposite of decoupling behavior from the views; the view determines the behavior to some degree by creating its own controller instance. The view is dumb, a front end and a view and the controller should be plugged together by some entity that can decide on this (probably the neutral outsider application main class that created the model as well). You can see this done in the web gallery as well.

Again, as with any pattern these are not hard rules (it varies), but if you decide to narrow the MVC approach, you should know why and not just because it feels OK I guess.

Originally posted by Nutrox
updating the model directly even though view->model updates seem to be allowed in MVC.

That is *not* allowed. The reference to the model a view can obtain is only to retrieve values from. MVC is all about removing those connections and this is why I am not a fan of even a model reference just for information retrieval.

Originally posted by Nutrox

// In a view
MyController(getController()).setMusicVolume( 0.5 ); 

Can anyone see any obvious problems doing things this way?

That sounds about right if you ask me.

[Nutrox]

Thanks for the reply mate.

You have made some very good points, and I guess I would have restricted things quite a lot.

I was unaware that a controller could have multiple views. I knew multiple views could access a single controller, but I think I was thrown off a bit after seeing a few controllers that only allow one view reference to be added to them. Are view references in a controller really needed, or is it just required if the controller needs to access a view directly (that raises the question of storing multiple view references in a controller).

While I'm here... how do commands/services update a model, where do they get the model reference from? I'm thinking that the controller would pass it's model reference to the command/service, but I can't remember seeing that being done in any of the code I have seen.

[Codemonkey]

Originally posted by Nutrox
I was unaware that a controller could have multiple views. I knew multiple views could access a single controller, but I think I was thrown off a bit after seeing a few controllers that only allow one view reference to be added to them.

Well the opinions differ in this area a little bit. Some say a view should only have one controller and some say a controller should have only one view connected to it.

But I think they missed the point. MVC is about separating responsibility by introducing indirection between the model, representing/interacting views and the decision/glue logic in the controller. Add to that some of the classical benefits like that of the Controller actually being an application of the Strategy pattern (you can switch out controllers for views, although in practice you'll hardly ever encounter it) and the plugability of the views and you have the gist of MVC. In this context, it doesn't really matter how many views or controllers are connected; as long as these principles are maintained it's only a matter of logistics and guarding cohesion among these. Too many times I've seen GodClass controllers, because a view only had one of those and inflexibility, because a controller had access to only one specific view.

Originally posted by Nutrox
Are view references in a controller really needed, or is it just required if the controller needs to access a view directly (that raises the question of storing multiple view references in a controller).

If a controller has no need to access the view, then there's no need for the reference I think. It's not causing a balance shift in responsibility or visibility.

Originally posted by Nutrox
While I'm here... how do commands/services update a model, where do they get the model reference from? I'm thinking that the controller would pass it's model reference to the command/service, but I can't remember seeing that being done in any of the code I have seen.

Passing the model is a good way, either during construction or during execution. I mean, if the controller did it in the classical approach, why can't Command do it instead? You are still completely adhering/respecting the behavioral intention of the Command pattern. No violation in that regard I can think of.

If you look at the CairnGorm diagram you can see that the command is directly updating the model (the model is passive in the diagram) as well.

[Nutrox]

If anyone is interested, I think I have nearly finished my little framework and I have created a simple working example to demonstrate how it works. You can grab the example and source files from here.

There is no real reason to open up the example FLA file (it only contains library assets, no code) but if you do want to open it up you will need Flash CS3. You won't find many comments in the code at the moment either, but I will comment everything up and throw a couple more examples together some time during the week.

I would just like to thank Codemonkey for this top-tastic thread and example files. It has helped me to finally get my head around the whole MVC thing.

Thank-you monkey matey!

[Codemonkey]

I found it very interesting myself; first time I've put all these thoughts on paper. I have to admit I Googled some things up to verify my ideas and how the world thinks about these issues. You know how it goes

I hope more more people can use this stuff.

Originally posted by Nutrox
If anyone is interested, I think I have nearly finished my little framework and I have created a simple working example to demonstrate how it works. You can grab the example and source files from here.

I love that dataflow, did you use a tool for that perhaps?

In the Service class, perhaps I missed it, but who is handling the PENDING event. More accurately, who is cycling through the request queue one after another?

I would probably have made the Command class an interface that extends IResponder, since it only has abstract methods. This also takes care of the AS3 constructor issue.

Other than that, it looks amazing
I would dump the entire structure in a global library and per application extend/implement it.

[Nutrox]

Originally posted by Codemonkey
I love that dataflow, did you use a tool for that perhaps?

I just used Flash for that. I wasn't intending to include it in the ZIP initially because I think it is a bit pants, but I thought some of you guys might find it interesting.

Originally posted by Codemonkey
In the Service class, perhaps I missed it, but who is handling the PENDING event. More accurately, who is cycling through the request queue one after another?

The base Service class handles the request queue internally. It took me a while to decide how to implement that but it seems to be working as intended. What I will do is put together a little login or email example to show how that works.

The PENDING event is dispatched to the responder in the same way the RESULT and ERROR event is, it is just to let developers know if a service request has been queued. I may give developers the option to cancel the request if a PENDING event is dispatched.

Originally posted by Codemonkey
I would probably have made the Command class an interface that extends IResponder, since it only has abstract methods. This also takes care of the AS3 constructor issue.

Yep, you are right. I will sort that out.

Originally posted by Codemonkey
Other than that, it looks amazing
I would dump the entire structure in a global library and per application extend/implement it.

Thanks, mate.

[wraevn]

I just looked @ your base classes and example Nutrox. Very well done. It's so clean and readable ... I can see great potential in extending/building upon this framework.

Good on ya mate! And thanks for sharing.

[Nutrox]

Thanks mate. It is over at Google Code now if you want to keep tabs on it.

[wraevn]

I've finished rebuilding the original MVC Gallery in AS3 and adding all sorts of other stuff (webservice connectivity, multiple transitions, motion display, repositionable controls/thumbs etc.). I'll post a link to the final results when they go online. I'm sure I broke some MVC rules in the process, but it was a fantastic experience thanks to Codemonkey and this thread! I also learned AS3, so I've got that going for me ... which is nice

So now I'm on to developing an RIA ala Photoshop (user designs stuff, has text, images, shapes, layers palette, tool bar, options bar etc.)

I'm 99% sure I'm going to use Nutrox's Neondust framework as the base for the app ... but I'm having trouble wrapping my brain around what is what in the MVC.

The Models are pretty straight-forward (I think). But the Views and controllers, not so much.

Keep in mind I'm a Flash programmer via Bachelors Degrees in Vocal Performance, Theatre and Music Theory and Composition. Narry a computer course in site - just all seat-of-my-pants programming really.

Here is what I've been thinking so far, I'd appreciate any comments/help where appropriate:

MODEL 1: Department Model
Object containing parsed data from an XML regarding product(s) retrieved via WebServices (product = t-shirt, mug, sticker etc.)

MODEL 2: Product Model
Object containing configuration data about the selected/configured product (extracted from MODEL 1 based on user selects in VIEW 1/CONTROLLER 1)

MODEL 3: Design Model
Object containing data pertaining to the custom design.

VIEW 1: Product Configuration Screen
This is where you select the brand, color, size, shape, style etc. of your product (e.g. Large, White Fruit of the Loom Anvil T-Shirt w/ Black trim)

CONTROLLER 1: btns etc. for VIEW 1.

VIEW 2: Design Screen
This is where you create a design that will get printed onto the product you selected.
Consists of 4 SubViews:
     subview: Stage
     subview: Options Bar
     subview: Tools Bar
     subview: Layers Palette

Each subview has its own controller

_____________________

So:

1. The user launches the RIA. RIA retrieves a bunch of product data.

2. User interacts w/ CONTROLLER 1 to select and configure the product. The controller updates the Product Model (MODEL 2), which updates the appearance of the product in (VIEW 1).

3. User enters Design View.

4. User interacts w/ various controllers of the subviews to manipulate the design.
Subview controllers update the Design Model (MODEL 3) which notifies its observer (VIEW 2) which notifies its observers (all subviews) what was changed and each subview updates accordingly.

_____________________

Perhaps on a more general note ... do you guys have any methodologies/tools/resources for converting a functional spec and use-cases into class structures, design models etc.?

[Nutrox]

Codemonkey will be able to give you an insightful response to all of that. I'll post my initial thoughts though:

The first thing that caught my attention was this "MODEL 2 ... data extracted from MODEL 1" because, as far as I know, Models should be completely unaware of each other. What you could do is use a Command to call the XML data loading Service (the Service would also parse the XML and place the parsed data into a DTO), then once the DTO is passed back to the Command the Command updates MODEL 1 and MODEL 2 with the relevant information.

• The Controller executes the Command
• The Command calls the Service
• The Service loads and parses the XML
• The Service returns the parsed data to the Command
• The Command updates the Models

This isn't strictly related to your questions, but I'm starting to think that using a single Controller (i.e. a Front Controller) would make things a hell of a lot easier. Instead of passing zillions of Controller references around to zillions of Views and subViews, each View would simply dispatch an event and that event would be picked up by the Controller which in turn would execute the relevant Command. There is a good chance that I will updating the Neondust Base framework to work with a single Controller.

The question about software/tools is another one for the Codemonkey I think, I can't actually think of any at the moment.



PS: It would be great to see your AS3 version of the MVC Gallery.

[Codemonkey]

Originally posted by Nutrox
This isn't strictly related to your questions, but I'm starting to think that using a single Controller (i.e. a Front Controller) would make things a hell of a lot easier. Instead of passing zillions of Controller references around to zillions of Views and subViews, each View would simply dispatch an event and that event would be picked up by the Controller which in turn would execute the relevant Command. There is a good chance that I will updating the Neondust Base framework to work with a single Controller.

You're catching up fast Nutrox.

The FrontController was originally meant for Web applications I believe (through servlet) but registering the frontcontroller as listener to the view would be fine for any application. Or, just make all controllers listeners to the views (either to control events at the lowest level, or view-filtered events).

On a sidenote, you can leave out the dispatcher, since that is specifically for web application, for determining the next view (next page to go to). furthermore, you'll probably be looking at the 'Command and Controller Strategy' variety (on same page you posted).

One thing though. They don't mentioned it, but you can image a controller losing cohesion fast in this situation. For webpages this is still so, but less so because a web application inherently isn't as interaction intensive as a desktop application (and Flash by definition is such an application, even if it runs in the browser). So even though a single Front controller works for web application, you may need more for a classic application (like maybe just change current controllers to listeners).

Just venting my thoughts here...

Originally posted by wraevn
MODEL 1: Department Model
Object containing parsed data from an XML regarding product(s) retrieved via WebServices (product = t-shirt, mug, sticker etc.)

MODEL 2: Product Model
Object containing configuration data about the selected/configured product (extracted from MODEL 1 based on user selects in VIEW 1/CONTROLLER 1)

MODEL 3: Design Model

My first thought was, why three different models, where are you looking for that separation of responsibility, cohesion (seem to be using that word a lot lately)?

Then I realized you probably mixed up the concept of a model and domain layer and commands/service connection to this:

In your case, merge all models into 1 model, that provides all updates to the various views (foremost this will decrease complexity for updates a lot for you). Instead of three models you now should have a asingle model with three parts that together can be called the domain layer. Then with commands and/or services you can modify these domains (either directly or through the model).

Having separate models functionally works but is more cumbersome, while all you want to achieve by utilizing a Model (capital M) is the logistic aspect, the loosely couple communication with the views and controllers. you can achieve this with only a single model, while still keeping the three aspects of your application separated.

[edit]
Not saying you shouldn't have seperate models, because you perfectly can. Just make sure you don't confuse models with domains, of which there can be several in a model (and there often is). For example you can have a Car model that contains domains for Airco, Washing system and Sound system. In such a case the model containing those can actually act as a Facade for the Controller.
[/edit]

Originally posted by wraevn
Perhaps on a more general note ... do you guys have any methodologies/tools/resources for converting a functional spec and use-cases into class structures, design models etc.?

That is a very big question and many, many... many books are written about it. You should probably do some Googles and perhaps get a book on that subject. Meanwhile, keep an eye out for "Agile Developed" and "Extreme Programming". Both good concepts in my experience geared towards flexibility and minimal document requirements.

[Nutrox]

Originally posted by Codemonkey
...
So even though a single Front controller works for web application, you may need more for a classic application (like maybe just change current controllers to listeners).

So, a View dispatches an event, all Controllers receive that event and decide if they need to do anything in response to the event?

[Codemonkey]

It's possible but I'm not sure that is very practical (haven't really explored that option yet myself). Considering the FrontController was actually created for Java webapplications, take a look at how there can be multiple [front] controllers there:

@Core J2EE Patterns - Front Controller
While the Front Controller pattern suggests centralizing the handling of all requests, it does not limit the number of handlers in the system, as does a Singleton. An application may use multiple controllers in a system, each mapping to a set of distinct services.

In fact this is what you see with all popular MVC frameworks like Struts, Spring MVC, JSF and so on. What they do is configure with XML what URL request map to what Action or logic-executing-object for that URL (basically the URL request compares to function call on a controller). So often you see many controllers for actions (CRUD or otherwise) and often to care of navigation entirely (in the XML -or, navigation rules- you can define forwards for actions and/or form validations for success, failure and custom forward types). The important thing to notice here is that *not* all controllers are listening to all events: this is configured underwater by whatever mechanism the framework offers (some config XML most of the times).

So while you can have a Servlet Front Strategy, it is widely accepted that this it's not optimal per se; hence the MVC frameworks. In a desktop application I'd say you would do something similar, but a lot more programmatically: function calls on controllers instead of URL being mapped to actions. And controllers registered to specific views (just like an Action being mapped to for specific URL requests).

Instead of:

myView.setController(c);
 
// or 
 
function MyView(c) {
this.controller = c;
} 

You can have:

view.AddListener(c); 

Now a view never needs to concern itself with controllers, only to which degree it sends out events, whatever controller is listening to it. Even less tightly coupled and no masses of references to pass around.

[Nutrox]

The main problem I am encountering though is trying to implement static constants for the event/command types. I want to use static constants because it eliminates the possibility of a developer sending out invalid event types, thus avoiding hard-to-debug runtime errors.

View (want to avoid this)

dispatchEvent( "someEvent", data ); 

View (want to do this)

dispatchEvent( Controller.SOME_EVENT, data ); 

The way things are working at the moment, the Controller registers it's Commands using an ID, it makes those IDs available via static constants, and those IDs are used for the event types. The Controller can then use the event type to reference and execute the Command. Clean, simple, and very easy to manage.

The problem with this is that the View will need to know which Controller(s) it should be using. I don't have a problem doing things that way because it still conforms to the MVC data flow, but I imagine some people may frown on the idea.

Thoughts?

[Codemonkey]

Originally posted by Nutrox
The problem with this is that the View will need to know which Controller(s) it should be using. I don't have a problem doing things that way because it still conforms to the MVC data flow, but I imagine some people may frown on the idea.

Well, it's a tricky one but the real issue isn't that the views need to consult the controllers which event they should use, the real issue is that the views should define these in the first place.

The views define the events and to what degree they handle these themselves and in this train of thought: the controllers are the 'steers' the views use to drive the model. What you did now is define controller centric events, while these should be view centric. Once you have the latter situation, it's easy to have controllers as viewlisteners. Another way of saying the same is: the view defines the interaction boundaries and thereby the possible events; the controllers are just there to be utilized by the view(s). The fact that the controller handles this with Commands is unrelated to the event in itself. Adding that 1-on-1 event-command constraint is almost hampering the loosely coupled nature of the view-controller relationship.

Ofcourse you can look at it from both sides. The controller can offer certain functionality and the views just have to accept that and use its constants to actually utilize that functionality. The idiom though is that the controllers are there to support the views, the interaction a user can have with the application [through the views].

Originally posted by Nutrox
The main problem I am encountering though is trying to implement static constants for the event/command types. I want to use static constants because it eliminates the possibility of a developer sending out invalid event types, thus avoiding hard-to-debug runtime errors.

Yes I've had such days of looking

So OK, if you want use static constants.... just don't put them in the controller if you don't intent on a 1-on-1 view-controller relationship (since they are view centric). Then would it work for you to have Controllers decide on the Commands based on the view-event type received, listeners or not?

I know you now have this neat associative array of events mapped to Commands, but doing that actually makes the controller superfluous because you already moved all the logic to the Commands and now also the events-to-commands glue has become what might as well have been some static constant (no decision logic required). See this view centric event translation to the right chain of Commands is what the Controller is supposed to do...

[edit]
Maybe you can still maintain the associative arrays, except populate it with events from the various views to the right commands. Then register the controllers with the specific views for the events they can handle (so all controllers that can handle an event from a view would be registered with it).
[/edit]

[Nutrox]

Hmm, I'm going to have to think about this then. I'm not really worried about sticking rigidly to MVC or sacrificing some flexibility if it means I can make the framework easier to use and easier to extend/implement. I seem to be going around in circles here so I think it would be better if the framework was based on and around MVC rather than trying to make it confirm strictly to MVC.

Anyway, I will let you know how it goes.

[Codemonkey]

While I'm preaching along, I've updated the 1st post with a reference to your Google project. I'm still waiting for wraevn's contribution

[wraevn]

Here ya go - an AS3 port of the original MVC Gallery

AS3 MVC Gallery

Now, this one doesn't have all my mods (transitions, motion display, multi-image display etc.). If I posted that I'd get fired). This is almost just like the original gallery (look, images et al) but in AS3.

Please be kind as this was my very first attempt at AS3 and was learning as I went.

At some point I replaced the slider w/ the new CS3 slider component (can't remember why).

I also renamed some things, changed some background colors here and there during testing etc.

I also started using Uza's AS3 Easing class, but I honestly can't remember if that's even implemented in this version - but it's included nevertheless. I think I'm still using EnterFrame events as in the orig. AS2 version.

Oh - and I don't think I commented much of anything. Sorry

Enjoy all!