Refactor Workflow Run Form Toward Vue (part 2) #9147
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jmchilton
added this to In progress
in Simplified Workflow-centric User Experience
via automation
jmchilton
added
status/WIP
area/UI-UX
area/workflows
kind/refactoring
jmchilton
force-pushed
the
wfrun2vue_1
branch
from
34429e9
to
969be1a
Compare
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Dec 19, 2019
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Dec 19, 2019
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Dec 19, 2019
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Jan 3, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
force-pushed
the
wfrun2vue_1
branch
2 times, most recently
from
a9d42e7
to
114e4bd
Compare
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Jan 30, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
force-pushed
the
wfrun2vue_1
branch
from
114e4bd
to
86356e3
Compare
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Jan 30, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
force-pushed
the
wfrun2vue_1
branch
from
86356e3
to
509aa75
Compare
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Mar 20, 2020
... for interaction between the landing page (WorkflowRun) and the form itself (currently ToolFormComposite but that code should be migrated into WorkflowRunForm).
…re reusable class.
Based on PR review comments ( galaxyproject#9151 (comment) ).
|
Rebased on top of the prettier changes. For future @jmchilton's reference - repeat cycle for each conflict: Backup of last pre-rebase branch at https://github.com/jmchilton/galaxy/tree/wfrun2vue_prerebase. |
|
Works well in my testing, refactoring looks good. I think we're probably want to continue to move most of the service layer stuff (not a whole lot there for this particular PR, obv) into Vuex, but that won't hold up anything in terms of merging this. |
Simplified Workflow-centric User Experience
automation
moved this from In progress
to Done
Apr 28, 2020
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
May 11, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Jun 1, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 9, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 10, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default (at least until batch parameters are hidden or implemented). - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI (see TODO below for followup) - Drops job caching option to simplify the UI (see TODO below for followup) - Drops resource parameters - we've already verified there are none. TODO: - Handle batch parameters - either implement them or disable them in this context. - Make history target in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_target_history in ['new', 'current', 'show_selection']. - Make job caching option in simplified mode configurable via galaxy.yml - simplified_workflow_run_ui_cache in ['on', 'off'].
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 10, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 11, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 11, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 11, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 11, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 11, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 11, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 12, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
jmchilton
added a commit
to jmchilton/galaxy
that referenced
this pull request
Aug 13, 2020
Builds on refactoring the workflow run form landing and orchestration into Vue (galaxyproject#9147). Implements galaxyproject#9111 - part of https://github.com/galaxyproject/galaxy/projects/15 and outlined in http://bit.ly/simplified-workflow-ui. What is in the PR: - Add new Galaxy configuration option - ``simplified_workflow_run_ui`` set to ``off`` by default. - If instead the admin has set this parameter to ``prefer``, on the workflow run page scan the workflow run request and if three conditions are met show a simplfied tool form. These conditions are: - No workflow "resource parameters" - pretty niche, not documented, I don't think anyone outside of Canada is using them and even them I'm not sure if they ever got to production. - No "open" tools (i.e. tools with disconnected runtime inputs). - No "replacement parameters" defined outside PJAs. I'm calling #{} inside PJA and ${} inside tool steps both "replacement parameters" because the user populates them the same way in the GUI. The API only handles them inside the context of the PJA - it seems the GUI is responsible for replacing them at runtime in the traditional form. - The simplified workflow form: - Drops tool and subworkflow steps from rendering all together and instead just renders the inputs. These are not rendered as separate "steps" or forms - but as just different inputs the same clean, simple form (more the like tool GUI). Labels (or step indexes as a fallback) are used at the input name, step annotations are used as the input help text. - Simplify the workflow request made by the client - send only replacement parameters and inputs - do not serialize tool state for each module. I think this makes what we are tracking more structured and should be more performant as well. Prevents storing HDA IDs in unstructured JSON blobs in the database as well. - Drops history target option to simplify the UI - simplified_workflow_run_ui_target_history can be set to either 'current' or 'new' to adjust this parameter Galaxy-wide for the simplified form. - Drops job caching option to simplify the UI - simplified_workflow_run_ui_cache can be set to 'off' or 'on' to change this parameter Galaxy-wide for the simplified form. - Drops resource parameters - we've already verified there are none for simplified workflows.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Builds on #9138. New commits include: