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

Show Posts

| * |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / Architecture / Tying mediator's registration to view component's life cycle 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
2  Announcements and General Discussion / Architecture / Registering Multiple Instances of one Mediator and Proxy on: March 14, 2009, 05:44:25
Hi,
I would like to suggest another approach for the same issue discussed in the original post:
http://forums.puremvc.org/index.php?topic=596.0

The original discussion suggests the mediator using the type property of the notification as a discriminator, only taking action if it matches its own name.
This approach results in multiple mediators being called to handle the same notification, while only a single one is actually interested in it and taking an action.

I would suggest using the notification name for pairing mediators and proxies in the following way:
The same as in the original post, both mediator and proxy pair are given a unique key on registration.
The mediator adds this key to its list of notifications interests.
This key serves as the name parameter of the notification leaving the Proxy.
This way, these notifications are handled only by the mediator who included this name in its list of notifications interests - the corresponding pair.

Any thoughts are welcome.

Cheers,

-Ilan




Pages: [1]