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. >
