I see, the "SHOW_TABx" is the instance name of your tabs! I misunderstood your setup.

I don't have the answer to your question but would like to make a suggestion. Instead of sending a notification as SHOW_TABx you can have one notification and you can pass an id with it.

sendNotification ( SHOW_TAB, {id:x});

This will help in the future if you were to have 100 tabs (exaggerated to make a point), then you just add the ID to the notification instead of having to create 100 constants.

This is the main reason why I was thinking of the use of commands as the main router for communication through the application:

There is an attractive simplicity to a one-to-one relationship of Commands to Model interactions, and it is certainly possible to implement to that plan. If you have a large and/or distributed team working on your codebase, this might be the best because its easy to get everyone on the same page about what they're doing, since the same rule is applied everywhere.

but you are correct, the end user is the most important on the software development and there has to be a compromise on the development rather on the assumption that the end user will have the best system available.

You might reuse some of the same view components, but the Mediators will likely be unique to the application they're a part of and will not be good targets for reuse. But if you've abstained from letting your Model know anything about the rest of the app, then you can package it separately and use the same library in all your apps.

I think this is more along the lines of what I was thinking. Something that can be reused even though the likeness of being reused is very minimal educating yourself to working this way might feel counterproductive at first but will have pay offs in the long run when your attitude towards development comes so natural on leaving your resources open for reusability.

Conceptually, there is nothing wrong with putting all of your application's Model tier interaction into Commands if it 'feels more natural' to you, except that it uses up way more cycles than necessary to get things done.

When you talk about cycles, are you referring to the processor/CPU usage? I mean if your application is toward computer-savvy users you might be very likely to get users with "good" computers that wont have any issues processor intensive applications. No that this should be the mentality towards all applications, I mean more as this should be a secondary thought than a rule?

I have a small dilemma, so far through the documentation we can see how Mediators are able to listen to notifications which is really easy to implement. But I have found that using Commands for all my calls makes me feel more comfortable in that I dont have to tie my mediators to certain Proxies when there are changes to them but rather Commands are tied up to Proxy and Mediator Notifications.

This feels more natural forcing me to create my Mediators/Views/Proxies more open and not having references (or importing) from each other but they just expose their APIs which the controls are able to use as needed.

What is the general consensus in regards to this approach? I remember reading/listening something about Cairngorm using this method so in general I found the following

Allowing Mediators to listen for events
- faster development
- have to add references to other actors within the class
- less commands

Go through the Commands:

- slightly development
- lots of commands
- loose coupling ( not having to import classes to mediators/proxies)

When is it a good time to remove elements (Proxy,Mediator,Commands) from the facade? Would it be "better" to leave all the assets available rather than subscribing/unsubscribing?

Is it ok for Proxies to gather information from other Proxies or should I be going the other way around.

This is how my aplication is working:

User dispatches an event
Mediator sendsanotification
Command gathers that notification
ProxyA needs information from VO that belongs to ProxyB.

In this case, should I go all the way around and get a reference from ProxyB to gather the information I need from the VO that is connected to ProxyB or should I just get a reference to that VO directly on ProxyA.

The only issue why I am hesitant to get a direct reference on ProxyA and ProxyB from the same VO is because ProxyB is making changes to the VO.

Great explanation and I am following the "Stand Up Straight" way since that is how I am accustomed to work with my current AS practices.

I do like the flexibility of the framework that allows you to work either way depending on your needs.

All I was trying to retrieve was the ID of the button in action by the mediator than then can be used by other elements on the application, by reading another one of your replies I was able to understand perfectly what I was not understanding.

http://forums.puremvc.org/index.php?topic=1473.0

so it was my fault all along.

Jason is referring to Flex List Control.

As you may know, Flex comes with variety of components:
Controls: Button, Label, LinkButton, List, Tree...
Layout: Canvas, Tile, VBox...
Navigators: LinkBar, TabNavigator...

I see, some of us use the framework without Flex, that is why I was a little confused

I have a simple property on a view (ID) and I need the mediator get a hold of that property when an event happens. The Mediator does not trigger the event but the user does by interacting with the view.

Here is where I am confused. I do want my view to cooperate with pureMVC but at the same time I want my view to be reusable with other applications. In the login sample from Best Practices the buttons are tied up to a VO which makes me feel that the View is already being tied to a specific VO so if I need to move it to a different application the VO needs to go with it, and with so I feel it breaks encapsulation.

So I thought I can either expose the property (or create/get-set methods) but then would this modify the PureMVC framework?

Just out of curiosity. Who are you referring to when you say "Control" are you talking about any specific kind of class within puremvc?

Thanks and it does makes sense, but in the case that we need to let the Mediator know what specific button was accessed (via ID or Name) how do we pass that information to the Mediator without tying each view to the PureMVC paradigm? After all the application needs to know who initiated the request.

When creating views that have different properties that will be manipulated, in the purist point if view will the proper way to hold and manipulate this properties will be proxy/vo? or would it be just ok with doing it directly from the mediator/view?

What is the best method to organize components that have sub components or sub views.

For example, say you are building a car class and you have your

CAR

door
/handle
./handleinnerstuff

engine
/radiator
./waterlevelinradiator

Is that the best way to create "complex" components? Or would it be best to create them all inside the view folder?

door
handle
handleinnerstuff
engine
radiator
waterlevelinradiator

I have seen people do the above and it is ok in smaller apps but when you have really complex apps then it gets really messy.

another thing I was looking at was the multicore version of puremvc but that is way over my head right now as I am getting used to the standard version.