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
