Closed yochannah closed 5 years ago
@joshkh I think this might have already been done. Can you confirm and close / address the issue as needed?
Deep linking to lists kind of works but maybe not the way you'd expect.
When any query (including those that display lists) is sent to the /results page the query is pushed into the result page history stack. If the query doesn't have a name then one is generated, and this is what appears in the URL:
http://localhost:5000/#/results/query-i-just-ran http://localhost:5000/#/results/results-from-some-template
So It's really a link to a query in history! If it's not in the history then we get an error.
I think we'll need a second layer in the URL that tells BlueGenes the type of thing to look for in the assets:
http://localhost:5000/#/results/
Example: http://localhost:5000/#/results/list/my-list http://localhost:5000/#/results/query/my-saved-query
This could be streamlined and combined with the report route so that:
http://localhost:5000/#/results/item/Gene/1997283
...goes to a report page instead, making the links more uniform.
@yochannah Whatcha think?
@joshkh Hmm, two thoughts:
1) I now question what we need /results/
for at all - is there a scenario in which it is needed if we have /list/
or query
but still needs results for some reason? I dob't thinks so.
2) deep links need to include, or at least accept, a mine name. It can try default if there is none.
With those two in mind, could we have a URL system like -
http://www.somebluegenes.com/#/flymine/list/my-list http://www.someotherbluegenes.com/#/yeastmine/query/some-query http://www.somethirdbluegenes.com/#/query/some-query <- goes to the default mine
I now question what we need /results/ for at all - is there a scenario in which it is needed if we have /list/ or query but still needs results for some reason? I dob't thinks so.
I still think there's some value in having a base path that distinguishes between "Show me this part of bluegenes" and "Show me this piece of data in InterMine". Otherwise the types of viewable things can collide with application routes. For example bluegenes.org/query/some-query would dominate the word "query" at the root path, and given that query is also a verb it rules out using it as an action, such as bluegenes.org/query/for-this-value.
bluegenes.org/list/mylist <- data bluegenes.org/query/somesavedquery <- data bluegenes.org/report/default/Gene/1234 <- data bluegenes.org/regions <- tool bluegenes.org/querybuilder <- tool
Where as this keeps the "physical" sections of bluegenes away from the viewable data types:
bluegenes.org/view/query/somesavedquery bluegenes.org/view/object/Gene/1234 bluegenes.org/view/list/somesavedlist bluegenes.org/querybuilder bluegenes.org/templates
Also, having the bluegenes.org/[view]/thing let's us create a rule such as "anything below this route needs extra prefetched data." It's just a small detail and in the end won't make a huge difference, and of course the decision is yours! :)
deep links need to include, or at least accept, a mine name. It can try default if there is none.
Good point! I'll work that in too.
I like view as a route! Nice idea.
On 23 April 2018 at 13:44, Joshua Heimbach notifications@github.com wrote:
I now question what we need /results/ for at all - is there a scenario in which it is needed if we have /list/ or query but still needs results for some reason? I dob't thinks so.
I still think there's some value in having a base path that distinguishes between "Show me this part of bluegenes" and "Show me this piece of data in InterMine". Otherwise the types of viewable things can collide with application routes. For example bluegenes.org/query/some-query would dominate the word "query" at the root path, and given that query is also a verb it rules out using it as an action, such as bluegenes.org/query/for-this-value.
bluegenes.org/list/mylist <- data bluegenes.org/query/somesavedquery <- data bluegenes.org/report/default/Gene/1234 <- data bluegenes.org/regions <- tool bluegenes.org/querybuilder <- tool
Where as this keeps the "physical" sections of bluegenes away from the viewable data types:
bluegenes.org/view/query/somesavedquery bluegenes.org/view/object/Gene/1234 bluegenes.org/view/list/somesavedlist bluegenes.org/querybuilder bluegenes.org/templates
Also, having the bluegenes.org/[view]/thing http://bluegenes.org/%5Bview%5D/thing let's us create a rule such as "anything below this route needs extra prefetched data." It's just a small detail and in the end won't make a huge difference, and of course the decision is yours! :)
deep links need to include, or at least accept, a mine name. It can try default if there is none.
Good point! I'll work that in too.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/intermine/bluegenes/issues/66#issuecomment-383561873, or mute the thread https://github.com/notifications/unsubscribe-auth/AI14jm4CSiwGy46EP_m1wUw3O3T1cFi-ks5trcy5gaJpZM4L1M2Q .
Report pages can be deep linked to like this: http://localhost:3449/#/reportpage/flymine-beta/Gene/1038161
an equivalent for named lists might be http://localhost:3449/#/results/flymine-beta/LISTNAMEHERE