I've noticed that the "InputCommand" in the input module is dispatching "CanvasEvent" events... And also, the "CanvasModule" is dispatching "ShellEvent" events. I understand if you were just doing this to quickly wire up an application, but I'm wondering, in regard to making a reusable modular app, wouldn't you want to make sure that each module DOES NOT import anything outside of its own package? Isn't it part of the point to have a module in such a state that I can simply build a new RL shell, grab my old module, pop it in and send it its own events...?
It seems as though with the way you have this example built, in order to reuse a module I built for an old app, I would require me to open it up and change the events/commands and so on and so forth in order to get it to work with a new project. Wouldn't it be best to be able to simply import the necessary classes from my module into my new shell, and then simply dispatch the modules' own events from the shell to the module? And furthermore, couldn't the shell act as sort of a 'translator' to help modules talk to one another without having to couple them? For instance: my 'InputModule' dispatches an input event which is picked up by the shell, the shell then translates this to a 'CanvasEvent' and the shell dispatches that to be picked up by the 'CanvasModule'. That way both modules could care less about each other, and if built right, I might never need to open them up again...
Maybe I'm not seeing things right, but as of now, this seems like the most logical way to use these modules... To NEVER import a single class out side of its own Module package (unless its a dependency like TweenMax or RL of course).
What do you think? I'm still trying to figure this all out, so any kind of reply is more than appreciated!
Great post! I do have some questions/concerns...
I've noticed that the "InputCommand" in the input module is dispatching "CanvasEvent" events... And also, the "CanvasModule" is dispatching "ShellEvent" events. I understand if you were just doing this to quickly wire up an application, but I'm wondering, in regard to making a reusable modular app, wouldn't you want to make sure that each module DOES NOT import anything outside of its own package? Isn't it part of the point to have a module in such a state that I can simply build a new RL shell, grab my old module, pop it in and send it its own events...?
It seems as though with the way you have this example built, in order to reuse a module I built for an old app, I would require me to open it up and change the events/commands and so on and so forth in order to get it to work with a new project. Wouldn't it be best to be able to simply import the necessary classes from my module into my new shell, and then simply dispatch the modules' own events from the shell to the module? And furthermore, couldn't the shell act as sort of a 'translator' to help modules talk to one another without having to couple them? For instance: my 'InputModule' dispatches an input event which is picked up by the shell, the shell then translates this to a 'CanvasEvent' and the shell dispatches that to be picked up by the 'CanvasModule'. That way both modules could care less about each other, and if built right, I might never need to open them up again...
Maybe I'm not seeing things right, but as of now, this seems like the most logical way to use these modules... To NEVER import a single class out side of its own Module package (unless its a dependency like TweenMax or RL of course).
What do you think? I'm still trying to figure this all out, so any kind of reply is more than appreciated!
Thanks again for the awesome example! Great work!
-j