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: Proxy registration / Stage child management  (Read 10335 times)
tobydeh
Port to Python
Sr. Member
*
Posts: 52


View Profile Email
« on: March 04, 2008, 02:59:39 »

Hello I have a couple of questions...

1) Should all proxies be instantiated and registered together when the application starts? Or can this be done as and when they are needed?

2) I work in a pure AS method, i do not use flex and i am trying to decide the best way to handle the creation and addition of new children to the stage etc...

if my AssetProxy executes:
facade.registerMediator(new ProgressBarMediator(new MovieClip()));

How should i handle the addition to the stage? Is it a bad idea for the Mediator to gain a reference to the stage? Should i send the child as the body of a notification? Should i create the movieclip and attach it to the stage from the command and THEN create the mediator with a reference to the new child?

I cannot seem to find an elegant solution to the management of children.

Many thanks in advance.

Logged
tobydeh
Port to Python
Sr. Member
*
Posts: 52


View Profile Email
« Reply #1 on: March 04, 2008, 04:29:56 »

Perhaps the best solution is to register all mediators and children in the StageMediator constructor and set them all to invisible, then manage their visibility as and when they are needed?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: March 04, 2008, 06:51:42 »

Toby,

With both Mediators and view components you will find times when creation of some Proxies and their data objects must be deferred.

When and how you do it is up to you but any INotifier can create and register a Proxy any time.

As for adding children to the Stage, have a look in the HelloFlash demo at the StageMediator and how HelloSprites make it onto the stage when you create new ones by dragging.

-=Cliff>
Logged
tobydeh
Port to Python
Sr. Member
*
Posts: 52


View Profile Email
« Reply #3 on: March 04, 2008, 07:11:43 »

Hi Cliff thanks for the reply.

I have studied all the demos in great detail and unfortunately the HelloFlash example does not really work in my situation because i am building a website which contains many different views that load at different times.

If i was to use the same method as HelloFlash then stage mediator would contain a STAGE_ADD_SOMETHING for every "page" which would get very bloated.
Logged
tobydeh
Port to Python
Sr. Member
*
Posts: 52


View Profile Email
« Reply #4 on: March 04, 2008, 07:38:10 »

Also the HelloFlash example does not demonstrate the removal of view components / mediators.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: March 04, 2008, 11:20:46 »

In HelloFlash, the StageMediator is doing the creation of the HelloSprite when it hears a Notification from a HelloSpriteMediator, carrying the parameters lifted from the HelloSprite being dragged.

Considering this setup, I think I've misplaced this particular method, and this has confused you.  I will refactor soon.

The creation of the HelloSprite should happen in the HelloSpriteMediator, and the HelloSprite itself sent as the Notification body rather than just the parameters to make one.

This means any number of Mediators could create different objects to be added to the Stage. The stage would listen for STAGE_ADD_CHILD Notifications and cast whatever shows up in the body to DisplayObject and add to the stage using Stage.addChild().

Same thing to remove. If the Mediator for an object wants its child removed from the Stage, it would send a STAGE_REMOVE_CHILD Notification with a reference to its view component. The StageMediator would hear this and do a stage.removeChild(). Then, the Mediator can use facade.removeMediator() to unregister itself.

-=Cliff>
Logged
tobydeh
Port to Python
Sr. Member
*
Posts: 52


View Profile Email
« Reply #6 on: March 05, 2008, 02:16:16 »

Thanks cliff im glad you said that, it is what i had done before i asked the question... I wasn't sure if throwing children around in Notifications was a good idea!

Just a thought... if i dispatch a notification that the stagemediator accepts, why dont i just call a method like addSprite() directly on the mediator? example:

var stageMediator:StageMediator = facade.retrieveMediator(StageMediator.NAME)
stageMediator.addSprite(myChild)

Why would you prefer to use Notifications over this method?

Also... what if the child doesn't need to be added to the Stage, but to another child? For example if i wanted to add a ProductSearchResultView to a ProductPage

Should these be handled by notifications as well? Or by retrieving the mediator and adding it directly to the view component / using a mediator method?

Many Thanks
« Last Edit: March 05, 2008, 02:31:27 by tobydeh » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: March 05, 2008, 07:08:50 »

Calling methods on a Mediator causes a tighter coupling than communicating by Notification. Introducing couplings between Mediators makes it more difficult to refactor.

For instance, in your question you asked what if it was some other mediator the child needed to be added to.

So let's imagine that you already have your Mediator who has the new child in hand, sending a note with the child, which StageMediator hears and acts upon.

But now, later in the project you really want that child added to PhotoGalleryMediators child instead.

Refactoring involves only 2 classes:
 
Refactor/move the notification interest and the handler for that not from Stage Mediator to PhotoGalleryMediator. QED.

If you had been calling a method on StageMediator from the original mediator, then 3 classes are involved in the refactor:

Refactor/move the addChild method from StageMediator to PhotoGalleryMediator then refactor the original mediator to import and retrieve PhotoGalleryMediator instead of StageMediator and make the call on it instead.

In this limited case, its only a little bit of extra work, but you can see what would happen if it was a practice used very often. It would tie your view in knots making it a pain to any major overhauls of the view.

-=Cliff>
Logged
Pages: [1]
Print