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.
