PureMVC Architects Lounge

Generally, I render the view component, then call its command on CREATION_COMPLETE. The command first initializes the mediator and then the proxy and calls the methods on the proxy to get the required data. I initialize the mediator first so that it can catch the responses from the proxy. I make sure the view component is completely created so the mediator can set the data on it.

I find this to be acceptable in most situations but on some more complex pages I find that my page loads with empty fields and then they get populated because the view rendered and then the proxy got its data. I would prefer that when I go to a "new page/tab" that the first thing that happens is that the proxy registers and starts the asynchronous calls to the service layer/db. While I am waiting for a reply, the view component can get rendered and then the mediator created. When the mediator is created it will set all the data on the view component from the proxy. The mediator will still have its listeners on the proxy to set the data if it comes in after the mediator is created.

Is this the best way to do this? Its annoying to call the proxy prep command, then wait for the view to hit CREATION_COMPLETE, and then call the view prep command. I also have to write extra code in the mediator to initially set the proxy data that came in before its creation.

I'm just fishing for better ways to do this!

Generally you want to register Proxies BEFORE any view prep takes place, but DON'T have the Proxies go ripping off and requesting data right off the bat. Then later invoke data fetching calls when the mediators are registered and ready to receive the notes from the Proxies.

-=Cliff>

Not that I'm challenging what you said, but I'm curious why I shouldn't make the data requests before the mediator is created? I check in the onRegister method of the mediator if the data requests were fulfilled before it was created and then I get the retrieved data from the proxy accordingly. It takes a bit more code but it seems like it should be more efficient. Is it that the efficiency is negligible and isn't worth the extra code? I have to write an extra command for each view now and extra logic to handle calling both.

Usually, those Mediators that aren't registered yet are going to want to hear from the Proxies when the data comes in so they can feed it to their hungry view components. They don't want to miss the notification. And checking to see of the data is there and then just listening for the note if not is redundant code. Just listen for the note and be sure the note can't be sent before the Mediator is ready to respond. So the general procedure that fits most applications is to prepare the Model by registering all the Proxies first, then prepare the View by registering the Mediators. Then start making the calls for data.

Another important reason is that when developing an RIA, particularly a Flex-based one, you should always consider the possibility that the Model region will be reused by another application. It is possible and often desirable for Flex web apps, AIR desktop (and soon AIR mobile) apps to use the same Model tier, but with different use cases. Keeping this notion in mind when developing your app will lead to a more portable Model tier; one that doesn't make any dependencies on or assumptions about the application it is running in.

In the Flex web version of your app, you might want to go load a bunch of data in a particular Proxy right away because the primary use cases of the specific application will be using it first.

However in the desktop application, (for instance, a maintenance app for the data shown by the web app) it might not be desirable for this Proxy to automatically go fetch its data. It might be that you only want to do this when doing maintenance of its data type, and it may be one of many types.

So as a best practice I continue to advise Model Prep / View Prep / Fetch Data / Show Data as the basic steps.

-=Cliff>