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: Modularity string name  (Read 6904 times)
spacecom
Newbie
*
Posts: 6


View Profile Email
« on: March 13, 2008, 11:06:33 »

I would like to know what is the string name=Modularity importance and how they work together?

1. In the Modularity.mxml which is set as a constant .
2. In the ApplicationFacade.as the name "Modularity is set in the startup function. Does the name in the mxml file tie up with this. Is the name Modularity due the the folder name modularity under your org folder?
3. In the starupCommand.as the name Modularity is set in the excute function as well. Does the var app: Modularity name refer from the ApplicationFacade.as. ?

Secondly the root folder names are org and com respectively. I would like to ask how I would setup my project root when I using a domain name as root folder co.za.'myDomain to contain the sub folders for the canvasWidgets (your root folder org). What do I name the the root folder for the multitons when I have already used the co.za.'myDomain name?

Do I have to use a second domain name as you have eg: com.widgetmakers? What would yur advise be?

PS. We are now upgrading a long standing web based enterprise software package built in CF 7 to use the new framework. We congratulate you and your team on a job well done.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« 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>
Logged
Pages: [1]
Print