On Wednesday 07 Mar 2007, Russell Munro wrote:
I access the methods on the Controller singleton inline like this as the
article does:
Controller.instance.registerInfoTip(data) As opposed to setting a
'var model' like we do with ModelLocator.
We have instances of static classes (like
Russel,
This is very interesting. I am going to look at the article more closely.
It sounds like this is exactly the right concept.
Thanks,
Hank
On 3/6/07, Russell Munro [EMAIL PROTECTED] wrote:
I ran into this similar problem with a mapping application I am creating.
There was allot of
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
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
I ran into this similar problem with a mapping application I am
creating. There was allot of calculations require to render the map
image that were:
- nothing to with services
- were too small to pass through the cairngorm micro-architecture
- were definitely not part of the view
I umm
I am sure there will be plenty of suggestions, but it sounds like you
need some sort of static point of access for your sounds. There are
few approaches that I would try:
Make a SoundManager Singleton class that extends the EventDispatcher.
That way if you make use of the basic Flex events, you
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
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
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
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.
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
11 matches
Mail list logo
