jwopitz, Thanks for the feedback. I definitely would not use cairngorm just for this feature, but my app is already fairly large and is based around cairngorm. Thats why I have been trying to think about the best way I might implement this with it.
Regards, Hank On 3/6/07, JWOpitz <[EMAIL PROTECTED]> wrote: > Oooh good call. I forgot about these little helpful tools. > > But Hank, I think you nailed it on the head. There are no wrong > answers. Given the fact that you have thought about this as > thoroughly as you have, I am sure that you will find the best solution > for you and your app no matter what direction you take. > > Here is one more bit about Cairngorm. Like Scott said, it might be a > bit overkill to use this micro-tecture if you have a very simple > application. Now if you have already implemented it for other > purposes, you will incur very little if any overhead for adding > another command. But if this is the one and only place that you will > using this in this app, then it might be a bit overkill. > > Anyway, good luck and be sure to link us up to see your progress. > > Take care, > jwopitz > > > --- In [email protected], slangeberg <[EMAIL PROTECTED]> wrote: > > > > 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 [email protected] > <flexcoders%40yahoogroups.com>, "Troy > > > Gilbert" <troy.gilbert@> > > > > 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 <hank777@> 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 > > > > > > > > -- > 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 > > > >
