Sending fetchRelatedData to multiple targets

[rpoyner]

My application has a split pane with one grid in the navigation pane and one in the list pane. The detail pane has 4 tabs with multiple forms and grids. Clicking on a record in the listpane grid should send something like fetchRelatedData to each of the elements in each of the tabs in the detail pane. I'm wondering if there is a best-practices way to do this. One solution would be to bind a function to recordClick in the listpane grid and have it fire fetchRelatedData to a list of elements in the detail pane. That would be fairly simple, but it does not take account of which tab in the detail pane is visible at the time. Maybe that's good enough? Or is there some fancier mechanism that magically updates the visible tab and causes the others to update when they are shown.

Thanks.

[Isomorphic]

There isn't really a single "best" way to do this. By issuing all the fetch requests at one time in response to the record click, you're getting data for all the detail components up front. This has the advantage that you can take advantage of queing to perform a single client-server turnaround encompassing all requests, and that when the user shows the content of a tab, the detail component is already populated.

However if you're talking about a large amount of data, or if the user is unlikely to display different detail tabs, you may be transferring unnecessary data to the client. The other approach (which would avoid this) would be to track the currently visible detail component in your application code, and have the recordClick (or selectionUpdated, etc) notification from your list-pane call fetchRelatedData only on the visible component - and have additional logic on the TabSet tabSelected notification which would perform a fetch on the detail component being revealed if the selection in the list component had changed.

The first approach is a little less coding in your app, and is likely to be sufficient in most cases, but neither approach should be particularly difficult to achieve, so it really comes down to what user-experience works best in your actual usage.

Regards
Isomorphic Software

[rpoyner]

Great. The queue advantage of doing all the requests at once was something I hadn't considered. That combined with the fact that the detail data will be small decides it in favor of the all at once strategy.

Thanks.