Support ?show=screen-123 for mapr jstree

[will-moore]

This adds support for the URL e.g. ?show=screen-2 so that we can link to a Study within a Gene etc. This may be a useful entry point if we use a different UI / App to do the initial mapr query, then we want to link to a particular study within a matching term in the mapr app. E.g. http://web-dev-merge.openmicroscopy.org/mapr/gene/?value=CDK5RAP2&show=project-4501 (user-3)

In mapr, this will load Genes that match value CDK5RAP2. With the 'show' query, we load the top level gene nodes of the tree, to check their "study" children for a match with the 'show' query. If we find a match then this node is selected and expanded. NB: This is a different approach from the webclient/?show=image-2 where the node may be deep in the tree and needs us to load the "path" to this node before expanding all the nodes along the path. Here, we know that the "study" will be one level below the "Genes" that are children of the root node. So we can simply expand each and look for the "study". This will expand some nodes unnecessarily, but the number will be small since most e.g. Genes don't have many homologues (not many children of the root node).

To test:

• Browse e.g. Gene, Antibody, etc pages in mapr. Enter a term, e.g."CDC5" pick from auto-complete etc to show studies.
• Note a study ID, e.g. screen-51
• Construct URL of the form /mapr/gene/?value=CDC5&show=screen-51
• Enter this URL in the browser. The matching Gene(s) should be loaded as normal, the child studies loaded and the matching one selected and expanded.

[will-moore]

I need to investigate mapr_paths_to_object to see if there's a better way to get the direct path to the object, instead of expanding multiple nodes.

[will-moore]

@joshmoore You were going to review this today, but I'm going to try a different approach using paths_to_object e.g. /mapr/api/gene/paths_to_object/?map.value=CEP120&project=18328 to save me from loading more of the tree than I need.

[joshmoore]

I'm going to try a different approach using

ok.

E.g. http://web-dev-merge.openmicroscopy.org/mapr/gene/?value=CDK5RAP2&show=project-4501

`KeyError: 'active_user'` if not logged in

``` Traceback (most recent call last): File "/home/hudson/virtualenv/lib/python2.7/site-packages/django/core/handlers/base.py", line 132, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/opt/hudson/workspace/WEB-DEV-merge-deploy/OMERO.py/lib/python/omeroweb/decorators.py", line 486, in wrapped retval = f(request, *args, **kwargs) File "/opt/hudson/workspace/WEB-DEV-merge-deploy/OMERO.py/lib/python/omeroweb/decorators.py", line 536, in wrapper context = f(request, *args, **kwargs) File "/home/hudson/virtualenv/lib/python2.7/site-packages/omero_mapr/views.py", line 186, in index context['active_user'] = context['active_user'] or {'id': -1} File "/home/hudson/virtualenv/lib/python2.7/site-packages/django/http/response.py", line 208, in __getitem__ return self._headers[header.lower()][1] KeyError: 'active_user' ```

---

Otherwise, looks :ok:. I'd want us to also test this in the context of an IDR test server just to be sure though.

[will-moore]

Hmmm, not sure what's causing that but e.g. http://idr.openmicroscopy.org/mapr/api/gene/paths_to_object/?map.value=INCENP&screen=1101 seems to work OK. I'll add a fix for `KeyError: 'active_user'`.

[sbesson]

Is this ready for relisting ?

[will-moore]

@sbesson Yes. The test link is in the description. http://web-dev-merge.openmicroscopy.org/mapr/gene/?value=CDK5RAP2&show=project-4501 (user-3) NB: I noticed the &show=project-4501 gets stripped if you get redirected to login.

[sbesson]

Tested using the workflow described above. In general selecting the mapr value and the container ID works as expected selecting the correct element on the tree.

• in addition to project-<id>, I realized that dataset-<id> is also supported which is a nice thing to have
• the above made me wonder how the tree exploration strategy would perform in the context of a larger tree. It might probably be worth deploying the above into an IDR testing resource and trying a few scenarios like mapr/organism/?value=Homo%20sapiens&show=...
• trying my luck with other types, I tested http://web-dev-merge.openmicroscopy.org/mapr/gene/?value=CDK5RAP2&show=image-118454 but received an exception which we probably want to handle at the application level.

Overall, no objection to merging and tagging as 0.3.0a2 although more testing might be required on IDR alongside the gallery work.

[sbesson]

Tested as part of today's review of the gallery app on IDR. Merging for a pre-release