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: Another small request  (Read 13569 times)
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« on: January 29, 2009, 08:27:30 »

I started using interceptors today, and they rock. However, I found one small change I needed to make in order to inject an interceptor (or any code) before the application starts, but after the fabrication apparatus was initialized completely. I need to ensure access to moduleAddress but also to make sure no notifications or routing have been sent out yet.

I found that inside startApplication() of ApplicationFabricator there's a notifyFabricationCreated() method called on the FlashApplication class which I could override in my own ModuleApplication allowing me to run my code before the app started. I thought it was perfect for injecting my code, however, I realized this call is made after _facade.startup(startupCommand, fabrication) resulting in my code running after some of the initial routing, notification and other start-up calls are made. By reversing the order of these two calls within StartApplication() I was able to register my code before the application actually started, but still ensuring that fabrication was intialized and moduleAddress was available.

Can you see any reason not to reverse these calls? Am I missing anything that may misfire? Is there a better way to run some of my own code after fabrication has initialized but before the startup command is called?

I realize I could just add my code to the start-up command itself, but I wanted to add it in my base module class so all my modules could inherit the functionality.
« Last Edit: January 29, 2009, 08:34:11 by Jason MacDonald » Logged
Darshan Sawardekar
Sr. Member
****
Posts: 85


View Profile Email
« Reply #1 on: January 30, 2009, 03:45:26 »

Hey Jason,

The fabricationCreated event should only really be sent when the application's fabrication has finished initializing completely. That way if the shell/parent needed anything from the child module in the fabricationCreated handler, it has that information. I tried swapping those lines but it breaks the unit tests. Also a couple of flex demo's depend on the module having finished initializing when the fabricationCreated event is received.

Another way to achieve this is to hook into the init sequence of fabrication which is,

  • initializeModuleAddress()
  • initializeFacade()
  • initializeEnvironment()
  • startApplication()

The hook method to do what you are looking for is initializeEnvironment. You mentioned you have a ModuleApplication. You need to add a custom fabricator to it. In the ModuleApplication, You need to override initializeFabricator like

:
override public function initializeFabricator():void {
   _fabricator = new ModuleApplicationFabricator(this);
}

And in the ModuleApplicationFabricator < FlashApplicationFabricator do,

:
override public function initializeEnvironment():void {
   super.initializeEnvironment();

   facade.registerInterceptor("fooNote", FooInterceptor);
}

peace,
darshan
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #2 on: January 30, 2009, 06:52:38 »

I guess I was trying to avoid using a custom fabricator since I already had a custom Application. I had originally wanted to hook into initializeEnvironment() but couldn't find a clean way to do so, short of a custom fabricator.

I thought there might be a reason for firing that event after, which is why I wanted to ask, but it seemed to work fine in Flash. In the end, I'll just create a Fabricator as you suggest.
Logged
Darshan Sawardekar
Sr. Member
****
Posts: 85


View Profile Email
« Reply #3 on: February 01, 2009, 07:51:10 »

After some more thought I think the initializeEnvironment could be added as a hook within the IFabrication interface itself. ApplicationFabrication would implement this call and subclasses call super.initializeEnvironment or not to override this behaviour. Make sense?

peace,
darshan
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #4 on: February 01, 2009, 08:38:58 »

That would be great!
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #5 on: February 19, 2009, 11:57:10 »

Hey Darshan. I know you are busy but was there any update on this? I'm still using my hack and would love to get a fresh set of SWC's with this and the public access to applicationInstanceName I mentioned in this thread on your site. I'm afraid my hacks will be out of memory before long and my code will break when I update to your next version and won't recall what all I need to change.
Logged
Darshan Sawardekar
Sr. Member
****
Posts: 85


View Profile Email
« Reply #6 on: February 21, 2009, 07:45:52 »

Hey Jason,

The applicationInstanceName code and tests are on SVN. I haven't been able to work on the direct hooks to IFabrication in the lifecycle yet. My work commitments have left me with very little spare time recently. I will have more time to work on this after the next week or so.

I have tried to make building of Fabrication swc's from the svn very easy with an ant based build system. To build an swc use, ant swc, ant swc-flex, etc. This will produce the corresponding swcs in the dist folder.

peace,
darshan


Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #7 on: February 21, 2009, 06:34:26 »

Cool, thanks. I didn't realize you had committed it to SVN.
Logged
Pages: [1]
Print