Modularity .. ?
Hi Guys,
I'm having an issue today, and cannot quite figure it out, although I presume the answer is somewhere in front of my nose.
This is the issue:
I have a main application, a Game, and a component that has it's
own Context and configuration and a class that manages the
component through public functions.
It works like so:
The game is instantiated and eventually it want's to create a new
instance of this module. For this it creates an OrderVO, that is
then passed to the module through a public function
module.getManager(order:OrderVO):IManage ... The getManager method
will prove that the order is correct and return a Manager that was
mapped as Singleton and created via
injector.getOrCreateNewInstance(IManager) . (btw. To this point
everything is still FINE). Then in the game I map the returned
Manager also as a Singleton so that my different Commands in the
Game can use the manager public methods.
The issue is the following!!!
The Injector for the Manager is the one from the Game! Although the
Manager was created succesully by the injector of the Module's
Context.
I did not passed the Context of the Game to the Module cause I really believed that it was unnecessary. One of my colleagues here suggested to try turning off the ModularityExtension, but this did'n brought me much either.
What do you think ?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Ondina D.F. on 17 Feb, 2013 11:53 AM
Hi Gustavo,
First questions:
What is the role of that Module?
Is the ‘Manager’ some kind of a Service class, accessing external resources? Are there more ‘Managers’ inside your Module, and you’re trying to access the right one, depending on some conditions?
Why don’t you use events to communicate with your Module? Say, the shell or other modules dispatch SomeModularEvent.USER_DATA_NEEDED to access UserService,
SomeModularEvent.LAYOUT_DATA_NEEDED to access LayoutService and so on. The results would be sent back to the shell or other modules via an event’s payload, SomeModularEvent.USER_DATA_LOADED, SomeModularEvent.LAYOUT_DATA_LOADED
Most probably I didn’t understand your use case, so please try to explain it better :)
Ondina
2 Posted by Gustavo on 18 Feb, 2013 08:35 AM
Hello Ondina,
The Module is a Service, I have other services that work correctly though and that are working through Event's communication as you described. I could make this module work the same way... non the less I still remain puzzled, and don't quite get how the Manager can not be registered to 2 contexts without passing the shell context to the module to work over it.
For example, my module manager works like a remote-control, offering public function to play, stop and pause the animation of the module. I could , like you suggested, make it work with event's... but can I also make the manager use internally the modules context and injector, while the shell has the Manager mapped on it's own injector? That is basically what I've been wondering the whole time.
Thank you for your reply :)
Support Staff 3 Posted by Ondina D.F. on 18 Feb, 2013 12:04 PM
Module implementing ISomeModule:
function getModuleService():IModuleService
return injector.getOrCreateNewInstance(IModuleService);
Shell:
moduleService=(moduleLoader.child as ISomeModule).getModuleService();
Since you got an instance already, you should map it like this:
injector.map(IModuleService).toValue(moduleService);
4 Posted by Gustavo on 18 Feb, 2013 12:27 PM
OHHHHHHHHHH!!!!
I got it !!!!
It was, as usual, Human mistake!... And that human, was ME !
Now, this is what I was trying to do.... I mapped the same Class Manager as a Singleton ion both the Shell and the module, and the tried to override the Singleton created by the shell with the one retrieved by the module thus a simple '=' operator.
And naturally, this did not worked on all other places where the Manager was Injected.
Then I changed this:
with this:
and Presto! all is now working nice and dandy!
I will anyhow refactor it to work via Signals... but my mind is in peace to understand what the problem was.
:)
5 Posted by Gustavo on 18 Feb, 2013 12:27 PM
YESSSS!!
I now see your response!
That was the way to do it ;)
Thank you Ondina
Support Staff 6 Posted by Ondina D.F. on 18 Feb, 2013 12:31 PM
You're welcome, Gustavo :)
Ondina D.F. closed this discussion on 18 Feb, 2013 12:31 PM.