-
Notifications
You must be signed in to change notification settings - Fork 987
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Tool Panel views structures and combine ToolBox and ToolBoxWorkflow into one component #16739
Refactor Tool Panel views structures and combine ToolBox and ToolBoxWorkflow into one component #16739
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backend looks good so far!
Parts of this seem correct. I certainly like the idea of just sending the backbone of tool sections - that seems like such a conceptual win from an API perspective. We're still implementing multiple different tool panel views and of different types and such though right? The thing that causes some anxiety on my end is we had like turned ontologies into just another tool panel view and now we're like recomputing some ontology code on the client that had shifted to the backend. It might be used in totally fine ways though. Cool stuff though - even if it makes me anxious! |
John's comment...
Thank you @jmchilton !
Yes, we're still treating those as the same (i.e.: At the front end, the Tool panel itself appears and works the exact same way. |
4735cca
to
475f93c
Compare
Thanks for the clarification - I appreciate you easing my anxieties! This is exciting work - very nice job. |
Regarding this example: "filter": {
"model_class": "ToolSection",
"id": "filter",
"name": "Filter and Sort",
"version": "",
"description": null,
"links": null,
"tools": [
"Filter1",
"sort1",
"Grep1",
"panel_label_gff", <- this part
"Extract_features1",
"gff_filter_by_attribute",
"gff_filter_by_feature_count",
"gtf_filter_by_attribute_values_list"
],
"panel_labels": [ <- and this part
{
"model_class": "ToolSectionLabel",
"id": "gff",
"text": "GFF",
"version": "",
"description": null,
"links": null
}
]
}, If I understand this correctly, this treats strings within the "tools" array which are prefixed with "panel_label" in a special manner, referencing a label defined in "panel_labels". If this is the case, I do not like the design choice of giving some string special type implications. What I mean by this is that all other strings here are tool identifiers, while "panel_label_gff" is a panel label identifier. This is confusing when working with the API return, and can lead to edge cases if a tool id happens to start with "panel_label_". I'd prefer the label object to be directly inside the array, next to the IDs. This still gives the array a mixed type, which is not ideal, but now that mixed type is obvious and easier to handle, rather than be hidden behind indirection. |
Thanks @ElectronicBlueberry I did think about placing the |
This comment was marked as resolved.
This comment was marked as resolved.
e048175
to
09c51f1
Compare
Changed the structure of toolbox received from the backend ToolBox is now an object of ToolSections (and Tools) by id Also consolidated `ToolBox` and `ToolBoxWorkflow` into one `ToolBox` that is contained within a `ToolPanel`. Removed Tool panel providers and ProviderAware tool boxes
sections within a ToolSection
improve typing in several places
improve typing
if user had some favorite wfs
058d727
to
a418224
Compare
@ahmedhamidawan and I talked about the API changes a bit and the plan is to adjust this so that the old route doesn't change and will continue to return the same to_dict, supporting |
Changed the structure of toolbox received from the backend ToolBox is now an object of ToolSections (and Tools) by id
(sample structure laid out here in #16453 (comment)
Change in backend
api/tools
returnapi/tools?in_panel=True&view=ontology:edam_operations
used to return:and it now returns:
And we use
api/tools?in_panel=false
to return atoolsById
object to reference these views.Going forward, this will make it easier for us to make any structural changes with these lighter "view" objects that store only tool ids, to then create the Tool Panel views we like at the front end.
Note: Case where a
ToolSection
contains aToolSectionLabel
In such cases (a "Sub" Label within a Section):
![image](https://private-user-images.githubusercontent.com/78516064/270783546-7eb4d438-325f-4f66-a2df-8c91550a064b.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjM5MDIzNzcsIm5iZiI6MTcyMzkwMjA3NywicGF0aCI6Ii83ODUxNjA2NC8yNzA3ODM1NDYtN2ViNGQ0MzgtMzI1Zi00ZjY2LWEyZGYtOGM5MTU1MGEwNjRiLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE3VDEzNDExN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTllYWYyZTdjOWQxNTM5MWM4NTcxY2ZhOTU0YWRiMjQ5M2E1NWUxOWYwMzNmMzZkZjJmNzhlNjg5NDQwMTIwNjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.-50UPjzUyLG53TW0HyScY9ESRdc0nJjDoktkbhevkUg)
the new api structure will do something like this:
Fixes #16499
Fixes #16101
Also consolidated
ToolBox
andToolBoxWorkflow
into oneToolBox
that is contained within aToolPanel
. Removed Tool panel providers and ProviderAware tool boxesHow to test the changes?
(Select all options that apply)
License