Multiple delegate service parameters in different views

[Roustalski]

Lets say that view comp 1 with mediator 1 has a text field for searching.

View component 2 with mediator 2 has two date fields for start and end times for the search.

Lets also say that view component one dispatches an event to initiate the search, the mediator translates that to a notification/command pair. The command then retrieves a proxy and invokes a method that requires all 3 parameters.

How would you handle this?

The options as I see it:

1. View Comp 1 grabs the time params from View 2 and exposes the API to the mediator.
2. View Comp 1 Mediator 1 grabs the time params from View 2 Mediator 2, and then sends the notification with all 3 parameters
3.View Comp 2, when initialized and interaction with the time controls occur, sends a notification that maps to a command that sets the time parameters on the proxy. View Comp 1 then sends it's normal notification with its parameter, the command invokes the search method on the proxy with the search text, and uses the already stored time values from the other notification.
4. Some sort of AsyncCommand magic, where each mediator is polled (via notification I presume) for it's parameters and then launches the search command.
5. Other?

Thanks.

[Joel Hooks]

When the search parameters are changed they are stored to a SearchParamsProxy (with perhaps SearchParamsVO as the data) whish is then referenced for the actual search.

[Roustalski]

What reasoning do you use for keeping the parameters in a different proxy as opposed to the one who will actually use it?

In this simple scenario at least...

[puremvc]

Because it is data collected from several places in the app which another actor will use to perform a search. This keeps the searching actor from being coupled to the varied sources of the search parameters, which could concievably change.

Its sort of like all the employees (mediators) taking their time cards to the punch clock (SearchParamsProxy) where they're collected later and entered into the accounting system (search happens). No need to go collect them from each employee.

-=Cliff>

[JJfutbol]

Agreed with Joel and Cliff. I actually use the same approach for filtering/sorting. I'll have say a TaskProxy where I maintain a collection of tasks, allow creating, updating, etc. My service interactions are maintained there. But the way I filter the data is very unique and doesn't necessarily match or behave with explicit fields. I like having this in its own proxy, TaskFilterProxy in this case, since it can change (new filters, changing others) and its important enough to have on its own.

Also I would store the current filter/sort selections in the TaskFilterProxy much like how you would store the search params in a SearchParamProxy. So I would have selectedFilter and selectedSort properties (thanks to Cliff for this tip from meeting you at MAX)! At the end of the day someone needs to be responsible for globally maintaining a selection so in my case the best choice was the proxy (or at least it made most sense there). This proved incredibly helpful since I have a single command FilterTasksCommand encapsulate the necessary logic (command doesn't receive any body, then it assumes current selection for filtering, critical if your app does refreshing behind the scenes!).

[Ilan Avigdor]

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