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: Tying mediator's registration to view component's life cycle  (Read 4629 times)
Ilan Avigdor
Courseware Beta
Newbie
***
Posts: 5


View Profile WWW Email
« on: August 04, 2010, 02:56:19 »

Hi,

I read the discussion regarding mediators registration
http://forums.puremvc.org/index.php?topic=1249.msg6484#msg6484
and specially Cliff's remark :

Usually it is the mediator of those view components that will register the mediators for their deferred children, by listening for their creation events.


In a Flex project I'm involved, we experienced that relying on view component's creation events (creationComplete/Initialize) may be limiting in some circumstances:

When more than a single view component is created at once (i.e master/details contents are replaced) and the registered mediators listen to each others notifications, controlling the order of registration is crucial, whereas the order of view component's creation events is unpredictable.

It seems that in these cases it is better for the parent mediator to register child mediators regardless of its view component's life cycle, before it is attached to the display list.
The child mediators should not expect a fully initialized component, but rather a well behaved one (apply to Flex object life cycle and can handle setters before fully created).

Any insights?

Thanks,

-ilan
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #1 on: August 05, 2010, 09:01:29 »

How are you instantiating these child components?  Is it all in MXML???
Anyway, I rarely use creation events to register a view component with a Mediator.

Rather, I would have the parent component create the child, add it, and then dispatch an event which its mediator catches and then handles (for example by registering another mediator for it).

Or, I would have the parent's Mediator instantiate the child itself as well as the child's mediator and then add the child to the viewComponent as necessary.  I think this is what you are advocating.

Either way, I have complete control over the ordering of the Mediators' instantiation and can expect predictable results from the overarching application.

But ideally, I would have some formal application level procedure for changing views, adding popups, etc. which would encompass all possibilities and obviate the question of how to deal with "child" mediators.  It's just me perhaps, but I find the idea of a Mediator being the "child" of another Mediator distasteful.  I think they should all be equal in the eyes of the application architecture regardless of where their viewComponent lies in the view hierarchy.  I'll stop there since I risk getting into a semantic argument that has nothing to do with your current post!
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #2 on: August 06, 2010, 07:51:03 »

@jpwrunyan you're right, it is not a good idea to think of a Mediator as being a child of another. All Mediators are peers. It is the view hierarchy that has children.

So if a view component is created by way of deferred instantiation, such as when a child of a Viewstack is navigated to for the first time (if creationPolicy isn't set to 'all'), then an event is automatically dispatched with a reference to that child. That bubbling event can be listened for anywhere at all along the view hierarchy.

Depending on your app's Mediator granularity you might listen for that event in a Mediator for the Viewstack, or the component that contains the Viewstack, or even all the way up at the application level.

But if a parent component explicitly creates its children in a method as you mention and turns around and dispatches a custom-named instance of Event, then you should probably use the Mediator of that specific parent component to do the listening if the event name is defined as a constant on that parent component that is generating the event, since its Mediator is the only one that should reference that constant.

However if you dispatch a bubbling instance of a custom event class where the name of the event is a constant defined on the event, then once again you can listen anywhere up the hierarchy for the event since the listening Mediator doesn't need to reference the component that generated the event.

-=Cliff>
Logged
Ilan Avigdor
Courseware Beta
Newbie
***
Posts: 5


View Profile WWW Email
« Reply #3 on: August 08, 2010, 12:38:05 »

Cliff, @jpwrunyan thanks for your feedbacks !

@jpwrunyan, both options you mentioned does not rely on the view component's life cycle. That's exactly my point!

Cliff, It's the first time I realized that when you refer to "creation events", you actually mean the events dispatched by the container adding the child (ChildExistenceChangedEvent.CHILD_ADD) and not the event dispatched by the child itself (Initialize, creationComplete).

This makes all the difference, as the childAdd is handled immediately, in a synchronous manner (in the same frame) and let you control registration order, while the timing of creationComplete is not predictable.

My question referred to the registration timing, so I will leave the discussion regarding responsibility out of this scope.

Thanks,

-ilan
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #4 on: August 08, 2010, 10:24:37 »

Cliff, @jpwrunyan thanks for your feedbacks !

@jpwrunyan, both options you mentioned does not rely on the view component's life cycle. That's exactly my point!

Right, sorry.  I guess in my own convoluted way I was trying to agree with you on that point.  Sorta got sidetracked into talking about Mediators half-way through my own post...
Logged
Pages: [1]
Print