Module support ideas

2 views
Skip to first unread message

Christophe Herreman

unread,
Nov 25, 2009, 5:53:44 AM11/25/09
to springactionscript-dev
Hi all,

while we currently have basic module support, we would like to discuss
use cases with you and get some feedback on how modules will be used
in certain scenarios and expand Module support based on those ideas.
This should also help us to decide what to include in the 0.9 release.

Here are some use cases for loading modules, in all of which the
Modules do not have an own application context. Looking forward to
your input and feedback.

***

1) Module is merely an extra view in the application and it does not
have an own context: autowire works by default (if enabled in the app)
and the module has access to all objects from the context via
autowiring.

- No config is needed.

2) Module is merely an extra view in the application, it does not have
an own application context, and we don't want it to access objects
from the app context through autowire. In other words, autowire should
not not be enabled for modules that are loaded.

- How do we configure this? Do we set a flag on the
FlexStageProcessorRegistry, so it knows that it should ignore Modules?
This is an all or nothing situation. Either all Modules are allowed or
none.

3) Application loads several modules that don't have an own context
and we want to allow certain modules to use autowiring to access
objects from the application context.

- How do we configure this? Do we create some sort of a Module Policy
per module that allows or denies autowiring in modules? Should there
be a default setting that applies to all modules that are not
explicitely configured? If implemented this way, this would also solve
use case 2.

Santosh Kumar

unread,
Nov 25, 2009, 2:28:45 PM11/25/09
to springactio...@googlegroups.com, Christophe Herreman
Hi Christophe,

Below are my thoughts

In general Modules are classes just like application files.One key point about Module "By default, a module is loaded into a child domain of the current application domain". Meaning "Because a module is loaded into a child domain, it owns class definitions that are not in the main application's domain"

Why?

Simple answer is child Application domain can be unloaded. That's the core benefit of it.

Scenario 1:

"All class definitions inside modules are defined in application domain"

I would like to vote for use case 1(No config is needed) Autowire for modules if and only if all the class definitions in modules are defined in application domain. 

Scenario 2:

"All class definitions inside modules are not defined in application domain" 

Then it should be configurable as per need basis for auto wiring for modules then i would like to vote use case 3(certain modules to use autowiring to access objects from the application context.)

Scenario 1 Vs Scenario 2:

I think Scenario 2 is overall safest bet.. because if we allow scenario 1 there might be cases where some class definitions are found in both two modules but not defined in application domain, First Module alone registers that classes (First Come First Serve) if another module tries to access the same class then we get Flash Player exception, one good example is definition of Managers(PopupManager,DragManager etc) definitions are found  inside one module not defined in application domain then another module tries to access same Manager classes then Flash player will throw an exception. 

It should be treated case by case basis whether all the module class definitions should appear in application domain or some appear in application domain that are commons while specific ones will appear inside module itself.

So scenario 2 will solve the above problem by allowing the user configuration. So finally i vote for use case 3(certain modules to use autowiring to access objects from the application context. We should also take a look at feasibility of addressing both scenarios  will be of great benefit.

How about RSL's?

No worries,  because all RSL's are loaded in parent application domain so we don't need to worry about auto wiring for it


Regards,
Santosh Kumar



--

You received this message because you are subscribed to the Google Groups "springactionscript-dev" group.
To post to this group, send email to springactio...@googlegroups.com.
To unsubscribe from this group, send email to springactionscrip...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/springactionscript-dev?hl=en.



Reply all
Reply to author
Forward
0 new messages