Actually, SoundManager doesn't seem to fit MVC. You have no view and no user input, correct? Why not just use a Command (or whatever patterns fit) structure without worrying too much about Cairngorm..? Cairngorm's great and all, but it is intended to manage large applications with many views, in the end.
Looking back at your orig. post, looks like Command/Event structure may be just fine, but that also doesn't mean you need to use the CairngormCommand (if such exists). maybe what you really want is a state machine that fires some events (probably). That state machine could very well sit in your model and fire events. Or not! You might want to take a look at the concept of CRC's ( http://en.wikipedia.org/wiki/Class-Responsibility-Collaboration_card) as a starting point. In the end, KISS works! -Scott On 05 Mar 2007 19:15:18 -0800, hank williams <[EMAIL PROTECTED]> wrote:
Thanks guys, I still dont know what I am going to do, but it is very helpful to hear the arguments. Sometimes it is really helpful just to get other peoples views. Obviously this is a bit of a gray area and there is no *wrong* answer here, which is why nuance and opinion are quite helpful. Regards, Hank On 3/5/07, JWOpitz <[EMAIL PROTECTED] <jwopitz%40gmail.com>> wrote: > 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 flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, "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 > > > > > > > > > > > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > Yahoo! Groups Links > > > >
-- : : ) Scott
