Spring Actionscript Multicore integration inside Fabrication

[GoogleCodeExporter]

Darshan,

Thank you for your continous efforts on Fabrication. We have successfully 
built and deployed a number of projects in Fabrication. It's been a joy.

I need to bring DI to our projects. I do not want to go with alternative 
frameworks such as RobotLegs etc because they couple themselves to Run-
Time specific features (i.e. EventDispatcher) unlike PureMVC which is Run-
Time feature-set independent. I much rather prefer the approach, your way 
of thinking, of Abstract - > Concrete Utility which is what Fabrication is 
and what has been a great separation of concerns.

There is no official pureMVC multicore Spring Actionscript extensions but 
I was basing my research on http://blog.vivoid.com/2009/03/spring-
actionscript-puremvc-multicore-integration-0/ development for multi-core 
pureMVC to introduce it inside Fabrication.

The puzzle that I have is where do I start introducing a spike to Spring 
Actionscript PureMVC extensions of Fabrication without interfering with 
the inheritance chain such as "FabricationMediator extends Mediator". I do 
not want to introduce a versioning of the Fabrication but rather look for 
an elegant way to introduce IocMediator, IocProxy and other members into 
Fabrication. Your advice or help would be very much appreciated.

Thank you,

Alex

Original issue reported on code.google.com by a.mikhai...@gmail.com on 18 Feb 2010 at 11:14

[GoogleCodeExporter]

PS THIS IS NOT A DEFFECT. IT IS A QUESTION AS TO HOW TO GO ABOUT A FABRICATION 
EXTENSION TO ACTIONSCRIPT PUREMVC MULTI-CORE

Original comment by a.mikhai...@gmail.com on 18 Feb 2010 at 11:15

[GoogleCodeExporter]

Hey Alex,

Regarding you query about Spring MVC DI in Fabrication.

I had a brief glance through the code you linked to. It looks good but 
integrating 
that with Fabrication looks messy due to the class hierarchy like you mentioned.

There is a simpler way, but you need to make some core modifications to support 
it. 
The basic idea is use Fabrication's Interceptors to do post-init or pre-remove 
actions to plug-in the dependency injection on demand.

The first thing you need is to know when any of the PureMVC actors get 
initialized(and removed). Send notifications like ACTOR_CREATED, ACTOR_REMOVED, 
or 
more specific like PROXY_CREATED etc. or both.(ha!) You need to modify the 
registration methods of the actors, either in PureMVC Model-View-Controller 
classes 
or the Fabrication ones. You could get away by doing it in some of the 
front-facing 
aliased method, but that's just lazy. :-)

With these notifications in place, build some concrete Interceptors that do the 
plugging-in like if actor implements IocMediator, set proxy on it, or do any 
other 
stuff etc, else ignore and so on, whenever a ACTOR_CREATED notification is 
intercepted.

The rest of the stuff, like loading the appContext, etc is straightforward, and 
can 
be done in a startup command that preps the environment based on the data from 
the 
applicationContext xml. Since this stuff is mostly registration of objects you 
could 
do it outside like in a main application class, or command etc.

Hope that helps.

-ds

P.S. I haven't been able to do much improvements in recent times. Sorry about 
that...

Original comment by darshan....@gmail.com on 19 Feb 2010 at 6:25

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Darshan,

Thank you for your response. It is a rather interesting way to approach it - to 
not 
follow the progression of pureMVC -> Spring Extensions -> Fabrication but 
rather use 
Fabrication Interceptors to introduce the cross-over dependency into Spring 
Actionscript and its extensions. Hmm... -) 

Since it would be building on top of Fabrication, how certain are you about its 
architecture underpinnings not having fundamental changes at the core? I know 
you 
said you had ideas about changing a few approaches around.

Thanks,

Alex

Original comment by a.mikhai...@gmail.com on 19 Feb 2010 at 10:51

[GoogleCodeExporter]

I'm thinking that if many modules are involved, it would be beneficial to have 
DI is 
some and not in others. One useful abstraction that has become possible with 
the easy 
multi-module notification, is the use of modules almost as compiled libs. The 
interceptors idea supports this notion since you probably match against some 
interface.

I have a few ideas that might improve on the respondTo syntax. Namespaces can 
be used 
to implement DI-esque injection implicitely. However this will be an alternate 
syntax, the respondTo style will remain and work alongside it.

Regarding Interceptors, this has been an extremely useful feature for me so 
far. I 
don't see any reason to change it at the moment.

-ds

Original comment by darshan....@gmail.com on 22 Feb 2010 at 12:40

[GoogleCodeExporter]

Hi Alex,

If you chek latest version of Fabrication you can find a simple idea of IoC 
mechanism implemented for dynamic injection of actors into mediators, commands 
etc. If you find this interesting, and if you have other ideas how to 
add/improve this more - just let me know.

Original comment by rafael.s...@gmail.com on 14 Jul 2010 at 11:58