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

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

I used the term "registration" but indeed meant to construction.

Thanks !

We are in the design phase of a PureMVC based system with similar requirements, and this thread is an important take on this issue. Thanks!

Our system, however, like many others, requires that the search/refresh should be initiated when changing any one of the filtering views (i.e. view component 2, which holds the start/end times).

In addition, the same filter change can require refreshing different types of data/proxies for different data representation views (i.e. changing the end date should refresh both tasks and appointments lists).

The options we see are:
1. The filter proxy (i.e. TaskFilterProxy) sends a FilterUpdated notification, handled by a command that is responsible for calling the relevant proxies to refresh.

This approach leaves the data views "clean", showing interest only in changes to the data they represent, regardless of the reason it was changed. However, the command handling the filter updated notification becomes somewhat of a maintenance bottleneck.

2. The mediators which should refresh as a result of a filter change handle the filter updated notification by sending some kind of a "need to refresh" notification, which causes the relevant proxy to refresh.

This approach encapsulates the need for a refresh in the data representation mediators, but makes them less reusable (for apps which doesn't use the same filters).

Any insights/additional options are most welcome.

Thanks,

-Ilan

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