Doing that, yes a command will drive two Soma instances. The good thing about that is you can use the same event from modules (like a loaded swf that would dispatch those events), or from other Soma instances. I thought you could easily use a “selector” in the the events to know which Soma instance you want to drive. I believe having more than one Soma instance is aspecial need, right?

Now, I’ve done it this way. I had to make choices but I’m not pretty sure what would be the best.

The problem with passing something else than the stage is, if your IEventDispatcher/component is not on the display list, you won’t get events dispatched from another view. But, is that a problem or a capability? I’m not sure either.

Your input is definitely interesting. Could you put you demo and code online somewhere? or send it to me so I can see what you’ve done more precisely?

Feel free to create a post on the forum, maybe it will be easier to push the conversation further if you’re interested, if you don’t mind registering!

http://www.soundstep.com/forum/

I’ll think about that anyway.

Thanks

Romu

I modified your SomaCafeTownSend example to support the situation described above by turning stage into an IEventDispatcher and not passing the Application itself to the SomaApplication constructor but an instance of an component which hosts the navigation-ViewStack. I also modified the SomaApplication constructor to call super() and not super(.stage). Now I can edit the user data of the 2 instances independently.

What do you think about it? Did I miss something obvious?

Lg
warappa

Thank you.

Soma MVC is not really good for loose-coupling coding, that’s why I’m experimenting with SomaCore. Soma MVC has been built upon Cairngorm while I’ve built SomaCore from scratch.

Please feedback if you test SomaCore.

Romu

You are very brave to take this on and I wish you good luck. You say you are trying to avoid hundreds of classes. That’s got to be good. MVC is something I would very much like to do but finding the time to is a problem.

I like your drawing and, as a visual learner, I would encourage you to provide some diagrams and SWFs of those “Wires” (I do like that name) so that we can find an easier way to understand the interactions that occur between elements.

So far I saw two ways to inject/update information into views without having framework code inside:

- Dependency Injection
- Buffer classes (such as Mediators and Proxies in PureMVC for the analogy, respectively for Views and Models). I mean “buffer” by classes that act as steward of other classes.

I’ve chosen the second way, and I’ve created a “buffer” class that I called a Wire.

Wires are completely free classes. I won’t tell you how to use them (because that’s up to you) but I can tell what you can do with them. Wires can be used to update views and models but they are not tight to anything. They are not even only tight to one tier. To create a wire class you extend Wire and implements IWire, and here are the roles they can take:

- a wire can act as steward of a view (such as Mediator in PureMVC)
- a wire can act as steward of a model (such as Proxies in PureMVC)
- a wire can manage both a view and a model
- a wire can manage multiple views and/or multiple models
- a wire can be considered as a subdivision of the framework and create its own views, create its own models and register its own commands. Much like you would create a specific package to hold a specific matter.

When I build something, I always try to keep a good level of freedom to handle problems how I like but most importantly, how they should be. If you like to have the framework telling you (or forcing you) how to build your application, fair enough but you won’t like it.

The wires are the free elements that will let you built your application the way you like or the way it is required to be. They can make your application rigid, segmented, flexible or centralized, depending of the role you are going to give them. They are so free that I believe remove (or lesser) what I call “Framework Fight”.

Let’s take an example, the Cafe TownSend above.

There are 2 wires: the LoginWire and the Employee Wire. They both register their own commands to control their views and models.

The Login Wire only handles a Login View.

The EmployeeWire handles 2 views: a list of employees view and an employee details view. But also 1 model (the employees data), all of them only related to employees matter.

I hope it is giving you some lights on what I’m trying to do, or at least, on how I’m trying remove the problems I encounter.

Romu