Child Module CAN NOT map root events to commands?

[TJ]

Hello,

I have a multi module project where several of my modules share
services, so these services and their controllers are in the root or
shell of my application. I am able to use the scope attributes for
dispatcher and event handling just fine, but I ran into an issue where
a service in my root sends an event which I tried to map in the swiz
of my module (child) and it cant seem to catch the event. Using the
[EventHandler] in a presentation model in the module verified the
event is being sent and can be caught.

So I am to assume that commands mapped in a module can only listen for
local events and not global by default. If this is the case, is it
possible to have a command in a module mapped to a global event?

[Brian Kotek]

It is possible. You can see it working in the example application on Module communication: http://tinyurl.com/85xeazl

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

[TJ]

Hey Brian,

Yes, I see in the module example the root events being handled by the
[EventHandler] tag in the module's PModel. I have this working in my
app. What you example does not have is a CommandMap class mapping
root events in Module1 to some command classes residing in Module1
Swiz.

So what I am trying to do is inside my Module1CommandMap:

mapCommand(RootEvent.ROOT_EVENT_FLAG, SomeCommandInModule1,
RootEvent);

My command classes (extended from ICommand or IEventAwareCommand)
living in my Module1 Swiz can not be mapped to Root (global) events.

Right now the only solution I was able to create was to add a
GlobalEventController to my Module1 Swiz, have it listen for global
events using [EventHandler] and then dispatch 'local' events that are
mapped in the CommandMap to execute my various commands... Granted
this will work, but it seems like I'm having to code a solution for
something the framework should already do.

[TJ]

Well, not exactly. Your application shows global events being handled
by the [EventHandler] tag in Module1. I have this working in mine as
well. The problem is I have a CommandMap in my Module1 and global
events I have mapped will not trigger the mapped commands:

// In my module 1 command map class:
mapCommand(RootEvent.SOME_EVENT_FLAG, SomeModuleOneCommand,
RootEvent); // This does not work.

The workaround I created for now was to add a GlobalEventController
class, handle the global events using the [EventHandler] tag, and then
re-dispatching them with a local dispatcher so the Commands in the
Command map will respond to them.

This seems a bid redundant. Is there something I have missed about
setting up the CommandMap to listen to global events?

On Feb 8, 11:06 pm, Brian Kotek <brian...@gmail.com> wrote:

[Brian Kotek]

Hmm it sounds like it could possibly be a bug in the command map then. If you create a very simple test application that demonstrates the problem and sent it over I can take a look.

Thanks,

Brian

[TJ]

Hey Brian,

I made an example and put it on my server. It's exported as an FXP
but I zipped it so the server would allow you to download.

http://67.239.69.29/swiz/ModuleCommands.zip

[Brian Kotek]

By the way, are you getting an error or a message in the console log?

[TJ]

No. Just normal confirmation of startup and module decompression:

[SWF] D:\_FB4.5\ModuleCommands\bin-debug\ModuleCommands.swf - 312,582
bytes after decompression
[SWF] D:\_FB4.5\ModuleCommands\bin-debug\ModuleCommands.swf\[[DYNAMIC]]
\1 - 1,218,469 bytes after decompression
[SWF] D:\_FB4.5\ModuleCommands\bin-debug\ModuleCommands.swf\[[DYNAMIC]]
\2 - 763,122 bytes after decompression
[SWF] D:\_FB4.5\ModuleCommands\bin-debug\ModuleCommands.swf\[[DYNAMIC]]
\3 - 445,616 bytes after decompression
[SWF] D:\_FB4.5\ModuleCommands\bin-debug\ModuleCommands.swf\[[DYNAMIC]]
\4 - 2,020,590 bytes after decompression
[SWF] D:\_FB4.5\ModuleCommands\bin-debug\com\moduleCommands\moduleOne
\MyModule.swf - 164,494 bytes after decompression
module created

[Brian Kotek]

Looks like a limitation of the CommandMap. Currently it attaches its event listeners to the Swiz dispatcher, which is local to the Swiz instance. In this case, in order to listen for events from the parent app it would need to attach the listener to the globalDispatcher. I'll try to ping Ben to see if this is by design, or if it would make sense to change CommandMap to use the globalDispatcher.

For now, in your CommandMap subclass, you can override mapCommand to remove the listener from the local dispatcher and add it to the global dispatcher. Something like this:

override protected function mapCommand( eventType:String, commandClass:Class, eventClass:Class = null, oneTime:Boolean = false ):void

{

super.mapCommand( eventType, commandClass, eventClass, oneTime );

_swiz.dispatcher.removeEventListener( eventType, handleCommandEvent, false );

_swiz.globalDispatcher.addEventListener( eventType, handleCommandEvent, false, 0, true );

}

BTW, once I got it working I ran into an error in your code. Your injection for model in HandleRootEventCommand needs to be public.

[Brian Kotek]

To add, you'd probably want to avoid any lingering listeners on the global dispatcher by overriding unmapCommands() as well, something like this:

override protected function unmapCommands():void

{

for( var eventType:* in map )

{

_swiz.globalDispatcher.removeEventListener( eventType, handleCommandEvent );

delete map[ eventType ];

}

map = null;

}

[TJ]

Hey Brian,

Thanks for this bit of help. So, is it possible to have 2 command
maps in an application where one is for local and one for global? I'm
thinking this would be my best route for a solution in my application
since I have some services that are global in the root and some that
are local as well.

TJ

[Brian Kotek]

Exactly. If some are local and some are global, I'd probably keep them in two separate classes (and use a descriptive name for each one) even if CommandMap had some built-in way to specify local vs. global, just for clarity. 

[TJ]

Hey Brian,

FYI - This worked like a charm. I have a shared common library so I
created a class called ApstractGlobalCommandMap adding the above
functions and just inherit from that class. Works like a charm!

TJ