myGrid
  1. myGrid
  2. TAV-559

Referenced nested workflow support should be more consistent/easier to use

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5, 1.5.1, 1.5.1.1, 1.5.1.2, 1.5.1.3, 1.5.1.4, 1.5.1.5, 1.5.1.6, 1.5.2, 1.5.2.1
    • Fix Version/s: 1.7.1
    • Component/s: Taverna GUI
    • Labels:
      None

      Description

      Currently we secretly supports referenced nested workflow. Such a nested workflow is saved in the scufl as:

      <s:processor name="get_orthologs">
              <s:workflow>
      
          <s:xscufllocation>file:/G:/toolkit/get_ko_pathways_3.xml</s:xscufllocation>
              </s:workflow>
      </s:processor>
      

      However, as pointed out by Paul Fisher to taverna-users on 2007-07-30, this means that if G: was your USB flash-drive at home, it might be at F: at work. If you are using it in a Linux or Mac OS X computer it would work even less.

      In general our GUI doesn't show that a nested workflow is referenced, and doesn't give the user any control over when it is referenced or not.

      Referenced workflows are generally very useful, as reported (offline) by Marco Roos, for utillity workflows/shims that can be built and maintained separately. Within their personal library of workflows they would generally like to use the latest version of that nested workflow, ie. the one stored behind the reference.

      Currently if you start editing a nested workflow Taverna will make a copy of it and break the reference. This might or might not be what the user wants.

      This Improvement request seeks a general clean-up of how Taverna handles referenced nested workflows and to improve the GUI to make referenced nested workflows more obvious and usable.

      Most of Taverna's users probably don't even know that referenced nested workflows are possible, and keeping it secret is like not telling a fresh programmer about functions.

        Issue Links

          Activity

          Stian Soiland-Reyes made changes -
          Field Original Value New Value
          Fix Version/s 1.6 [ 10021 ]
          Affects Version/s 1.5.2.1 [ 10037 ]
          Affects Version/s 1.5.2 [ 10024 ]
          Affects Version/s 1.5.1.6 [ 10036 ]
          Affects Version/s 1.5.1.5 [ 10034 ]
          Affects Version/s  1.5.1.4 [ 10032 ]
          Affects Version/s 1.5.1.3 [ 10031 ]
          Affects Version/s 1.5.1.2 [ 10033 ]
          Affects Version/s 1.5.1.1 [ 10030 ]
          Affects Version/s 1.5.1 [ 10020 ]
          Affects Version/s 1.5 [ 10010 ]
          Priority Major [ 3 ] Minor [ 4 ]
          Stian Soiland-Reyes made changes -
          Description Currently we secretly supports referenced nested workflow. Such a nested workflow is saved in the scufl as:

          {code=xml}
                <s:processor name="get_orthologs">
                  <s:workflow>

              <s:xscufllocation>file:/G:/toolkit/get_ko_pathways_3.xml</s:xscufllocation>
                  </s:workflow>
                </s:processor>
          {code}

          However, as pointed out by Paul Fisher to taverna-users on 2007-07-30, this means that if G: was your USB flash-drive at home, it might be at F: at work. If you are using it in a Linux or Mac OS X computer it would work even less.

          In general our GUI doesn't show that a nested workflow is referenced, and doesn't give the user any control over when it is referenced or not.

          Referenced workflows are generally very useful, as reported (offline) by Marco Roos, for utillity workflows/shims that can be built and maintained separately. Within their personal library of workflows they would generally like to use the latest version of that nested workflow, ie. the one stored behind the reference.

          Currently if you start editing a nested workflow Taverna will make a copy of it and break the reference. This might or might not be what the user wants.


          This Improvement request seeks a general clean-up of how Taverna handles referenced nested workflows and to improve the GUI to make referenced nested workflows more obvious and usable.

          Most of Taverna's users probably don't even know that referenced nested workflows are possible, and keeping it secret is like not telling a fresh programmer about functions.
          Currently we secretly supports referenced nested workflow. Such a nested workflow is saved in the scufl as:

          {code:xml}
                <s:processor name="get_orthologs">
                  <s:workflow>

              <s:xscufllocation>file:/G:/toolkit/get_ko_pathways_3.xml</s:xscufllocation>
                  </s:workflow>
                </s:processor>
          {code}

          However, as pointed out by Paul Fisher to taverna-users on 2007-07-30, this means that if G: was your USB flash-drive at home, it might be at F: at work. If you are using it in a Linux or Mac OS X computer it would work even less.

          In general our GUI doesn't show that a nested workflow is referenced, and doesn't give the user any control over when it is referenced or not.

          Referenced workflows are generally very useful, as reported (offline) by Marco Roos, for utillity workflows/shims that can be built and maintained separately. Within their personal library of workflows they would generally like to use the latest version of that nested workflow, ie. the one stored behind the reference.

          Currently if you start editing a nested workflow Taverna will make a copy of it and break the reference. This might or might not be what the user wants.


          This Improvement request seeks a general clean-up of how Taverna handles referenced nested workflows and to improve the GUI to make referenced nested workflows more obvious and usable.

          Most of Taverna's users probably don't even know that referenced nested workflows are possible, and keeping it secret is like not telling a fresh programmer about functions.
          Stian Soiland-Reyes made changes -
          Description Currently we secretly supports referenced nested workflow. Such a nested workflow is saved in the scufl as:

          {code:xml}
                <s:processor name="get_orthologs">
                  <s:workflow>

              <s:xscufllocation>file:/G:/toolkit/get_ko_pathways_3.xml</s:xscufllocation>
                  </s:workflow>
                </s:processor>
          {code}

          However, as pointed out by Paul Fisher to taverna-users on 2007-07-30, this means that if G: was your USB flash-drive at home, it might be at F: at work. If you are using it in a Linux or Mac OS X computer it would work even less.

          In general our GUI doesn't show that a nested workflow is referenced, and doesn't give the user any control over when it is referenced or not.

          Referenced workflows are generally very useful, as reported (offline) by Marco Roos, for utillity workflows/shims that can be built and maintained separately. Within their personal library of workflows they would generally like to use the latest version of that nested workflow, ie. the one stored behind the reference.

          Currently if you start editing a nested workflow Taverna will make a copy of it and break the reference. This might or might not be what the user wants.


          This Improvement request seeks a general clean-up of how Taverna handles referenced nested workflows and to improve the GUI to make referenced nested workflows more obvious and usable.

          Most of Taverna's users probably don't even know that referenced nested workflows are possible, and keeping it secret is like not telling a fresh programmer about functions.
          Currently we secretly supports referenced nested workflow. Such a nested workflow is saved in the scufl as:

          {code:xml}
          <s:processor name="get_orthologs">
                  <s:workflow>

              <s:xscufllocation>file:/G:/toolkit/get_ko_pathways_3.xml</s:xscufllocation>
                  </s:workflow>
          </s:processor>
          {code}

          However, as pointed out by Paul Fisher to taverna-users on 2007-07-30, this means that if G: was your USB flash-drive at home, it might be at F: at work. If you are using it in a Linux or Mac OS X computer it would work even less.

          In general our GUI doesn't show that a nested workflow is referenced, and doesn't give the user any control over when it is referenced or not.

          Referenced workflows are generally very useful, as reported (offline) by Marco Roos, for utillity workflows/shims that can be built and maintained separately. Within their personal library of workflows they would generally like to use the latest version of that nested workflow, ie. the one stored behind the reference.

          Currently if you start editing a nested workflow Taverna will make a copy of it and break the reference. This might or might not be what the user wants.


          This Improvement request seeks a general clean-up of how Taverna handles referenced nested workflows and to improve the GUI to make referenced nested workflows more obvious and usable.

          Most of Taverna's users probably don't even know that referenced nested workflows are possible, and keeping it secret is like not telling a fresh programmer about functions.
          June Finch (Inactive) made changes -
          Fix Version/s T2 guideline [ 10038 ]
          Fix Version/s 1.6 [ 10021 ]
          June Finch (Inactive) made changes -
          Assignee June Finch [ jfinch ] Tom Oinn [ toinn ]
          Stian Soiland-Reyes made changes -
          Link This issue has dependent TAV-574 [ TAV-574 ]
          Alan Williams made changes -
          Assignee Tom Oinn [ toinn ] Stuart Owen [ sowen ]
          Alan Williams made changes -
          Fix Version/s T2 guideline [ 10038 ]
          David Withers (Inactive) made changes -
          Workflow New features and improvements [ 10869 ] jira [ 11703 ]
          Hide
          Stuart Owen added a comment -

          This was fixed for the 1.7.1 release by TAV-574

          Show
          Stuart Owen added a comment - This was fixed for the 1.7.1 release by TAV-574
          Stuart Owen made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 1.7.1 [ 10054 ]
          Resolution Fixed [ 1 ]

          Error rendering 'com.atlassian.jira.plugins.jira-bitbucket-connector-plugin:dvcs-commits-tabpanel'. Please contact your JIRA administrators.

            People

            • Assignee:
              Stuart Owen
              Reporter:
              Stian Soiland-Reyes
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: