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]> 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 [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 > > > > > > > > > > > > > > -- > 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 > > > >
