Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Best place to handle module loading  (Read 8479 times)
lowpitch
Jr. Member
**
Posts: 10


View Profile Email
« on: August 26, 2008, 11:21:50 »

ello,

Just a quick question - in an app using Pipes for dynamic module loading, where do you reckon is the best place to handle the loading of the module (integrating with ModuleManager, listening for progress / setup / ready events etc).

Off the top of my head, it seems like this should go in a Proxy which can handle loading of modules, with each load triggered by a Command. The Proxy can handle the loading of the module, then when loading is complete, a notification is sent out (perhaps with the module's factory in the notification body). Any interested parties can then do what they want with the module once they know it's loaded.

I think this makes more sense than putting it in a Mediator or Command.

I'd appreciate any insight or thoughts.

Cheers!
Toby
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: August 27, 2008, 08:29:32 »

I use a custom Shell apparatus that handles loading, instantiating and pooling of modules, and though it has no visual aspect, and modules are loaded dynamically (like loading data), I still feel it belongs in the View tier, because it is loading Modules, which are generally used to dynamically compose the UI, and do not themselves represent the Model.

And practically speaking, using a Mediator to manage this Shell allows me to interact with it much easier since it can not only send but also receive Notifications.

-=Cliff>
Logged
lowpitch
Jr. Member
**
Posts: 10


View Profile Email
« Reply #2 on: August 27, 2008, 02:53:35 »

I take your point, but it still feels a little wrong to me as the ModuleLoader Mediator wouldn't actually be mediating anything, it's just providing a way to create the modules from the IModuleInfo object's factory. It feels almost more like a data store.

The approach I've taken seems strangely similar to one mentioned very recently in another thread on this forum. I have a ModuleLoaderProxy which handles the physical loading of the modules. When myModuleLoaderProxy.load (someUrl) is called, I make a call to ModuleManager.getModule (someUrl) and store the returned IModuleInfo in a lookup. If the module is loaded for a second time, I've already got that IModuleInfo object and I just call "load" on it again, sending out a Notification when the ModuleEvent.READY event is received. This'll work the same way whether the module is loaded the first time, or on subsequent attempts.

Interested parties can then listen out for this Notification, and if they then want to create an instance of the module they can get access to the IModuleInfo object (and therefore the Module's factory) through the ModuleLoaderProxy and then do what they want with it.

I'm treating the loaded modules in the same way as I would any data that's loaded in from the server. I store it in a Proxy and then anyone who wants access to it can retrieve it from there. All load / IOError handling is handled within the Proxy (just as it would be if I were loading an XML file, or calling a webservice).

It's working well so far (although I only coded it yesterday and haven't fully tested all my use cases yet) - I'm more than open to adjusting my thinking if it can *click* for me for the module loading process to be part of the view, not the model, but as yet I'm not fully convinced.

Do you think it can make sense to treat the loaded module data in the same way as any other data loaded from the server?

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: August 27, 2008, 04:32:10 »

I'm not mediating ModuleManager. I'm mediating the Shell apparatus I mentioned. It takes a configuration vo to know where the modules are, what they're for and how many instances to create right away.

Jist because they are dynamically loaded like data doesn't make them part of the domain model.

-=Cliff>
Logged
lowpitch
Jr. Member
**
Posts: 10


View Profile Email
« Reply #4 on: August 27, 2008, 04:43:07 »

Ok - interesting. I'll give it some more thought ;o)

I still kind of like them sitting in a Proxy, although I agree they don't form part of the Domain model. I think I just need to do a little more thinking about it all.

Thanks for input.
Logged
Pages: [1]
Print