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: When to register Mediators of loaded content in a web based Flash project  (Read 9603 times)
mdw1980
Newbie
*
Posts: 5


View Profile Email
« on: November 13, 2008, 11:40:20 »

Recently I've been trying to use PureMVC for a web based Flash project in which I'm using the Flash IDE. For simplicity's sake, let me abstract the design a bit so that you may get a better idea of the design.

This application has what I call a "shell". In essence, this is the main application. This is where startup occurs and the ApplicationMediator is registered and mediates the root of the main FLA file. This shell is also the SWF file that is embedded into the HTML page.

The shell has a simple navigation that loads "sections" into the shell on demand of the user. Each section extends a base class, lets call it AbstractSection. Each section then also has a Mediator specific to it that needs to be registered at some point. This is where my dilemma resides.

Initially, I was registering the Mediator for a loaded section after is has been loaded in the shell. But then I realized I was importing all the section mediators into my ApplicationMediator, and thus all the code for each section and its mediators was getting compiled into the shell. This is making the shell much bigger than it should be and defeats the purpose of leaving each sections code to be contained within itself.

So I then started to wonder if I should register the Mediator of each section within the document class of each FLA, sort of like what happens with the shell to start up the application. This of course, required a reference to ApplicationFacade within each section and thus compiling the PureMVC framework and anything else I had imported into that class into each section.

I'm no OOP expert, but I'm very comfortable using PureMVC with a self contained Flex or AIR application. But this is really confusing me. I look to all of you for help and suggestions. I hope my explanation is thorough enough, but if it isn't I'll gladly explain more as I'm very anxious to figure out how to properly do this as I really like PureMVC.
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #1 on: November 13, 2008, 11:55:07 »

It sounds to me like you need a Multicore PMVC solution. Your Shell loads in a Section which is a SWF containing a new PMVC core. All you need then is a dynamic mediator in shell to control the loading/unloading/cleanup of the loaded Section.

You might also have a look at Fabrication if you need to communicate between the Shell and the Section loaded.

This lets you keep all the classes responsible for a Section within it's SWF and also get the benifit of it being it's own PMVC app making it easy to debug/test.


If you go the multicore route, you might want to check out http://blog.guttershark.net/?p=30#comment-34 for a solution to compiling Flash files with excluded classes - your Shell will already contain the PMVC framework so there's no need for each Section to also compile the framework in.
« Last Edit: November 13, 2008, 12:00:06 by jasonmac » Logged
mdw1980
Newbie
*
Posts: 5


View Profile Email
« Reply #2 on: November 13, 2008, 02:35:38 »

Aww man. I was afraid you'd say multi-core. Guess I have something new to learn then! As for now, I've dropped the use of mediators for the sections and have resorted to my old way of building things with highly coupled code in the sections. Its not all that big a deal as this is not an application in the sense that it needs to be easily modified or extended over time. Its simply a marketing website that will eventually die when the campaign is over.

Its been a great learning experience trying to use PureMVC in an "experience site" and I'm really looking forward to try and implement the framework in another site that may benefit from it more.
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #3 on: November 13, 2008, 02:57:42 »

Aww man. I was afraid you'd say multi-core.

It's almost exactly the same as the single core, the only difference is the use of a Multiton key. And of course gaining the ability to run multiple cores.

While the learning curve for PMVC can be quite steep, once you understand how things work your dev time will decrease dramatically. It's well worth the time spent learning.
« Last Edit: November 13, 2008, 03:02:18 by jasonmac » Logged
mdw1980
Newbie
*
Posts: 5


View Profile Email
« Reply #4 on: November 17, 2008, 02:22:34 »

So upon further investigation, I think I'm onto something. The Modularity demo gave me some insight. Basically it seems to be that I will treat each section as its on Application, giving each section a Multiton key, in other words, a unique id/key. Furthermore, each section will implement an interface. Lets say these are IShell and ISection. Once a section is loaded into the shell, a reference to the shell will be made within each section. Makes sense so far.

My only question now is if I want to send a notification from the shell, will that notification only be heard within the shell? If not, I'm guessing I'll have to expose an API on the sections, defined as part of the ISection interface, to execute anything in a section that should respond to a shell based notification and vice versa.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: November 17, 2008, 07:29:11 »

This is where the Pipes utility comes in. Its a way of sending messages between Cores.

In Modularity you see how to let the shell and a module communicate by having references to each other and interfaces defining the callable methods.

The notification won't travel into the other core because its a different Facade and set of MVC actors.

So a notification in one core (the shell or a module) could trigger a call against the interface exposed by the other core.

But sometimes you don't want to have the cores have references to each other.

The Pipes util allows us to send Messages between cores.

Core to.core Messages will need to carry typed data more often than Notifications. This is because modular apps may be developed in suc a way that modules are created independently of each other, and so a contract must be in place between modules. In place if interfaces, the contract can be message type.

Have a look now at the PipeWorks demo and you'll see this approach used.

And of course, if need be you can mix and match interface driven synchronous communication and asynchronous message driven communication in the same app.

-=Cliff>
Logged
mdw1980
Newbie
*
Posts: 5


View Profile Email
« Reply #6 on: November 17, 2008, 07:59:27 »

Thanks cliff. I'm starting to understand now. I'm going to give this interface approach a shot and see how it goes. I think I'm even starting to see the potential of creating my own framework based on this to suite my needs as many of the projects I do at work end up being setup like this.
Logged
Jason MacDonald
Sr. Member
****
Posts: 243


View Profile Email
« Reply #7 on: November 18, 2008, 08:27:11 »

you might also have a look at Darshans Fabrication utility for communicating betwen shell and modules. I found it to be much easier to set-up and follow than Pipes - it really is pipes underneath but has a simplified way of interacting with it laid over top.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: November 19, 2008, 10:20:33 »

Exactly, Jason. Once you have pipes, you logically need a plumber.

-=Cliff>
Logged
Pages: [1]
Print