[Pixlib] interface changes

[dev@binarycrafts.com]

It's super interesting.
After Xavier pointed out that commands should handle cosmetic changes (
those who don't change models) I saw some light :)
My mantra for this week is:
If you need to make a mess, do it inside very specific commands. After all
the controllers are supposed to be the disposable part of your app.
So inside each command I decide what to do with my models and views. I try
to keep these last two as encapsulated as possible.
So the baseline would be that I keep ui layout decisions inside the
commands. Ok, I might have a layout manager with layout changing methods
but I call those from commands cause that's where the action is and in
each one I know pretty much what needs to happen next.

And inside commands I get my views using the ViewList ike this:
var b : AdBubble = AdBubble( MovieClipHelper.getMovieClipHelper(
ViewList.VIEW_AD_BUBBLE ) );

So far so good but if you guys think different pls correct me.


> I see what you mean Xavier, about updating the view with the Command when
> the Model does not change state.  Good idea.
> I think I haven't had an opportunity to do that because I usually put most
> of the functionality of my view in a separate class defined by an
> interface,
> and then access that API with my UI.  So in cases where I am updating the
> view for cosmetic reasons only, I'm usually doing it directly from the UI.
> I'm not sure it is the best way - it works good for me because I'm working
> with teams and this allows me to disperse views to various team members in
> other cities, and they are not dependant on any of my code.  Also when I
> get
> their piece back, I can either use it's methods, or I can choose to use my
> own methods in the UI (in case there is some problem with their method).
> Anyway, I'm going to try out updating the view from the Command as you
> suggest on my own project.  Do you use the 'target' property of the event
> received by the Command to know what view it is updating?
>
> For the 'backController' idea, it's something I was thinking about for the
> same reasons as the frontController - to eliminate redundant code, and
> better mapping of the event flow.
> So maybe such an idea would apply when I have several views, all of which
> have some very simillar methods in them.  Of course, I could have all
> these
> views inherit from a class...but what I was thinking of was to remove that
> method to a Command, and use that one Command to update a list of views.
> I
> have to think about it more....I'm rather tired, fighting a cold :(
>
> Anyway, sorry for going off on another direction guys!  But it's
> interesting
> I think...
>
> -tim.
>
>
> On 3/13/07, Xavier MARTIN <zeflasher at gmail.com> wrote:
>>
>> Hello tim,
>> yeah I'm updating the views from the command.
>> The model updates the views only if data from the model are needed.
>> Check the graphic on the first tut I've done...
>>
>> I don't get the point of the backController. All the views are already
>> listening to the model...
>>
>> Could you be more precise or give an example that really need this kind
>> of
>> structure?
>>
>> 2007/3/14, Tim Will <thedigitalartist at gmail.com >:
>> >
>> > So do you use Commands for updating views as well as Models Xavier?
>> > That's interesting to me.
>> > Up to now, I only updated views by 'pushing' data to them with an
>> event
>> > from the Model (but in my old framework, I used to do a more mx-style
>> where
>> > the Model would broadcast, then the view would 'pull' the data from
>> the
>> > model, using the 'target' property of the event).
>> > Anyway, lately I was thinking about something like a 'backController'
>> > that would be used to map events from the model to Commands that
>> updated
>> > views....do you think this is a valid idea?
>> >
>> > -tim.
>> >
>> >
>> >  On 3/12/07, Xavier MARTIN <zeflasher at gmail.com > wrote:
>> > >
>> > > If you really need to keep tracks of the actual position of the
>> views,
>> > > yeah put the info in the model.
>> > > Then in a command I will retreive those info hold by the model.
>> > > Then depending of those info act as needed on the views...
>> > >
>> > > 2007/3/13, dev at binarycrafts.com < dev at binarycrafts.com>:
>> > > >
>> > > > I have an application that has several main views that can change
>> > > > size and
>> > > > position depending on the user interaction.
>> > > > Where would you put the logic for reconfiguring the layout of the
>> > > > stage?
>> > > > In a central model dedicated to keeping all the info for the
>> layout
>> > > > state
>> > > > and updated by the commands. Or in the commands themselves?
>> > > > What do you guys think?
>> > > >
>> > > > _______________________________________________
>> > > > Pixlib mailing list
>> > > > Pixlib at osflash.org
>> > > > http://osflash.org/mailman/listinfo/pixlib_osflash.org
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > ----------------------------------------------------------------------
>> > >
>> > > Xavier MARTIN aka zeflasher or xxlm
>> > > Visit my website if you love flash:
>> > > http://www.webbymx.net
>> > > http://dev.webbymx.net
>> > > ----------------------------------------------------------------------
>> > >
>> > > _______________________________________________
>> > > Pixlib mailing list
>> > > Pixlib at osflash.org
>> > > http://osflash.org/mailman/listinfo/pixlib_osflash.org
>> > >
>> > >
>> >
>> > _______________________________________________
>> > Pixlib mailing list
>> > Pixlib at osflash.org
>> > http://osflash.org/mailman/listinfo/pixlib_osflash.org
>> >
>> >
>>
>>
>> --
>> ----------------------------------------------------------------------
>> Xavier MARTIN aka zeflasher or xxlm
>> Visit my website if you love flash:
>> http://www.webbymx.net
>> http://dev.webbymx.net
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Pixlib mailing list
>> Pixlib at osflash.org
>> http://osflash.org/mailman/listinfo/pixlib_osflash.org
>>
>>
> _______________________________________________
> Pixlib mailing list
> Pixlib at osflash.org
> http://osflash.org/mailman/listinfo/pixlib_osflash.org
>