Thanks again for confirming what you can.  And sorry for being deliberately vague.  At the moment I just can't describe the system I am working on.

And I can't (yet) tell the server side how to deliver data, either.  I have to take what they give me and say I like it (I don't).

Anyway, surely more questions to come...

I had looked over that example earlier.  It links the data in the departments to the data in roles by the shared value of userName, right?  If I were to (continue to) translate my situation into the User/Role/Department example, I would say that right now we have a unique singleton Proxy class for each department, with a common interface.  Then we have a unique singleton User class for each, uhm, actual user.  Yes, I know this sounds crazy.  It was perhaps stupid of me to try to re-state my problem in terms of the user/department/role example...

So let me try to start over going back to the abstract.

I have two types of Proxies, differentiated by interface:

IAProxy - for type A data (defines a getAData() method)
IBProxy - for type B data (defines a getBData() method)

And then I have a whole lot of server requests that get mapped into unique proxies...

A1Proxy
A2Proxy
A3Proxy
B1Proxy
B2Proxy
B3Proxy

The ratio between An to Bn is generally 1-1 but there are exceptions.

The A1Proxy is given its data, which comes from the "1" database "A" table, and so on for A2-An.
The B1Proxy is given its data, which comes from the "1" database "B" table, and so on...

Because the A1Proxy has its own unique class, it can do this inside its constructor:

:

public var bProxy:IBProxy
public function A1Proxy() {
   ...
   bProxy = B1Proxy(facade.retrieveProxy("B1Proxy"));
}
...and so do all the other A-type proxies...

And then a certain Mediator, not concerned with what database its data comes from; only concerned that it has A-type data and B-type data does something like this when it handles the notification "AProxyChanged":

:

aProxy = IAProxy(notification.getBody());
aData = aProxy.getAData();
bData = aProxy.bProxy.getBData();
for (i = 0; i < bData.someValueList.length; i++) {
  var someName:String = bData.someValueList[i]);
  ...
}
I am reasonably sold on the fact that the above proxies need to all be unique (for example, due to subtle differences between the databases, the fact that the requests are all separate and asynchronous, etc).

Maybe even the interfaces are ok, (for example, if the interface requires the getAData() and getBData() methods to return a typed VO).

But that proxy-reference-in-a-proxy still bugs me.  I know that the Mediator only gets the IAProxy reference in the notification but...

Maybe the notification should be mapped to a command instead of being responded to directly by the Mediator?  I think so...  The reason for this global "AProxyChanged" notification is that whenever any server request comes back in, it is automatically dispatched... this is wrong.  And besides, there has to be unique logic before that to place the correct AnProxy class in the notification anyway... it should just control the Mediator's data there as well, passing it both the A-type proxy data and the B-type proxy data... might not even need these IAProxy and IBProxy interfaces!  To reiterate:  the Mediator should not be responding to the "AProxyChanged" notification, it should be manipulated directly by one or more intervening commands!  Ah, the spaghetti unravels...

Well, I've drifted off my original concern into something very specific regarding the data model (and more?).  Thanks for listening anyway!

XMLProxy loading XML (finished) -> ImageLoadCommand -> ImageProxy (for each Image) -> ImageVo (SaveData) -> ?

Is that logic right? And how can I send a Notification to a ImageMediator which was created after the XML had been loaded? How should I mange the Names of ImageProxys and ImageMediators

I had the same exact question.  I think you are fine.  As far as the last step, here's what I do in my Proxies.  I dispatch a notification inside the setData() function something like this:

:

override public function setData(data:Object):void {
  super.setData(data);
  sendNotification(GlobalConstants.NEW_DATA, data, proxyName);
}
Anyway, your mediators might all respond to the NEW_DATA notification, then check if the type (ie proxyName) matches a proxy name they care about, and then finally process the data appropriately.

Finally, if your Proxy class is basically a single-instance class, then I would just make a specific notification name for it and not use the "type" parameter above.  In reality, this is what I do most of the time.  It cuts out a lot of needless handleNotification() calls that are ultimately ignored inside the unrelated Mediators anyway, but at the expense of having more notification names declared in your application.

The first approach is medium-simple, code-consistent, but redundant/wasteful, the second approach is very simple, efficient, but has higher code maintenance and documentation time.

I'm still looking for a silver bullet.

I think I figured out what was going on.  I said above that the bProxy reference doesn't change once it's instantiated on AProxy, but the AProxy reference does change in the Mediator that uses it (it's typed as just an interface... which mandates a getter for a BProxy instance).  So anyway, for example, the AProxy might be a list of users for a department in the company and then the Mediator accesses an instance of AProxy for any given department and then wants a role list (BProxy) for that AProxy accessed by the bProxy reference.  So obviously, the accounting department would have different roles than the sales department, and so forth... well you probably get the picture.

So in the end it wasn't quite as crazy as I had originally thought (and wrote).  But it still seems ... sub-optimal.  On the other hand, if I were just writing this in a regular non-PureMVC environment, I could see myself doing the same thing.

Now, what I think would be better is to have a AListProxy to handle all the departments and a BListProxy to handle all the roles and then implement logic to get the right item from BListProxy for any given item in AListProxy. 

Finally, as far as those handy-dandy mutual references, if they are still for some reason absolutely necessary, those can be put on a VO that is used as a list item for either or both list proxies.  So now, instead of Proxies with references to other Proxies that are accessed by a Mediator, we have VO's with references to other VO's that are accessed by the Mediator--perhaps not the best OOP but hopefully at least better than what we've got now.

Again, at this point I want to at least simplify the use of PureMVC in our project, this should:
1 confine spaghetti code to the individual view classes and VO's as much as possible--so they may be dealt with later
2 make the application level framework sound, so new stuff can be added easily and consistently

Thanks again for your time and help

... actually, I have a follow-up question about what a Proxy should do ...

I was looking over some source and found a place where a particular Proxy class (Let's call it AProxy) had a reference inside of it to another Proxy (Let's call it BProxy).  These two proxies' data share a relationship much the same way two tables in a database might.

Later in the source you have a Mediator class accessing BProxy data via its public reference on AProxy:

:

for (i = 0; i < AProxy.bProxy.someValueList.length; i++) {
  var someName:String = AProxy.bProxy.getSomeValueName(AProxy.bProxy.someValueList[i]);
  ...
}
Now, on the face of it, this just looks utterly daft to me.  But please disabuse me if that is not the case and in real life Proxies do indeed contain public references to each other.  By the way, the bProxy instance is not dynamic--it does not change during the course of run-time.  Looking at the PureMVC relationship diagram, it does indeed appear that Proxies are allowed to touch each other, but I thought that just meant, you know, if one proxy needed a value on another Proxy in order to initialize/update its own data it could go ahead and do so.

Anyway, what it seems to me should happen is that instead of bProxy instance being an actual Proxy extended class, it should be a simple VO type object.  AProxy can set up this VO from data it gets from BProxy upon construction.  But, and here's what I am sure the original author was thinking at the time, if I am going to set some VO on AProxy to data on BProxy, why not just make the reference to the BProxy itself and skip having to create a VO class?

I'm on the verge of rethinking this part of the application's model structure from scratch, but before opening that can of worms, I would greatly appreciate a second opinion.

In the meantime, I will crack open those links you gave earlier!  Thanks!

Thanks!  That's a way of thinking about it I had blocked off for some reason.  I guess I was trying to think in terms of there only being either Proxies or VO's in the approach to the data model. 

Although there might be exceptions, in most cases our problem is getting deeply nested data.  Making VO's for the Proxy to map less managable data onto makes great sense.  I guess it was just too obvious.

By the way, the XML approach is not possible.  The BlazeDS situation is probably most analogous to my situation.  No wait, now I see what you meant.  That's brilliant!

I have a sort of general question about PureMVC Proxies...

Currently I am using proxies almost exclusively to get data from the server.  I want to have a 1-1 relationship between (for example) RemoteServiceXXXProxy and some specific RemoteServiceXXX (like a url request to get login data).

All of these requests take time to get a response.  I assume that this response logic should go in the Proxy.  For example, instantiate the URLLoader object and send its url request in the proxy constructor, and then register all relevant response events to handler methods also inside the Proxy.  Those handler methods just assign the result of the URLLoader to the Proxy's data and dispatch a notification, specific to the Proxy, that tells any observers that its data has been set (and handle errors, faults, etc).

But, in the actual application there are times we want to use a short-cut to get data off the proxy without writing stuff like (please disregard whether this data model seems daft):

var accountProxy:IProxy = facade.retrieveProxy(AccountProxy.NAME);
var data:Object = accountProxy.getData();
var currentUserName:String = data.accountVariables.userNames[data.accountVariables.currentUserId];

... with something like this:

var accountProxy:IProxy = facade.retrieveProxy(AccountProxy.NAME);
var currentUserName:String = accountProxy.getCurrentUserName();

... where getCurrentUserName() is a method inside the proxy that gets the variable we want.

My personal stance is one against doing this.  Mainly, I worry about bloating proxies with "convenient" get() methods that are perhaps used only by one Mediator in the entire application.  My opinion is that, verbose or not, Mediators should format from the raw data of the Proxy, or, if enough Mediators are using the same data (like the example above), either 1) make a new Proxy like CurrentUserProxy that gets set-up from data on AccountProxy or 2) make a utility class containing those common data access methods (although this is similarly vulnerable to method bloat).

But there's one more option, which is to have the Proxy format itself with data variables that are more conveniently arranged that the raw server result.  When I read the best practices document, I got the impression that it said this is a good idea.  Honestly, though, this seems to me to be no different than adding get() methods (especially since I know other programmers will start using AS getter/setter properties if I let them!).

Anyway, I'm leaning towards a rule to forbid methods (getter/setters included) other than remote data access retrievers, updaters, and handlers from being implemented inside proxies.  But, not having an MVC background, I may have a bias, so I want to see what the PureMVC community has to say about the issue.  What rules do most people follow when implementing Proxies?  Is there some completely different way I might go about this?

Thanks!  That's exactly the kind of answer I was hoping for!  And put that way it seems so obvious.

By the way the the Slacker demo mentioned in the FAQ was quite helpful.  I just got stuck because deferred instantiation was also not quite exactly the same as what I wanted to do above.

I want to know how I should register Mediators and set their viewComponent.  I think there are a million ways to do this.  I just want one.

First of all, it is necessary for me to create the view instances dynamically after initial application start-up.  These view instances are not static to the application.  For example, depending on the account log-in, different panel views will be instantiated and shown on-screen to the user (not the same as pop-ups, but like pop-ups, they are dynamically created during run time).  I cannot change this specification.  Nor can I alter the decision to use PureMVC as the framework.

So now I want to know how on earth I should approach this problem in PureMVC.

I have decided to use commands to initialize these views--the command notifications to be dispatched based on the content of an account information proxy loaded after login.  But that's as far as I get before I am stuck.

What should these commands do?  Obviously instantiate a Mediator.  Should it instantiate the view component as well (the non-pureMVC .as class)?  That way I can pass the view component to its mediator's constructor when I initialize it.  But it seems strange to instantiate an .as component in a Command...  Furthermore, these Mediator classes are essentially singletons (ie there are not going to be two of the same panel view component on-screen ever) so should I really even allow them to accept a view component parameter in their constructor?

If that's the case, then should I instantiate the view component in the Mediator then?

I'm leaning toward the latter solution but would just like to double-check that there isn't a better way.

I think this problem is essentially the same one that occurs when dealing with PopUps (except that popups also require closing logic--which I don't have to worry about).  Surely there's a commonly accepted standard someone can point me to?

For what it's worth, I have read the best practices document (about 3 times in the past 2 months) and browsed the forums here but am still utterly overwhelmed by PureMVC.  What I really want is a slightly more concrete framework--which PureMVC self-admittedly is not.  So I hope I can get some suggestions here and/or concrete examples of how to make some common sense decisions about a PureMVC based framework.  Knowing this, if you can recommend any posts or communities, you will forever have my gratitude.

Thanks.
Patrick

ps I have a ton more questions but want to get a response to this one first...

edit: sorry for the split infinitive