[wraevn]

Sorry - just wanted to be the 200th post here ... I'm such a whore.

[edit]
ooh - and the 6th page as well!
[/edit]

[Nutrox]

After a wee bit of thinking I have decided to let developers choose if they want to implement static constants (for the event types) into the framework. I won't try to enforce static constants into the framework except for BaseModel.EVENT_UPDATE which is the default event type dispatched from Models.

I'm not going to try and do anything fancy with Model/Controller references either, again, developers can always customise the framework if they want to adjust the way certain things work.

By default, Controllers are added to Views, and Views are added to Models. This is essentially the Observer pattern but the pattern isn't enforced using IObserver and IObservable interfaces.

model = ModelLocator.getInstance().getModel( "id" );
view = new View();
controller = new Controller();
 
model.addView( view );
view.addController( controller ); 

modelA = ModelLocator.getInstance().getModel( "idA" );
modelB = ModelLocator.getInstance().getModel( "idB" );
viewA = new ViewA();
viewB = new ViewB();
viewC = new ViewC();
controllerA = new ControllerA();
controllerB = new ControllerB();
 
modelA.addView( viewA );
modelB.addView( viewB );
modelB.addView( viewC );
 
viewA.addController( controllerA );
viewB.addController( controllerA );
viewC.addController( controllerB ); 

...and so on.

I will be sticking with the way the Controller registers and executes Commands. The Controller receives an event and executes a Command based on the type of event. In a nutshell, the Controller is dumb, all of the logic required to update Models is contained within Commands. Commands know which Model(s) they need to update (references are obtained via the ModelLocator), and they can call upon Services (using the ServiceLocator) in the usual way.

M » V » C » CMD » [SRV » CMD »] M
 

[Nutrox]

Originally posted by wraevn
Here ya go - an AS3 port of the original MVC Gallery

AS3 MVC Gallery

It is looking very good mate. I have only skimmed over the classes but I will take a proper look at everything shortly.

I'm not sure if this is a bug or not, but the images seemed to enter a "slide show" mode of some kind and I couldn't stop it, and I'm not sure how I started it either.

Good work though. It looks like you are getting to grips with AS3 very quickly.

[wraevn]

The little button in the upper-middle starts slideshow mode ... can't recall if there's a way to stop it ... the lower-middle starts random slideshow mode. Should be the same as the AS2 gallery.

[wraevn]

Okay ... I think I might be starting to get a grip on things here ...

I've created a UML diagram of my RIA based on Nutrox's Neondust framework HERE

If you want to be able to load it into gModeler, HERE is the XML you'll need.

Codemonkey - Nutrox - et al ... could you have a gander and see if I'm on the right track? I may have some association relationships mixed up (I struggle w/ associations) but I think you'll get the idea.

Based on advice from previous posts I have:

1 Model which will contain all data, divided into 3 sections: Department, Product and Design. Model has 2 views: ProductConfig and Design.

1 View, which serves as the base class for many views. View has a Controller.

1 Controller to handle everything

The Design view has a Stage view, ToolBar view, PricingPalette view, LayersPalette view and an OptionsBar view, all of which extend View.

The LayersPalette view has ClipArtTab, StockArtTab and UserArtTab views, all of which extend LayersPalette.

The OptionsBar view has TextOptions, ImageOptions, ShapeOptions and ExtrasOpptions views, all of which extend OptionsBar.

... reading what I've got above, perhaps should not the Model have View, not ProductConfig and Design? Other thoughts?

[Codemonkey]

Originally posted by wraevn
Codemonkey - Nutrox - et al ... could you have a gander and see if I'm on the right track? I may have some association relationships mixed up (I struggle w/ associations) but I think you'll get the idea.

I can't spot anything wrong with it at a glance. You have a fine grained view structure though... are all those components views for your model? What events are they listening to (like disableControlls etc?).

Originally posted by wraevn
Based on advice from previous posts I have:

[..]

... reading what I've got above, perhaps should not the Model have View, not ProductConfig and Design? Other thoughts?

That's all looking good. I just didn't get that last sentence there...

[Codemonkey]

Originally posted by Nutrox
I will be sticking with the way the Controller registers and executes Commands. The Controller receives an event and executes a Command based on the type of event.

How are the events mapped to the right chain of commands, if the user decides to not use controller centric events? In other words, when the events->commands aren't mapped 1-on-1 in some associative array...

[wraevn]

So my thoughts went like this:

When you're configuring a product, you see ProductConfig view. You update the data, other stuff in the view changes, etc.

Then you switch to Design View (so ProductConfig/Design is a toggle).

The Design view is comprised of many different views depending on the state of the design/product/tool selected/layer selected etc.

All the data the view needs is in the Design portion of the Model.

The OptionsBar view for example hosts the generic functions all OptionsBars will need. The TextOptions therefore view will be listening for when a text layer or text object has been selected. Then it can toggle on and others can toggle off.

Basically, I've divided the Design screen into managable components, each of which contains UI elements and interactive elements that alter the view-state of the entire Design. This way, it's more easily skinable, adaptable and extensible.

[Codemonkey]

Here's a heads up for a very nice MVC framework, pureMVC. It deals in MVC a little bit like in our discussions here, and takes the separation issue a bit further. It's been put up there with cairnGorm et all.

Commands I'm a big fan of. Mediators I'm not sure (a Mediator is basically the view with the UI->Controller interaction seperated in a different class). One thing I'm not ready to accept is the need to put proxies in between the model and the mediators/commands. Apparently what they accomplish is a modularized business model consisting entirely of proxies that each govern their own interaction and notifications. It seems to me that it only unnecessarily bloats the model by a couple of factors.

Interesting enough though. Take a look at this pureMVC diagram as well.

[mindtwitch]

Sorry if this questions has already been asked and answered I've gone through the thread and didn't see anything related.

I'm using the original MVC sample files and have modified the AbstractView and AbstractController files to use accessors instead of straight methods (ie: getSomething()). Examples are below of changed files.

What I am having trouble with is I'm getting one Error on compile that I can't figure out. On the line in AbstractView controller.view = this in the set controller accessor, I am getting an error saying view is not a property. I was wondering if this is because of the changes I made to the IController and IView interfaces which are now empty since I don't use any of those methods now.

Any insight or help on this matter would be greatly appreciated.

Also, probably obvious but I am working in AS2. - Thanks - mt

Here are the changes I've made.

AbstractController.as

import patterns.mvc.*;
import patterns.observer.*;
 
class patterns.mvc.AbstractController implements IController
{
    private var _model:Observable;
    private var _view:IView;
    
    
    public function AbstractController(m:Observable) {
        // Set the model.
        trace("AbstractController");
        model = m;
    }
    
    
    //////////////////////////////
    // ACCESSORS
    //////////////////////////////
    public function set model( m:Observable ):Void
    {
        _model = m;
    }
    
    public function get model():Observable
    {
        return _model;
    }
    
    public function set view( v:IView ):Void
    {
        _view = v;
    }
    
    public function get view():IView
    {
        return _view;
    }
    
    
    
} 

AbstractView.as

import utils.error.AbstractError;
import patterns.mvc.*;
import patterns.observer.*;
 
class patterns.mvc.AbstractView implements IObserver, IView
{
    
    private var _model:Observable;
    private var _controller:IController;
    
    
    public function AbstractView( m:Observable, c:IController )
    {
        model = m;
        
        if(c !== undefined)
        {
            controller = c;
        }
    }
    
    /**
     * A do-nothing implementation of the Observer interface's
     * update() method. Subclasses of AbstractView will provide
     * a concrete implementation for this method.
     */
    public function update(o:Observable, infoObj:Object):Void
    {
        throw new AbstractError("update");
    }
    
    
    ///////////////////////////////////////////////
    // ACCESSORS
    ///////////////////////////////////////////////
    
    
    //////////////
    // MODEL
    public function set model( m:Observable ):Void
    {
        _model = m;
    }
    
    public function get model():Observable
    {
        return _model;
    }
    
    
    //////////////
    // CONTROLLER
    public function set controller( c:IController ):Void
    {
        _controller = c;
        controller.view = this;
    }
    
    public function get controller():IController
    {
        if( _controller === undefined )
        {
            controller = defaultController;
        }
        
        return _controller;
    }
    
    public function get defaultController():IController
    {
        return null;
    }
    
    
    
} 

[Codemonkey]

Hey twitch, IController doesn't have those methods, so the flash compiler doesn't recognize them. Either add the methods to the interface or cast IController as AbstractController.

AbstractController(controller).view = this; 

But I wouldn't do this, since you already have an interface, it wouldn't make sense to not add these methods to it...

[mindtwitch]

I was wondering if I could just cast to Abstract since IController is empty. There are no method definitions in the interface at all. I can't add accessor methods to the Interface can I? I've tried before and it returns errors.

Thanks for the tip. I might just scratch the interface all together since it doesn't seem that I really need it. However I do question whether this goes against OOP principles of coding to an interface instead of an implementation. Just seems weird to me that you can't define properties/accessors in the interface. Or can you?

[Codemonkey]

it's because setters/getters with set and get appear as properties to the outside world, not actually an interface. The fact they are really are methods is not guaranteed to the outside world, hence you can't add those kind of setters/getters to an interface.

In your case you might as wel remove the interface itself, since you also have an AbstractController, which really also defines an interface.

[mindtwitch]

Awesome, thanks a ton. Both for your help here and for starting this thread. It's a great resource.

[mindtwitch]

One more question, but probably not the last.

I'm creating a template system where there are various components (not Flash Components, just various movieClips in the library). I think I've got everything straightened out for the TemplateModel to load/parse/prepare the template file and then pass it to the TemplateView to do it's magic. Where I'm having a bit of trouble with flow is for the components.

In my mind each component should have it's own MVC as well, no problem here. Where I'm getting stuck is I need those components to talk back to the Template system to let it know when the component has been loaded, added and processing is complete etc. Where is the hook back into the Template MVC, is it through the TemplateController or directly back to the TemplateModel? Or should the ComponentController notify through the Observer? In turn the TemplateModel should be able to notify each component of any changes as well, style and layout changes etc. I'm sure the TemplateView handles notifying the Components.

Any insight and/or guidance would be greatly appreciated.

Thanks,
-mt

[Codemonkey]

Going on the information you provided:

You're right, each component would have its own MVC model. All Flash components actually have this, although a slightly different variant (where the controller/view is merged).

To keep things simple (relatively) between multiple components and a central templating mvc system, I probably wouldn't bother trying to keep track of the template model in the component controller or some other coupling like that. Instead, I would probably have the component controller registered as simple listener to the template model and have neutral 'events' like styleChange.

If you are still going the coupled model way (template/component), that's fine, just use the template controller inside the component controller. Remember, the controller is the operator of the machine (model). Since the component itself is somewhat of an observer of the template model like a view, it would propagate action's to the template model's controller. Talking from operator to operator so to speak. Have each controller operate on their own level: component controller on component management and template controller on template system management.

But as I said, I probably wouldn't do that, since that means the component controller needs to have knowledge of the templating's operation manager, the controller. With a neutral event based updating mechanism, I'd use simple listeners (both ways perhaps) to keep things decoupled and clean and simple. Doing this would also mean you could use the component completely outside of the templating system, using the right events.

I hope that made some sense.

[mindtwitch]

Seems to make sense but I may have to read it a couple more times. I like the idea of using simple events, would this be through the Observer to send out notifications? Everything does need to be decoupled in that the template system simply parses an XML template file that is then used by the view to place each component with properties etc. But the idea is that the components could also be used seperately if a developer wanted to leverage them via Actionscript. There definately needs to be a two way communication though where the templateSystem knows when a component has been loaded and is available etc. There is also targeting where a playButton (MediaControl) targets a component that can be played (ie: Video, AudioPlayer, PhotoSlideShow etc.)

It could be possible that once I dive into this more I will find that this may not be necessary though since I am trying to refactor some existing code and seperate everything out nicely.

As always, many thanks to you for the detailed explanation and help.

- mt

[osiris22usa]

thanks for the insight guys. i use this thread as a refresher when i'm feeling a little forgetful. thanks mang.

[Pop-Shock]

Hi CodeMonkey, Nutrox, et al,

Im just starting on my journey into MVC using AS2, (Im stuck with AS2 for now with Flash Lite.)

I was wondering how you go about visualising an MVC project, especially large UI applications, before you start programming? Obviously I need to look at the visual elements in the application, how the user interacts with them, and what is displayed back to the user once they have interacted. But I cant seem to grasp where in the MVC pattern all these things go!

Do you have any tips and tricks to get a large MVC project started?