[Pixlib] rev30

Francis Bourre peterphonix at usa.net
Sat Mar 18 10:24:46 EST 2006


hello fluxs,

Model class aka ModelLocator has been introduced to be used with 
FrontController class and Command interfaces. it's not intended to be used 
with com.bourre.mvc package at a first glance.

- why is the Model's constructor private ?
coz its an abstract class, it's been made to be extended.

- how do you implement the FrontController pattern using pixlib ?
I tried to make for you the most basical example ever made. I hope u'll like 
it. comments or questions are welcome!
http://www.tweenpix.net/blog/files/FrontControllerExample.rar

francis

----- Original Message ----- 
From: "fluxs" <fluxs at free.fr>
To: <Pixlib at osflash.org>
Sent: Friday, March 17, 2006 6:59 PM
Subject: Re: [Pixlib] rev30


Hi Francis,

And thank you for your long answer.

I get it concerning the use of the getModel, but I don't see how you
would mix the core.Model with the mvc.AbstractModel. In the scheme that
you describes, when the model is modifyed by a command (using getModel)
and has to notify the views, you're more talking about an mvc model,
right ? But the getModel will only give you access to core.Models...

Ah I just checked inside the core.Model and realized that it implements
the mvc.IModel interface. So using core.Model in an mvc architecture is
possible ! OK. I suppose that this is not always true though, for
example when you just want to hold a set of data and have other objects
be notifyed when it changes, right ? (well, it sounds a lot like a
simple observer pattern ??!!).

I then only have two questions left :
- why is the Model's constructor private ?
- how do you implement the FrontController pattern using pixlib ?

Francis Bourre a écrit :

> hello fluxs !
>
>> But I think I'm too new both to pixlib and arp to really catch the
>> point : are we talking about the Model of the MVC pattern ?
>
>
> No, we're talking more genrically of data model concept, understand
> thematical information state.
> Example : titles of all your dvd collection stored in an object.
>
>> So why adding a new core.Model ?
>
>
> Because that's pretty cool with the FrontController pattern to have
> global access to all your data models.
>
>> Also, I don't get the point of the getModel method : it aims at
>> managing several Models and retrieving them. But I thought the many
>> implementations of the mvc pattern agree that there is only one model
>> (I'm far from having studyed them all though :-)... so why being able
>> to deal with several ones?
>
>
> MVC pattern deals with one model for many controllers/views, but in
> you application you can have many MVCs deployed.
> Example: Imagine an application with one MVC for each visual component.
>
> Let's get back to our FrontController pattern!
> Each event broadcasted in the application (by our global
> eventdispatcher) triggers an associated command.
>
> Imagine that we fill a textfield with a new dvd title that we'd like
> to add in our database.
> - When I press on 'record entry' button, I ask my global
> eventdispatcher to broadcast my request: "Hey guys, lemme add this new
> dvd title in my collection!".
>
> - When 'onAddDvdTitleEvent' event is dispatched, front-controller
> triggers registered AddDvd command instance.
> Let's imagine now that AddDvd command makes DB access to insert your
> new dvd title.
>
> - When the command has finished its execution it can uses
> Model.getModel to update your concerned data model (the same way that
> a standard controller would do in MVC implementation).
>
> - Your data model:DVDModel could now notify all the views about a new
> dvd title existence.
> So all your UI's could refresh with latest informations.
>
> You could repeat the same process with different models and different
> commands.
> Model.getModel helps you to get the model associated with each command.
> One command would need DVDModel, another one would need
> DVDPriceListing, another one would need ApplicationSettingsModel ...
>
> This whole design encourages low coupling beetween each part of the
> application.
>
> Hope that helps !
>
> francis
>
> ----- Original Message ----- From: "fluxs" <fluxs at free.fr>
> To: <Pixlib at osflash.org>
> Sent: Thursday, March 16, 2006 5:56 PM
> Subject: Re: [Pixlib] rev30
>
>
> Hi,
>
> The Model and ModelLocator are in the air... many threads are discussing
> them on the arp mailing-list :-)
>
> But I think I'm too new both to pixlib and arp to really catch the point
> : are we talking about the Model of the MVC pattern ? If so, there is
> already an mvc.AbstractModel class, and it mainly implements change
> event notification. So why adding a new core.Model ?
>
> Also, I don't get the point of the getModel method : it aims at managing
> several Models and retrieving them. But I thought the many
> implementations of the mvc pattern agree that there is only one model
> (I'm far from having studyed them all though :-)... so why being able to
> deal with several ones?
>
> So it seems we're not talking exactly about the mvc Model, what is the
> use of this other Model concept ?
>



_______________________________________________
Pixlib mailing list
Pixlib at osflash.org
http://osflash.org/mailman/listinfo/pixlib_osflash.org





More information about the Pixlib mailing list