RL MetaArchitecture for modular apps

6 views
Skip to first unread message

Stray

unread,
Nov 15, 2009, 8:12:46 AM11/15/09
to robo...@googlegroups.com
Wondering what people think about a small fork (supplementary) for
modular apps.

The application I'm using RL on is a modular Air app. Not modules in
the Flex sense - just in the 'separately compiled and loaded at
runtime' sense.

Each module will have it's own context and so on, but I was thinking
about creating a top level version that essentially replicates the
existing RL structure and flow, but with the view classes replaced by
a ModuleMediator - Module pairing. I think all the classes would stay
as-is except that view / module swap.

I have been playing with Robert's As3 Signals stuff as well, but there
are obvious advantages to the existing RL decoupling approach for
modules that don't have a clue about each other.

What I was thinking of was:

1. All inter-module data goes via strongly typed Data Transfer Objects
which have property accessors but no functionality.
2. Those DTOs are required parameters of strongly typed events - the
event classes would be dictated by the DTO required.
3. Inject the (strongly typed) events into the Commands wired to them.
4. Command.execute passes the DTO to the modules that need them as it
runs their API functions...

So - what are the advantages / disadvantages to passing those DTOs via
parameters in functions / Injecting them?

I'm guessing that passing by parameter makes my unit testing easier...
but I wondered whether I should be Injecting them instead?

Obviously I'd also like to create the ModuleMediator classes
spontaneously as required...

My app actually looks like DumbAirShellThatJustVerifiesModules ->
ModuleManager -> Modules. The dumb air shell can't be updated, but the
moduleManager that would contain this context / logic / super event
bus can be, so API changes in the modules can be handled that way.

I'm still fighting TextMate to get output from git when the RL bundle
does its thing, so this is a few days away, but does it sound like a
sensible approach? I saw a module demo but it's flex modules I think,
which is a bit different.

Jesse Warden

unread,
Nov 15, 2009, 8:19:17 AM11/15/09
to robo...@googlegroups.com
How are yours different from Flex modules?  The whole point of Flex modules were to create an app that still allowed strong-typing, yet prevented you from caring mostly about who used what.  Using the mxmlc's ability to compile only the classes your module needed, you still got everything you needed.  Using RL's loadModule, or even just module level Contexts, you should be fine using the compiler's built in ability to detect these things.

I understood the need behind PureMVC pipes, even if I disagreed with it's implementation.  I don't, however, understand the need for modifying the current RL to support modules when... well, it already does.  Please keep in mind I'm still hung over from #riaunleashed, and am only on cup 1 of coffee.

Stray

unread,
Nov 15, 2009, 8:22:11 AM11/15/09
to robo...@googlegroups.com
Thanks Jesse - I think maybe I've missed something... *goes back to read code again*... would be good to not have to do the work if it's already working!

Sean Clark Hess

unread,
Nov 15, 2009, 8:23:09 AM11/15/09
to robo...@googlegroups.com
I never did pick up how contexts were supposed to "communicate" with each other. The docs mention it, but never explain how. Is it simply a matter of injecting to a context?

Jesse Warden

unread,
Nov 15, 2009, 8:34:49 AM11/15/09
to robo...@googlegroups.com
There isn't a global event dispatching mechinism like PureMVC's notifications.  You could use Robert's Signalz.

Out of curiosity, what is the use case you have for Context' talking to each other?

Stray

unread,
Nov 15, 2009, 8:36:28 AM11/15/09
to robo...@googlegroups.com
Jesse, I can't find 'loadModule' anywhere in RL... am I being dumb?

That's exactly it Sean - it's the inter-context communication I was thinking about. In my mind I had a (super? meta? parent? - dammit, all those words have other meanings)-RL that basically provides the same flow but for contexts instead of views... the module mediator would in many ways be a context mediator really.

Stray

unread,
Nov 15, 2009, 8:43:17 AM11/15/09
to robo...@googlegroups.com
In my case, each functional area of the app is provided by a different module. It's a large e-learning environment and there are elements like in-lesson navigation, stats, quizzes, background material library, definitions and footnotes and so on which different sub-companies of the client want to be able to tweak.

The lesson-runner will have things happen - for example reaching a lesson checkpoint - that the stats viewer, lesson menu selector, library menu and logging tool (which reports back to the server) all need to be made aware of. Each of those modules will have a context, but inter-module communication needs a context too. Of course I could just use conventional structures for that but then we wouldn't have a need for robot legs if the injection / context wasn't useful!

So - I'm not suggesting any changes to RL but that I was thinking that an uber-level RL that can handle comms between RL context based modules is what I need. As far as I can see I'd really only need to add a ViewMediator alternative that is for Modules instead.

Jesse Warden

unread,
Nov 15, 2009, 8:50:14 AM11/15/09
to robo...@googlegroups.com
Sorry, it was mediatorMap.mapModule.

Jesse Warden

unread,
Nov 15, 2009, 8:53:18 AM11/15/09
to robo...@googlegroups.com
While I'd argue from a Purist standpoint that you should organize your application around having a Context that should be able to direct all requests amongst the actors it has... that isn't very flexible or practical.  And in using PureMVC with AIR, I totally understand the need you have and where you're coming from.  So, again, in that cast, I'd add Robert's Signalz or something similar atop your Contexts.  I would suggest you wrap it in a base class on top of Context to ensure you only allow the use of signals from Contexts since the beauty of RL is it's use of the existing Event architecture and you don't want to muddy it up too much.

Stray

unread,
Nov 15, 2009, 9:06:41 AM11/15/09
to robo...@googlegroups.com
Thanks Jesse.

I'm not sure I really understand why it's not practical / flexible when compared with AS3 Signals?  Tell me more about that if you can... 

It seems to me that the intra-module pattern that RL implements is a pretty good fit for an inter-module pattern as well.. and I quite like the idea of only occupying brain / documentation space with that RL way of doing things once - but that's just personal preference and also to make it easier for others to follow what's going on.

Having said that - strapping AS3 Signals to my contexts (by composition) on a per-module basis is exactly what I was planning before I wondered whether there could be a composite pattern implementation of RL... with baby RL inside the giant RL on the outside.  Maybe I've just got RobotLegs fever?

I'm still hunting for that mapModule function - I'll go back through the git repo and check if it was removed or something.

Jesse Warden

unread,
Nov 15, 2009, 9:11:13 AM11/15/09
to robo...@googlegroups.com
Naw, I was agreeing with you.  Meaning, having to look at your application as a whole, and think where you can strategically place Context's just so you don't HAVE TO have a global notification framework is, to me, trying too hard to satisfy the purists.  Being pragmatic is what allows you to get things done, so using something like Signalz, or a global EventDispatcher instance... while not "best practice" still work wonders.

The reason Singletons, messaging frameworks, and globals exist is not because people want to piss others off, but merely because there is a need for them.  So use it/them.  Just understand the ramifications of doing so.

See my other response, it was mediatorMap.mapModule.

Stray

unread,
Nov 15, 2009, 9:12:38 AM11/15/09
to robo...@googlegroups.com
Ah, I can see now that mapModule got merged into mapView in this commit:


*thinks about it all some more*

Stray

unread,
Nov 15, 2009, 9:18:59 AM11/15/09
to robo...@googlegroups.com
Ah - gotcha. That makes a lot of sense.

Well - both As3 Signals and RL are already beautifully functional - so I guess it's just a case of working out where the least pain (or even most joy?) lies :)

Sometimes the least pain is in the structure that you'll be able to explain to some other developer in six sentences if you suddenly find you're out of action... !

Stray

unread,
Nov 15, 2009, 9:21:26 AM11/15/09
to robo...@googlegroups.com
Just checked out the update to the mapMediator -> mapView change.

I guess as all my modules are swfs, and thus movieclips, I can already use RL for this out of the box, by just mapping them as if they're views?  The RL context acting as the top level container doesn't / shouldn't care that those views also happen to be their own little RL apps.

Now, that sounds like a high-joy/low-pain solution...

On 15 Nov 2009, at 14:11, Jesse Warden wrote:

Shaun Smith

unread,
Nov 15, 2009, 9:24:44 AM11/15/09
to robo...@googlegroups.com
6 sentences eh?

An IContext guarantees an IEventDispatcher
An IContextProvider (yuck!) guarantees an IContext
IMediatorMap.mapView() can accept a string as the first param, and interface as the third param

That should be all you need to build a modular architecture in AS3 (no Flex required!).

I guess I need to knuckle down and put together a better example than the AcmeWidgetFactory!

Jesse Warden

unread,
Nov 15, 2009, 9:25:11 AM11/15/09
to robo...@googlegroups.com
My guess as to why that was supported was to support the easiest way to make modules: dumb View's.  Once you have modules that have significant amounts of functionality, and include their own framework code... there becomes less of a need to have a global Context to map them.  Meaning, you can just have a Loader/SWFLoader load in your SWF, and as long as it can still participate in the global affair via Signalz, then it's encapsulated as can be.  However, once you start to want it to participate in the existing Commands/Services architecture... then you should map the view.

I have no clue what's best... it really depends on the scope of the module, and how much work it has to do, but it sounds like you already have it figured out.

Jesse Warden

unread,
Nov 15, 2009, 9:26:14 AM11/15/09
to robo...@googlegroups.com
If you make an AIR specific one, I think that'll help.  In a web page, it's easy.  Once you start adding "Windows" the mix, that + the one Joel created, it's cool... but more the merrier.

Stray

unread,
Nov 15, 2009, 9:39:59 AM11/15/09
to robo...@googlegroups.com
Fantastic!

I'll give it a whirl... and weirdly I hadn't really realised that AcmeWidgetFactory applied here, though I can see it does now :)

Shaun Smith

unread,
Nov 15, 2009, 9:44:31 AM11/15/09
to robo...@googlegroups.com
Just to expand on the main point there: MediatorMap.mapView() allows you to map a Mediator from the shell to the string name of an external concrete view class (your module) and then inject that view as an Interface (to act as a bridge to that module).

If the Interface is IContextProvider then you have access to that module's IContext, which in turn gives you access to it's IEventDispatcher. It's then up to you to decide how much coupling you want to do based on the Event classes that you compile into the shell and modules.
Reply all
Reply to author
Forward
0 new messages