Hi Sebastian,
you answered my question, since I'm pretty new to Cairngorm, I just
wanted to make sure it's appropriate to host in the model object that
actually performs actions and don't just represents values derived
from actions performed by commands...
I think you answered my question, thanks then !

Almog Kurtser.

--- In flexcoders@yahoogroups.com, "Sebastian Zarzycki" <[EMAIL PROTECTED]>
wrote:
>
> I'm not really sure what you are asking about. If it's about whether
you are
> "allowed" to store state of your application in your model, then the
answer
> would be - of course! State is model as well! I've built several
> applications, where among various VO objects that came from server,
I have
> my own model, sometimes built around those VO's, but sometimes just
purely
> related to UI logic, that is state of my application. I would just
have one
> variable inside your SoundPlayer of the same type even
(SoundTrackVO), or
> plain boolean if you wish - currentTrack, isPlaying, etc. depending
on how
> much data you need about current song - this variable would be set as a
> result of .play() method, and nullified as a result of .stop()
method. Now
> commands just don't care, they just execute external functionality,
asking
> SoundPlayer to either play or stop, passing the parameters, they've
received
> from events. SoundPlayer, within .play() method (or you can refactor
it even
> and extract to new method), checks, whether currentTrack != null. If so,
> then go with .stop() first before playing new one.
> 
> Hope this helps.
> 
> Sebastian
> 
> 
> -----Original Message-----
> From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
> Behalf Of mydarkspoon
> Sent: Saturday, December 22, 2007 11:28 PM
> To: flexcoders@yahoogroups.com
> Subject: [flexcoders] Simple Cairngorm and State Pattern - design
thoughts.
> 
> Hello,
> 
> I'm adding some functionality to a Cairngorm app, I want to enable the
> user to select an audio clip from a DataGrid object with 2 columns:
> sound track name, and a play button next to it.
> Easy enough.
> 
> The confusion start to rose when thinking about the different use
> cases, which are very few but still:
> 
> 1. The user selects an item and click the play button next to it, the
> sound plays and the play button's label turns to "Stop".
> 2. (continuing from 1): The user clicks the stop button and the sound
> stops.
> 3. (continuing from 1): The user selects another sound track and hits
> the play button next to it, the previous sound clip stops playing, the
> previous sound clip button turns back to "Play", the selcted sound
> clip starts to play and its "Play" button turns to "Stop".
> 
> That's it.
> To disassemble these use cases into participants, I think I should
> have something like that:
> 
> In the view:
> A data grid populating list of SoundTrackVO objects where the first
> column displays the sound track name and the second displays a play
> button.
> 
> Commands:
> 1. PlaySoundCommand - start playing the soundtrack
> 2. StopSoundCommand - stops playing the soundtrack
> 
> Cairngorm events:
> 1. SoundToggleEvent can be named as START_PLAY or STOP_PLAY.
> attched to it will be the target SoundTrackVO object.
> 
> VO:
> AudioTrackVO
> properties:
>  - soundUrl - the sound URL
>  - isPlaying - a boolean indicating if the sound is currently playing
> 
> Model (That's where I need your help !:) ):
> Well, the use cases define a statefull behavior (e.g. the play button
> in case 1 causes the sound to play while the play button in case 3
> causes the active sound to stops and only then the requested sound to
> start playing).\
> And since commands are stateless I'd NOT like to have the play command
> to check whether a sound is currently playing and then stop it, that
> would lead to code duplication (both commands would need to know how
> to stop audio). Yuk.
> 
> That leads me to the State Pattern:
> In my opinion, which I'm really not sure is right, the play command
> should simply tell a SoundPlayer in the model to start play (is it ok
> to call it a business object ? I'm serious) and like so the stop
command.
> That object which resides in the model will have two methods:
> function startPlay(soundTrackVO:SoundTrackVO);
> function stopPlay(soundTrackVO:SoundTrackVO);
> 
> The SoundPlayer object is implementing a state pattern, therefore
> it'll have state objects:
> 
> PlayState object
> StopState object
> each of these will implement the IPlayerState interface which has a
> play() and stop() methods.
> 
> I'm digging to much into the State pattern, but that's the idea, The
> PlaySoundCommand will simply call the soundPlayer.play() and pass the
> SoundTrackVO to the model, and the StopSoundCommand will call the
> soundPlayer.stop() passing the target SoundTrackVO to stop playing.
> 
> So my question is if it's considered to be ok placing a self stateful
> object into the model like that in terms of best practices ?
> 
> 
> Thanks a lot, hope I didn't babble too much of it :)
> 
> Almog Kurtser.
>


Reply via email to