Moving away from reliance on Cytoscape selection #73
Comments
|
That's essentially what we did with commands. For the most part,
anywhere a "nodeList" can be passed, you can either say "selected",
provide a list of nodes, or a search to match (e.g. node type:protein).
…-- scooter
On 03/20/2018 08:29 AM, dotasek wrote:
I'm revisiting a review we did on CyREST vs. the Cytoscape API, and I
noticed that there's an immense reliance on the Node/Edge selection.
The way that some workflows would have to work now is as follows:
1. Make a selection
2. Perform a task that uses the selection as a parameter (Zoom to
selection, etc.)
or
1. Make a selection
2. Perform as task that alters the selection (Select neighbours, etc.)
3. Return the selection
I wonder if it would be of benefit to people making scripts if this
reliance on selection was reduced; if CyREST let you pass nodes and
edges as JSON directly to/from more endpoints.
For example, a zoom operation that just lets you send a list of nodes
to include in the view, or a neighbours function that accepts a list
of node SUIDs as a parameter and returns the neighbouring nodes as a
list of SUIDs.
These would definitely be more RESTful, and, from a programmer's
perspective, would reduce boilerplate code in the libraries. Thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#73>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC80-FEIawQmzhuRacWqR7rIQZXGI9jPks5tgSBggaJpZM4SyHem>.
|
|
The nodeList in the best-case automation scenario is treated as a String that needs to be parsed and formatted within R or Python, with special-case values. I'm suggesting an approach that would more explicitly handle just arrays of SUIDs, so that they could be validated and streamed to/from Scripting languages more easily. |
|
Decoupling this issue from previous mentions in favour of a list of possible functions to be supported (this way, I can close #72 for example, and later make an issue for supporting Show/Hide for multiple objects).
|
|
Some general thinking-out-loud: If we filter the level above from individual objects, we might get some useful functionality:
The problem here is that to be RESTful, whatever I PUT should also be returned by the GET. If I PUT a fragment such as Then one would expect the entire content of the SUID's visual properties to be the passed data (not what we want to do). This might be the domain of PATCH. Will have to inspect this. |
I'm revisiting a review we did on CyREST vs. the Cytoscape API, and I noticed that there's an immense reliance on the Node/Edge selection.
The way that some workflows would have to work now is as follows:
or
I wonder if it would be of benefit to people making scripts if this reliance on selection was reduced; if CyREST let you pass nodes and edges as JSON directly to/from more endpoints.
For example, a zoom operation that just lets you send a list of nodes to include in the view, or a neighbours function that accepts a list of node SUIDs as a parameter and returns the neighbouring nodes as a list of SUIDs.
These would definitely be more RESTful, and, from a programmer's perspective, would reduce boilerplate code in the libraries. Thoughts?
The text was updated successfully, but these errors were encountered: