[Pixlib] PixLib MVC, where should Key triggers go?

[Tim Will]

Ya, I totally agree with Xavier there.
It is useful to realize that with Frontcontroller, you are essentially
breaking your Controller into many smaller bit of logic held in Commands.
This is useful because you can eliminate a lot of code redundancy, and the
flow is easier to follow.
So lets say in your example you have two views
-1. The key listener view
-2. The photogallery view
If the key listener view is listening for, say, the arrow keys
(back/forward), when the arrow key is hit, this view would send an event of
type "keyHit".  Because you can make custom events by extending BasicEvent,
you might have one that has a setKeyType() method.  You can use this to
setKeyType("forward");
Since the "keyHit" event is mapped to a Command in the FrontController, the
Command is called.  Let's call it the "NewPhotoCommand".  This Command has
an execute() function that gets passed the "keyHit" event by the event
broadcaster.
Now that the NewPhotoCommand has the event, it can call the getKeyType()
method on the event, which returns our value, "forward".
This is where the logic of the Command comes in.  Since the value from the
event is "forward", the Command uses the modelLocator to retrieve the
"PhotoModel" and call it's setCurrentPicture() method, passing in a "1" for
an argument (we want to move ahead one in the list of photos available).  If
the value from the event had been "back" we would have passed a "-1" to the
setCurrentPicture() method of the model.
Models do only three things really: set data, retrieve data, and sometimes
validate data.
When our Model's setCurrentPicture() is called, it will likely look at it's
_currentPicture value, and see if it is valid to increase it by one - are
there more pictures in the list?  Since it sees this is a valid data change,
it now increases the _currentPicture value, and sends out a broadcast event
, say of type "pictureChange" (again, the event will have a type, and can
have methods to set and retrieve data - in many ways, an event is like a
little temporary model, whose lifespan expires once it reaches the
listener).
Now our second view, the "photogallery" view, hears the broadcast from the
model.  It will retrieve a value from the event broadcast by the model, in
order to update it's graphics.  This might involve loading in an image, or
any other number of actions it could take.
So in short, the command is applying logic to the user gesture, the Model is
setting and retrieving data, and the view is reflecting the state of the
model.
Really not so different from the MVC you might be used to, just a little bit
more modular.

Hope this is helpful,
-tim.

On 3/9/07, Xavier MARTIN <zeflasher at gmail.com> wrote:
>
> Seems good for me...
> Except that you could pass an object to your command with the photo IDs
> already in the view...
> Maybe as well you could have all the ids of the photos used, in the model,
> as your checking the directory to see if there is new photos, you will then
> update the array / object / map, in your model, holding the photos id, then
> you will send it to the view...
>
>
> 2007/3/10, Jon Bennett <jmbennett at gmail.com>:
> >
> > Hi Tim,
> >
> > > I would definitely put them in a view!  Use the view to trap the key
> > input -
> > > but don't do any logic there.
> >
> > ok
> >
> > > You want to keep the logic separate from the
> > > user interaction.  So, if the response to the user gesture is just a
> > > cosmetic one, and no model needs to be updated, you can have a simple
> > > control matched to the view (a good example might be a rollover - it's
> > just
> > > a simple animation change, and no other view or model needs to be
> > informed).
> >
> > sure
> >
> > > But if the key press triggers any kind of data change - this is where
> > you
> > > will follow your event/frontcontroller/command/model flow.
> > > It's important to keep in mind two things:
> > > -views are not just for graphics, anything that results in a model
> > needing
> > > to change should originate at a view
> > > -to the application, the user is just another model :)  Who do models
> > 'talk'
> > > to?  Only views....
> >
> > ok, I think things are starting to get clearer now - i was concerned
> > before as I have a lot of code in my view, and my previous experience
> > has meant putting more code in my controller, often triggering
> > different views based on the action that's been called in the
> > controller.
> >
> > so to clarify, say I have a simple app to display a series of photos,
> > I would have the following:
> >
> > // Commands
> > ShowPhoto( dir ):
> > - gets photo data from view
> > - checks model ID and data to see if another photo exists (based on DIR)
> > - if another photo is there, set ID of model (for persistenace) and
> > call the action on the model to update the View
> >
> > // Model
> > setID()
> > - sets current photo id
> > getData();
> > - gets dataset
> > showPhoto()
> > - passes data (based on ID) to view to show new photo
> >
> > or should most of the above code be in the model, with the
> > Command.ShowPhoto() merely calling the Model's ShowPhoto method?
> >
> > sorry if the above isn't overly clear!
> >
> > I'm trying to adjust to the MVCC pattern, I'm used to the body of the
> > code happening in the Controller, which i think is why I'm leaning to
> > putting my logic in the Commands above (in the first example).
> >
> > thanks,
> >
> > Jon
> >
> >
> > --
> >
> >
> > jon bennett
> > t: +44 (0) 1225 341 039 w: http://www.jben.net/
> > iChat (AIM): jbendotnet Skype: jon-bennett
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/pixlib_osflash.org/attachments/20070309/67091e88/attachment-0001.htm