Sweet, I'll try that.

Yeah I'd like that too, I don't like monkey patching things, but at least that option is open to us quite easily with AS.

Thanks Cliff, changing to deferred instantiation seemed to fix things (although there was another completely separate issue afterwards that drove me crazy).

I also took your guidance from another post of not having the mediator know too much about the view it is mediating, I guess their tight-coupling led me to fall down the trap of "just let the mediator change the selected child" -- I know set a displaySection property to a constant and then the view is responsible for handling changing the display as appropriately.

Thanks again,

-D

Ok, lets see if I can give you more details (luckily my hack to the framework to trace out when notification fire should come in handy here) - note I've skipped stuff like prepping the application:

1. appStartup > does some checking that the account is valid
2. accountValid > displays login
3. loginSuccess (either after auto login - remembered user - or manual user login )
    > login proxy stores user
    > application mediator switches to the core application module and loads the module (here's where things probably get funky - haven't looked at the multicore version of PureMVC yet)
4. ApplicationMediator handles module loaded:
4a "Registers the module" basically passes the facade to the module so it can use it, the module then registers it's commands
4b Sends CORE_STARTUP notification when module loaded (CoreStatupCommand)
> CoreStatupCommand. Register mediator for core module
> CoreStatupCommand. Register proxies (including ProjectProxy)

5 CoreMediator handles creation complete and registers the view mediators for it's sub view (including the ProjectOverviewMediator where the issue is).

Hope that makes sense, I don't really want to force everything in the core module to create straight away (by monkeying around with the creation policy) but I'm sure that would fix it.

I don't think so as the whole design of my app is that a user can enter the app at absolutely any given point (I should really say section), I'm then orchestrating things to ensure that everything is loaded as necessary it's just views I'm having issues with.

Nope, it's definitely a race, if I refresh a load of times when the user would be taken straight to a project overview then sometimes it throws the errors and sometimes it doesn't.

P.s. I didn't mention but I meant to, that if a user logs in and they are taken straight to the project page the same code highlighted below (which selects the projectOverview child) works fine. It only throws the error when they navigate from somewhere else within the application for the first time after logging in.

I must be doing something wrong as I have no end of hassle with mediators trying to interact with their related view before the view is ready for the given interaction.

For instance the problem I have today is this:

> The user enters the application at a project page
> The app navigates to that section and goes off and loads the project
> The project gets loaded
> The following code in the mediator gets fired:

case ApplicationFacade.PROJECT_LOADED :
            var project:ProjectVO = note.getBody() as ProjectVO;
            // populate the project to the view if it's the project we're expecting
            if( project.id == projectOverview.projectId ) {
               projectOverview.project = project;
               projectOverview.selectedChild = projectOverview.details;
            }
            ...

The problem is the first time the user does this I get an error when trying to set the selectedChild of the viewstack, as I'm guessing the component isn't complete yet. However I must have only just introduced this issue as it was working fine a couple of days ago, but the thing is I've not actually touched this mediator or it's view, just added something else that handles the PROJECT_LOADED notification.

I've read the best practices and everything else I can get my hands on (look through the examples etc.) but I'm still having issues with mediators.

For example in my dashboard mediator (the dashboard is usually the first thing the user sees after login) I have this kludge in the constructor:

....
this.dashboard.addEventListener( FlexEvent.SHOW, showDashboardHandler );
if( this.dashboard.visible ) this.showDashboardHandler();

As I say sometimes the user isn't always taken straight to the dashboard after the login (thus the event listener handles whenever they navigate to that section and it's displayed) whereas when they are taken straight there after login it's already visible by the time the constructor runs (which is fine).

Any thoughts are greatly appreciated.

-D

Cheers Cliff, very helpful.

Currently I have the following setup:

ModelPrepCommand & ViewPrepCommand register the core proxies and mediators required for the app to startup (basically the login screen and the login proxying). However part of the login checking is to check to see if the user is logged in from a previous session (using a "remember me" feature) so sometimes the login screen (a child in the main viewstack) is never displayed at all. This means that when I log in in this manner and then logout the login mediator throws an error when it's trying to set a 'you have logged out message' on the login view - as the view component hasn't been initialised by Flex yet.

I've read this post on deferred instantiation and tried that, by only adding the mediator (if it isn't already registered) when the viewstack displays the login screen. That stops the error, but obviously by the time the mediator is added the LOGGED_OUT notification has been and gone (or not, but either way the mediator wasn't registered before the LOGGED_OUT notification was sent), is this an edge case scenario or do I need to look at how I'm handling my 'logged out' message to the user (such as move the message to the proxy)?

Just read this post http://forums.puremvc.org/index.php?topic=68.msg241;topicseen#msg241, I was thinking of using the token (although my delegates don't currently return it) - I'm thinking of keeping the delegates they currently don't really do much but what they do (setting the parameters for the HTTPService send) is abstracted away from PureMVC so that seems cleaner to me, although it is another layer to manage.

Okay, I've reviewed the new best practices document and that has cleared some things up.

I currently have some Delegates which are responsible for doing the actual sending of the HTTPService request, and they accept a IResponder as the argument to the constructor. I think this is where I was going wrong, it adds an extra layer of abstraction that may not be needed. However it is nice to be able to test that it is creating the dynamic URLs correctly.

One thing I don't want is lots and lots of HTTPServices kicking around some of which will only get called once during the entire life of the app, so I was working with disposable HTTPServices, thus the IResponder being passed to the delegate when it's created and that being provided to the temporary HTTPService when it was called. I also somewhere along the way mis-understood proxies (it was actually a while between me reading the 101 courseware and then starting to implement PureMVC in my app so that's probably why).

So what's your the consensus with HTTPServices within Proxies, say I have a RoleProxy which is CRUD-like but allows listing of all the Roles do you have 1 HTTPService for each of the methods (5 in total) with associated event handlers (so maybe 5 result handlers and one fault handler -- depending on how granular your error handling needs to be), or something else.

Also as an aside I have tinkered with IOC in Flex (using this DI framework: http://thefoundry.anywebcam.com/index.php/actionscript/di-as3-released/) but once our app moved to modules it became difficult to work with DI.

What about having the Command act as a Responder (by implementing IResponder) and the execute method basically creates a delegate and then calls the appropriate method. That seems cleaner than what I'm currently doing.

So are you guys saying you have your mediators talk direct to your proxies.

I currently have it so that the mediators send a notification that they want some data, then a command usually just gets the proxy and tells it to get the data, when the proxy has it's data it sends a notification that the data is retrieved.

There are some instances where the command gets something in the notification body, but that's usually passed straight onto the proxy when we ask it to get the data.

I had the same issue here, thanks for the solution, but luckily the only one in an otherwise flawless upgrade.