Is the Shell's primary deal to load modules? If so, where does this happen?
This can happen anywhere, but a good place is in a Mediator because it can send and receive notes, and be the one touch point in the Shell for dealing with the Module(s). In this respect it is no different from a Mediator that instantiates its own view component and ships it off to the StageMediator or ApplicationMediator to be added to the view hierarchy, it is just loading the Module instead of instantiating it.
The 'getting started' tutorials I've read show the modules being created in a variety of Classes: in the Shell's Document Class, another in the ShellMediator - what is best practice here?
It really depends upon your overall architecture and when you need the modules to be available. PureMVC doesn't impose any limitations on this, it's only meant to facilitate the code separation and communications between modules.
Is there a utility for managing this?
There is no utility as yet, although I've thought that the Loadup utility might eventually be extended to handle it. There is the Imajn project (
http://imajn.com) which handles all this, but it is still a month or so away from the beta kicking off. You can sign up for it, now though and be notified when it's open.
most of the getting started tutorials house the Shell and all Modules in sub-packages of the same application, ie: src.com.myapp.shell, src.com.myapp.moduleA, etc, but is this actually modular beyond packaging?
Packaging and interfaces are the biggest key to achieving modularity.
The demos house everything in the same project for convenience only. If, for instance the Modularity demo were broken into the shell project, the common project and separate projects for the widgets, it would be waaaaaay more cumbersome for people to get up to speed and actually get something working.
To achieve the modularity that you want in production all you have to do is:
1) split the packages off into separate projects,
2) compile the common package as a library,
3) add that to the shell and module projects
4) compile the modules
5) load or instantiate the modules in the Shell
If they weren't already packaged properly, you'd have a big ugly refactoring job on your hands.
Of course once you've broken this into multiple projects, you now have a logistical problem getting the library built, the modules and the shell, and keeping them all in sync.
For this, you need to write an ant script. You cannot manage a truly modular project from within the Flex Builder IDE, there's too much setup involved (meaning new team members have trouble getting started).
Your ant script will have targets for building every piece, which make sure the dependent pieces are built first.
I prefer to create modular sections of the application that can run on their own, this way I don't have to compile and wade through an entire application to test each Module. I'm sure this is standard for most developers, however, in PureMVC, how would this handled exactly?
You can certainly do this. Your module should not care where it is loaded (or instantiated) as long as it implements an interface and/or a message protocol using pipes.
Therefore you can create a simple 'jig' a Flex app that simply instantiates your module, invokes methods on it or plumbs it and has a conversation with it over pipes.
-=Cliff>