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: Using Flex Modules with the single core version  (Read 7865 times)
dd
Newbie
*
Posts: 4


View Profile Email
« on: July 23, 2009, 09:47:22 »

I've just managed to take out a part of a project I'm currently working on, and make it compile as a Module, while still using the standard version of pureMVC framework. Reason for this is that we needed to manage our application size. Since some features are available to only some of our clients, and their size was 1/3 of application size, it made sense to just modularize them. And this was possible without switching to a multi-core architecture.
What I've done is make a startup command responsible for registering whatever elements the Module needed, including its cleanup command, and make the module send a notification trough Facade (thus avoiding a reference to ApplicationFacade) for the startup (just like the main application does). The cleanup command was then triggered by a notification sent from the main code base.
What also helped was the fact that all notification name constants were not defined in ApplicationFacade, but in a different class that had the sole purpose of defining them.
So, I can't help wondering if it's really worth it to switch from the standard framework to the multicore one. Since our Modules aren't really stand alone, but add functionality on top of the existing one, I'm really having a hard time seeing any advantages of such a change. Any thoughts on this?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 26, 2009, 12:00:17 »

Your shell and modules are still pretty tightly coupled in that their notification space has to be maintained in one place, and the shell has to have knowledge of what the module needs registered. It might work, but it's certainly not a design I'd want to advocate.

It would preclude things like isolated outsourcing of a module or a system where third parties contribute modules and you don't control the notification space.

-=Cliff>
Logged
dd
Newbie
*
Posts: 4


View Profile Email
« Reply #2 on: October 08, 2009, 03:36:36 »

The shell has no knowledge of what the module needs registered, although it gets registered under the same facade. That's the point.

I probably should have made clear what I needed. In the application I'm working on, the user logs in and is taken to a screen, based on his roles. It has a main navigator that can take the user to different screens, but not all users can access all the screens. And because the developing of certain screens made the application size pretty big, we decided to turn those screens into modules, and instead of having a ViewStack with all of them, just use a ModuleLoader. The idea was to have some code loaded only when it's needed, not having multiple modules loaded at the same time, in different areas of the application. So for this specific case, having the module fire his own startup command (just like the main application did) worked fine, and fast. Switching to the multicore version felt like an overkill.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: October 08, 2009, 07:26:56 »

If all the modules and the shell are registering their notifications in the same Facade, then you've got to manage the notification space as a whole. While you may be able to do that for one project you control, you don't get much reusability, since the modules, when taken to other projects may have namespace collisions with notifications already registered there.

Again, I wouldn't want to advocate this as a best practice.

-=Cliff>
Logged
Pages: [1]
Print