Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Mediators give me headaches  (Read 13425 times)
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« on: April 10, 2008, 02:36:50 »

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
Logged
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« Reply #1 on: April 10, 2008, 02:38:22 »

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.
Logged
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« Reply #2 on: April 10, 2008, 02:44:20 »

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.
Logged
justSteve
Courseware Beta
Sr. Member
***
Posts: 55


View Profile Email
« Reply #3 on: April 10, 2008, 02:53:03 »

Is this something the StartupManager Utility can address?
Logged
trilec
Sr. Member
****
Posts: 52



View Profile WWW Email
« Reply #4 on: April 10, 2008, 02:54:58 »

Might need a bit more info on how you are setting up the proxy for the ProjectVO and when your initializing it.

Logged
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« Reply #5 on: April 10, 2008, 02:56:29 »

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.
Logged
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« Reply #6 on: April 10, 2008, 03:11:56 »

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.

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: April 11, 2008, 04:34:50 »

Sounds like a search of these forums for the term 'deferred instantiation' might help you.
-=Cliff>
Logged
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« Reply #8 on: April 13, 2008, 06:00:30 »

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
Logged
justSteve
Courseware Beta
Sr. Member
***
Posts: 55


View Profile Email
« Reply #9 on: April 18, 2008, 10:33:33 »

(luckily my hack to the framework to trace out when notification fire should come in handy here)


i'm thinking a native logging utility would come in handy lots of places. nudgenudgewinkwink
Logged
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« Reply #10 on: April 18, 2008, 11:17:40 »

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.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #11 on: April 18, 2008, 11:58:24 »

There shouldn't be a need to 'hack' or 'monkeypatch' the framework to achieve this :)

Since the concrete Facade is used for all Notifications, you can always just override sendNotification in your ApplicationFacade, and then have it tee off a list of all the Notifications and when they're sent. Be sure to call super to have the notification actually be sent. This is also a place where you could disable certain Notifications.

You probably wouldn't want to add all the responsibility of doing logging here, probably in a Logging actor in the controller region that this 'Intercepting Facade' would communicate with by interface calls.

-=Cliff>
Logged
DEfusion
Courseware Beta
Jr. Member
***
Posts: 16


View Profile Email
« Reply #12 on: April 18, 2008, 02:01:05 »

Sweet, I'll try that.
Logged
Pages: [1]
Print