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: AS only and Multicore : problems w/ ModuleBase  (Read 9760 times)
pebanfield
Full Member
***
Posts: 33


View Profile Email
« on: January 16, 2009, 08:59:17 »

I'm looking at whether to try to use the multicore version for my AS3 only project. So far I've successfully created a module with ModuleBase. This gives me the ability to optimize linking for the containing application and best of all I get the little blue icon in FlexBuilder. Sweet! (Strangely the compiler initially places the .swf in the class directory rather than the Output directory, but then it started updating on compile once I moved it. A bit confused about this.)

Unfortunately, there is very little documentation for non-Flex framework modules, but I would like to try to make it work with multicore. My first problem is that ModuleBase does not apparently extend a DisplayObject class and so I was unsuccessful in trying to add my module to the stage. I tried to cast the module but no luck. Anyone know what I'm doing wrong with that? I thought .swfs were intrinsically display objects?

Anyways, as a work around I've winded up making the ModuleBase derived class a display object factory of sorts and pass the objects to my main application to be added to the stage when appropriate. This gives me the benefit of smaller downloads, but leaves something to be desired on the application scalability side.

At this point I'm thinking of abandoning multicore to just use a single core that loads modules that are simply view libraries, but of course this does not give me the benefit of scaling my control logic with multicore. Another idea is to have the ModuleBase derived class create an application runner class that extends Sprite and in turn sets the facade instance as normal. I think this probably makes the most sense if I can make it work?

On this last point - it seems like it would be practical for modules to have a way to send notifications via their own facades and the parent facade. Not sure if this makes sense. Perhaps this should be avoided as it breaks encapsulation? Thanks.

Peter

« Last Edit: January 16, 2009, 09:49:50 by pebanfield » Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #1 on: January 16, 2009, 09:47:03 »

Another related point - I think it would also be handy to retrieve proxies from a parent core. Any thoughts on this? Thanks.

Peter
Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #2 on: January 16, 2009, 09:51:23 »

OH crap - it just occurred to me. Is this what this Pipes utility is for? :)
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: January 18, 2009, 07:23:05 »

ModuleBase is a Flex class, just not an MXML tag.

You don't have to add a module directly to the stage as a display object. Once loaded, you can ask it to give you a display object that it will mediate internally.

Check out the PipeWorks demo to see how this concept works. Yes, its Flex, but you'll learn from it neverthelss.

-=Cliff>
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: January 18, 2009, 07:28:23 »

And yes, Pipes is for intercore communication. Don't try to ger refs to facades inside cores and mix notifications between them. You have to control the entire notification namespace in every module which puts 3rd party widget development right out the window. You may control everything in your app and modules, but that's the only way
It can work and therefore not a best practice for an industry bent on outsourcing.

-=Cliff>
Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #5 on: January 19, 2009, 09:46:33 »

Thanks Cliff - yes I am going to check out the Pipes as I've encountered another important flaw in my approach. I've realized that my approach was bad because it meant that the compiler is importing all the view classes into the parent/shell app instead of my ModuleBase derived class.

I understand that ModuleBase is in the Flex framework, but I was explictly using it because I don't have the luxury of importing the Flex UI framework into this particular app as I need to keep the file size down. Compiling my view classes into the shell caused it to be the more file heavy class, which is not what I wanted. Looking back at your Modularity example I think I am now seeing the benefit of using interfaces at the shell level.

I've run out of refactor time for this iteration, but hopefully I can make this work better next time around. Unfortunately, the technical debt here is going to mean my shell swf gets larger as my module view gets larger. :( The problem with my design is that I am setting view properties on state instances in a shell swf mediator. Hopefully creating some interfaces with solve this problem for me.

Peter

Logged
Pages: [1]
Print