I should probably clarify a few things. If you have MVC, and I had to qualify a SoundManager class as one of those, I would probably see it first as a command class. Manager type classes generally are of this nature anyway. But that can easily be argued to say Sound is also a view type nature too and there is enough supporting information to be so. Maybe this is more about personal preference as I can see both sides.
As to why I don't like the Model doing command-ish like things is that again it is not its responsibility. Now that is not too say that it can't dispatch events. In fact when you have a [Bindable] class, it automatically dispatches propertyChange events. So that is perfectly acceptable in my book. In fact if you look in the flex2 reference material and search metadata, it explains how this works internally and how you can do it manually. I do not, however, like methods in the Model aside from getters/setters. Many of the developers on my team, however do like to stick methods (not getters/setters) in the model. I don't like it and advocate against it. For instance we have a customizable dataGrid where users can add various column types with specific data. I suggested having a command-type class build columns for it. However, my teammates wanted to have a method in the model. For what reasons I do not now. All I know is that although I love democracy in terms of politics, I cannot stand it in application development. Sorry for that. Just a rant and rave for a sec. Back to the point though, to maintain consistency with the MVC framework, some sort of ColumnManager would be appropriate and would be in the command family. I am not any kind of MVC purist and occasionaly bend the rules or do something questionable with regards to what we have been discussing. But when developers start deviating dramatically from the core purposes of what a model is, what a command is, what a view is, then I will raise an eyebrow and possibly a stink. Again my 2 cents. Hope it helps in your decision making. --- In [email protected], "Troy Gilbert" <[EMAIL PROTECTED]> wrote: > > 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 > > > > >
