puremvc
|
|
« Reply #1 on: March 15, 2008, 04:40:25 » |
|
Hi Spacecom,
To clear things up, the 'Modularity' string is merely a key for the main application's Core.
Just like we register Mediators and Proxies by name (using a NAME constant if they don't need to be multiply-instantiated) we're doing the same with Cores. The string gets passed to the View to as the key for the unique View instance for the Core, to the Model as the key for the unique Model instance, and the Controller and Facad likewise.
You will also note that the way this string is created for the widgets allows multiple instantiation of the widget. It appends a unique URI for the widget (for the most part guaranteeing that other companies won't use the same string), and adding the id of the actual instance.
The Modularity cast in the StartupCommand is casting the reference to the application (passed in from the original facade.startup(this) call in the Modularity.mxml. It just happens to be the same as the string name we're using to register with.
The separate package spaces com.widgetmakers, com.widgetworks, org.puremvc were meant to illustrate the point that these could be third party widgets; flex modules created and compiled by other companies, but made to work with the host application. Something like Wallop.com.
And finally, if you're writing everything and your stuff all goes into the same top level package space, you'll still probably want to create separate applications for the modules and for the host app. And you'll want to create a library project to contain some interfaces that tell the module how to talk to the app and vise versa. (See IWidget and IWidgetShell in the demo).
So you might have these projects:
Flex Library: co.za.myDomain.myapp.interfaces.*
Flex App: (has the interfaces swc in libs) co.za.myDomain.myapp.shell.*
Flex Module #1 (has the interfaces swc in libs) co.za.myDomain.myapp.moduleone.*
Flex Module #2 (has the interfaces swc in libs) co.za.myDomain.myapp.moduleone.*
-=Cliff>
|