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: StartupCommand or put it in ApplicationFacade.startup() ?  (Read 7635 times)
polesen
Newbie
*
Posts: 5


View Profile Email
« on: June 11, 2008, 01:35:47 »

I was wondering, why we are always doing a StartupCommand, which kind-of bootstraps the whole mediator and proxy setup? Couldn't we just do it directly in the ApplicationFacade.startup method?

Could this StartupCommand:

:
public class ApplicationStartupCommand extends SimpleCommand {
    override public function execute(notification : INotification) : void {
        facade.registerProxy(new XyzProxy());
        var app : FooApp = notification.getBody() as FooApp;
        facade.registerMediator(new BarMediator(app.bar));
        sendNotification(ApplicationFacade.GET_INITIAL_DATA);
    }   
}

not simply be replaced by this code, in the ApplicationFacade.startup method:

:
  public function startup(app : FooApp) : void {
      registerProxy(new XyzProxy());
      registerMediator(new BarMediator(app.bar));
      sendNotification(ApplicationFacade.GET_INITIAL_DATA);
  }

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



View Profile WWW Email
« Reply #1 on: June 13, 2008, 06:20:58 »

Certainly you could.
Startup might be simple enough that you'd be better off that way.

It might be a more complicated process where the model prep and view prep are handled be different commands because the model is imported and has its own prep command.

Simple or complex, triggering a Command puts the responsibility in a dedicated place rather than adding more responsibility to the Facade, which is really not meant to be very smart, just a go-between really. It has the startup responsibility of creating the other actors and then hands off.

Another reason for not doing the StartupCommand  activities in the ApplicationFacade is   that it would encourage using it as a generic place to put 'global' functions. Clutter attracts clutter and the facade is too tempting a place to start cluttering.

That said, if you get all this but still hate passing off to that startup command to register one proxy and one mediator, then by all means make your program less complex; do it in the startup method, and drop the command. Especially if you have no other commands to register. That way you can skip overriding the initializeController method as well.

-=Cliff>
Logged
polesen
Newbie
*
Posts: 5


View Profile Email
« Reply #2 on: June 13, 2008, 06:56:41 »

Okay, thanks for the reply.

I understand what you are saying. My reason for asking is, that I feel strange when putting something like Mediator-to-View gluing and Proxy setup into a Command. In my understanding, commands will contain business logic (in combination with my model proxies), and this framework setup in the StartupCommand isn't businesslogic at all.

In addition to this, I could see that my ApplicationFacade already contained some framework-bootstrap code (in initializeController()), and some of it was in the StartupCommand. Hence, I had this framework bootstrap partly in the facade and partly in a command.

Wouldn't it be better to advice people on keeping the framework-bootstrap/glueing-it-all-together code inside the ApplicationFacade, and only put what is actual business logic into commands? I understand, that the setup process can be much more complicated than my little example is, but would it not always be possible to extract the "importing of model" from the registering of proxies and mediators?
Logged
Pages: [1]
Print