Permanent URLS

I can imagine use cases where users would value direct access to the app in a range of circumstances.

URLs with attributes

The instances may require URL attributes:

1. a particular dataset
2. datasets for a particular trial, a platform, 20 most recent... (show results of specified search)
3. a particular XY-Plot on a dataset (specifying the contents of each axis)
4. a map of a dataset
5. a map containing a named set of datasets

URL 2 (all datasets for plat_a on trial_b) would be used as convenient way of directing a user to a useful set of data. Typically, the 'Filter' panel of the Browse page would be used to produce a search query. If this query is fired into the event bus as a FILTER place (with the query as an attribute) then the app will be using that search as a URL. The URL can then be copied by hand, or via a "Copy URL" link alongside the search results.

So, the Filter will fire an event that contains the Query. The results-table will hear this event, formulate an ElasticSearch query, and show any matching results.

Dumb URLs

In contrast, this next set are dumb URLs - potentially just be links to the relevant web-page (if we have multiple entry points)

1. the maintainers page
2. the add data page
3. current shopping basket
4. browse page
5. home page
6. export shopping basket
7. operate on shopping basket

History support

It would be good to support the Back button in the UI. When a user drills down into a dataset, it would be good to allow him to use Back to return to the previous view.

Thoughts on event producers & consumers

FilterEvt

Contains encoded query. This query can be parsed by the Filter view in order to mark the selected values, or by the Matches view in order to produce an ElasticSearch query.

AddToBasketEvt

This contains a single dataset id, to be added to the basket.

ViewDatasetEvt

This contains a single dataset id, to be shown in the View dataset panel.