Coming from a game development background, I always consider sound to be apart of the view. Generally, I consider anything directly consumed by the user to be "view" while internal state that has meaning independent of the view is the model.
So, while your sound player does maintain state (the currently playing sound, the current position in the sound being played), you need to answer for yourself whether that state is on par with (to use a trivial example) the contacts in an address book or the position of a scroll bar on a text box. If the sounds are used to convey information about state, then it sounds to me they're more like scrollbars. If the sounds *are* your state that you're concerned with (like an audio editing application), then they should be in the model. Another way to judge it: if you were going to persist the current state of your application to disk, would you worry about persisting the state related to sound? Or to put it another way: if I was forced to manipulate the data in your application through an API instead of a UI, do I care about the sounds or are they only there for the pleasure of the human audience? Troy. On 3/5/07, hank williams <[EMAIL PROTECTED]> wrote:
Thanks, > Make a SoundManager Singleton class that extends the EventDispatcher. > That way if you make use of the basic Flex events, you can then have > the soundManager instance assign its event handlers. > This is the way the code currently works. > As for using the Cairngorm class, I think that could also be a good > idea. I have written a little blog on it here: > http://jwopitz.wordpress.com/2007/03/01/ > I read your blog, and it seems to finish right where I am beginning. I agree with your premise that commands can and should be used for internal app communication and not just for remote access. In fact that is why I posted my question. The issue is where in the cairngorm architecture a singleton type class of this type should sit. In cairngorm you have events, commands, delegates, views and model. As I have spent time thinking about this today, I have started to think that it is indeed closest to being an element of the model. It retains state and can be queried as any element of the model can. The only weird thing is that it can broadcast events. But it makes sense to me that certain types of model information perhaps should be able to generate events. Currently models generate events surreptitiously via the binding architecture. They really do generate events, just not in the cairngorm way. So why not allow model elements to generate cairngorm events? > I would not start having the model do any command-ish activities since > that is not its responsibility. Why not? If a model contains data that changes, why is it appropriate that the only way to "tell the world" is via binding, when binding just doesnt always match the need? Regards, Hank
