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: Delayed command and proxy registration?  (Read 6754 times)
gregbown
Jr. Member
**
Posts: 16


View Profile Email
« on: August 12, 2008, 06:34:02 »

My application needs to give the user a 30 second video followed by a login screen and the option to go directly to the login at any point.
InitProxy gets access to a 30 the second clip url.
loginProxy gets access to the full length video url

InitProxy is registered in StartupCommand.

When and where should I register the loginProxy?
If I use a LoginCommand to register LoginProxy when and where should I register the LoginCommand?

I believe that I need to register them in ApplicationMediator on the event from the view but I have not seen any examples of this.
All the examples assume login is the first action and so registration is always in StartupCommand.  If anyone knows of a deferred registration example please post it.
Thank you
Greg
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: August 13, 2008, 08:25:05 »

Unless there's an overarching reason for jumping through hoops to defer the registration of LoginProxy and LoginCommand, I'd just do them at the start. It doesn't sound like you have terribly complex application, the only issue is in when does the LoginCommand get triggered, or when does the Proxy get called. If you set everything up normally and then control the order in which notifications are sent, then you'll have a simpler application.

This isn't to say that deferring instantiation of actors isn't ever necessary, but usually it's a Mediator being deferred because the view component it mediates hasn't been instantiated by the view just yet. Proxies and Commands occasionally need to be deferred as well if you have a really huge app with lots of them and you're never sure which will be used during a given session. But again, this adds complexity to your app since the registrations happen in multiple places, and should only be done if it's absolutely necessary.

It's sort of like going to a shoot out but leaving the gun empty till you get there because that's when you expect to use the bullets. Safer true, but a gunslinger generally doesn't fire till he needs to, and fumbling bullets into the chamber while facing down the opponent in the street at high noon is less cool (and arguably more dangerous) than just popping open your holster snap and standing ready.

-=Cliff>
Logged
Pages: [1]
Print