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.