[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 compon