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: More getting started with Multicore questions...  (Read 7791 times)
sideDoor
Full Member
***
Posts: 25


View Profile Email
« on: April 12, 2010, 09:18:55 »

I've been studying hard on best practices, run through tutorials, searched and read posts, and there's still some general Multicore structural stuff not clear to me, so please forgive me if I ask a pile of basic questions here, many of which maybe well known to the community.

1. Cores: Shell (or other common names like Application, Main, Index) vs Modules?  Is the Shell's primary deal to load modules?  If so, where does this happen?  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?  Does it matter where they are loaded?  Is there a utility for managing this?

2. Using/loading actual Modules:  Again, 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? 

In building non-Flex AS3 applications, 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?  Should I load into the Shell (when I find out where it is best to do so) an swf file (a Module) typed to an Interface?


I'm sure I'll have many more questions, thanks very much!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: April 13, 2010, 08:28:00 »

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>
Logged
sideDoor
Full Member
***
Posts: 25


View Profile Email
« Reply #2 on: April 13, 2010, 06:43:20 »

Wow, many thanks for your time, I greatly appreciate it!

Points 1 through 5 really clarified for me how to proceed in a production environment!  Thanks so much (and I might as well end this sentence with an exclamation mark, too)!

Another question (sorry, I'll have many, really sorry...):

What about privatizing the key, or using a unique ID, for each core?  I've read a bit about this on some posts, like here:

http://www.as3dp.com/2009/07/22/a-non-flex-actionscript-example-of-a-puremvc-multicore-application/#comment-3018

Would you be able to expand on this practice?

Thanks again!

sd
« Last Edit: April 13, 2010, 08:54:01 by sideDoor » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: April 14, 2010, 08:59:39 »

Chandima's thoughts on that are pretty good:

An exposed core key is like a global variable that exposes everything inside a core. If this is desirable in an application I don’t see a problem with it.

One of the big advantages multicore brought to the table was better testability. Allowing each core to be independently tested. You can only do this if access to cores are controlled (e.g. via interfaces) and inter-core dependencies are injected ( e.g. setApplicationShell — setter injection ).

Exposing a core key and allowing another core to access its proxy creates a hard dependency between the cores. Much like class ‘A’ accessing a public method in Class ‘B’ makes ‘A’ dependent on ‘B’. It is more desirable to inject dependencies as it makes dependancies explicit.

I basically see three scenarios where you'd want to be concerned about the core names being exposed:

1) If there are security considerations (i.e. you're loading third-party modules which might turn out to be evil) you might want to spend a little time ensuring that the cores get runtime-generated UUIDs as names. So if your app had a core for managing the user's private info, you wouldn't want that to be named by constant. Otherwise, by looking at disassembler output, the writer of the evil module would know to request the 'USER_STUFF' core, and start plundering.

2) If you are on a team where everyone isn't up to speed with best practices, or the app will later be maintained in legacy by another team who may not, then exposed core names could end up being problematic and possibly should be generated. Someone decides that they need something from another core, and rather than installing some plumbing and requesting it formally from the other core, they instead simply smash a hole in the wall and take it (i.e. fetch that core and request things they know are there, thus creating an inter-core dependency that completely negates the whole premise of modularity). This is the equivalent of doing parent.parent.parent.child.child.value, but some folks will go the brute force route irregardless.

3) Finally, if a core will be instanced multiple times, just like a mediator or a proxy, it needs a unique name, not a constant. Of course you can just tack an instance number onto the name if you'd like. The nice thing about including a human readable name is that it is helpful when you are looking at stuff in the debugger.

Otherwise, in an application where I control the horizontal and the vertical, I don't really mind, because I DON'T ever request another core by name. The multiton key is distributed to all the actors in a core, so their built in facade reference points to the right facade, and their sendNotification methods use that facade, so all the notifications remain inside that core. There is no reason to request another Facade, so the fact that their names are exposed does nothing to upset my code.

-=Cliff>
Logged
sideDoor
Full Member
***
Posts: 25


View Profile Email
« Reply #4 on: April 16, 2010, 06:17:08 »

Thanks!

For anyone interested, there's a cool AS3 Class that generates a relatively certain unique ID, which can come in handy with the above approach of generating Core keys at runtime. The Flex framework has the UIDUtil Class natively, but for pure AS3, there's no such thing.  Check it out here:


http://www.rgbeffects.com/blog/development/actionscript-3-guid-generating-unique-ids-for-users-in-as3/
Logged
Pages: [1]
Print