Default value for data_column not working?
Hi all, I'm trying to write a new tool working with tabular data (specifically a Reciprocal Best Hits (RBH) tool using BLAST style tabular output). I want the user to be able to choose a column number (from one of the input files), but I have a default column in mind. However, Galaxy doesn't seem to obey the default column number: <inputs> <param name="a_vs_b" type="data" format="tabular" label="Hits from querying A against B" description="Tabular file, e.g. BLAST output" /> <param name="b_vs_a" type="data" format="tabular" label="Hits from querying B against A" description="Tabular file, e.g. BLAST output" /> <param name="id1" type="data_column" data_ref="a_vs_b" multiple="False" numerical="False" value="1" label="Column containing query ID" help="This is column 1 in standard BLAST tabular output" /> <param name="id2" type="data_column" data_ref="a_vs_b" multiple="False" numerical="False" value="2" label="Column containing match ID" help="This is column 2 in standard BLAST tabular output"/> <param name="score" type="data_column" data_ref="a_vs_b" multiple="False" numerical="False" value="12" label="Column containing containing score to rank on" help="The bitscore is column 12 in standard BLAST tabular output"/> </inputs> I've tried giving the default column value numerically (as shown), and also using value="c2" etc. Regardless, Galaxy just defaults to the first column. Is this a bug, or am I doing something wrong? Thanks, Peter
Hi Peter, I don't see your attempt to use default in the example given. A bit more detail? -K On Wed, Mar 30, 2011 at 12:32 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hi all,
I'm trying to write a new tool working with tabular data (specifically a Reciprocal Best Hits (RBH) tool using BLAST style tabular output).
I want the user to be able to choose a column number (from one of the input files), but I have a default column in mind. However, Galaxy doesn't seem to obey the default column number:
<inputs> <param name="a_vs_b" type="data" format="tabular" label="Hits from querying A against B" description="Tabular file, e.g. BLAST output" /> <param name="b_vs_a" type="data" format="tabular" label="Hits from querying B against A" description="Tabular file, e.g. BLAST output" /> <param name="id1" type="data_column" data_ref="a_vs_b" multiple="False" numerical="False" value="1" label="Column containing query ID" help="This is column 1 in standard BLAST tabular output" /> <param name="id2" type="data_column" data_ref="a_vs_b" multiple="False" numerical="False" value="2" label="Column containing match ID" help="This is column 2 in standard BLAST tabular output"/> <param name="score" type="data_column" data_ref="a_vs_b" multiple="False" numerical="False" value="12" label="Column containing containing score to rank on" help="The bitscore is column 12 in standard BLAST tabular output"/> </inputs>
I've tried giving the default column value numerically (as shown), and also using value="c2" etc. Regardless, Galaxy just defaults to the first column.
Is this a bug, or am I doing something wrong?
Thanks,
Peter ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
On Fri, Apr 1, 2011 at 3:55 PM, Kanwei Li <kanwei@gmail.com> wrote:
Hi Peter,
I don't see your attempt to use default in the example given. A bit more detail?
-K
Hi Kanwei, My example tool is now here: https://bitbucket.org/peterjc/galaxy-central/changeset/198bf927ca30 As per the original email, I have three parameters which are column numbers, and I want the defaults to be columns 1, 2 and 12. However, on my Galaxy installation they all default to the first column. I have tried giving the default values as 1, 2, and 12, and also as c1, c2 and c12 - neither works: https://bitbucket.org/peterjc/galaxy-central/changeset/374143be8e45 If you need more information, let me know. Thanks, Peter P.S. Bug filed here: https://bitbucket.org/galaxy/galaxy-central/issue/507/
On Fri, Apr 1, 2011 at 4:10 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Fri, Apr 1, 2011 at 3:55 PM, Kanwei Li <kanwei@gmail.com> wrote:
Hi Peter,
I don't see your attempt to use default in the example given. A bit more detail?
-K
Hi Kanwei,
My example tool is now here: https://bitbucket.org/peterjc/galaxy-central/changeset/198bf927ca30
As per the original email, I have three parameters which are column numbers, and I want the defaults to be columns 1, 2 and 12. However, on my Galaxy installation they all default to the first column.
I have tried giving the default values as 1, 2, and 12, and also as c1, c2 and c12 - neither works: https://bitbucket.org/peterjc/galaxy-central/changeset/374143be8e45
If you need more information, let me know.
Thanks,
Peter
P.S. Bug filed here: https://bitbucket.org/galaxy/galaxy-central/issue/507/
Trello migrated issue (where I have also commented): https://trello.com/c/6ugfcLgI/435-507-default-value-for-data-column-not-work... Partly solved, rather than looking at the value tag it seems to look at the default_value tag instead. I consider this a bug (a needless difference from the other parameter types), but out of backward compatibility (e.g. the boxplot tool) suggest this accept either tag name? Would a patch doing that be acceptable? Furthermore, regardless of the numerical setting, the defaults must not include the leading c (e.g. 2 rather than c2), see: https://github.com/peterjc/galaxy_blast/commit/eb9a26b21bf55266184cf00cfe692... Regards, Peter
Hey Peter, I opened a pull request to allow the use of the value attribute and to allow column numbers to be prefixed by c. I cannot see any problem with either change and I have added some unit tests. Hopefully, this makes things more intuitive. https://bitbucket.org/galaxy/galaxy-central/pull-request/389/small-column-pa... Thanks, -John On Mon, May 12, 2014 at 6:17 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Fri, Apr 1, 2011 at 4:10 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Fri, Apr 1, 2011 at 3:55 PM, Kanwei Li <kanwei@gmail.com> wrote:
Hi Peter,
I don't see your attempt to use default in the example given. A bit more detail?
-K
Hi Kanwei,
My example tool is now here: https://bitbucket.org/peterjc/galaxy-central/changeset/198bf927ca30
As per the original email, I have three parameters which are column numbers, and I want the defaults to be columns 1, 2 and 12. However, on my Galaxy installation they all default to the first column.
I have tried giving the default values as 1, 2, and 12, and also as c1, c2 and c12 - neither works: https://bitbucket.org/peterjc/galaxy-central/changeset/374143be8e45
If you need more information, let me know.
Thanks,
Peter
P.S. Bug filed here: https://bitbucket.org/galaxy/galaxy-central/issue/507/
Trello migrated issue (where I have also commented): https://trello.com/c/6ugfcLgI/435-507-default-value-for-data-column-not-work...
Partly solved, rather than looking at the value tag it seems to look at the default_value tag instead. I consider this a bug (a needless difference from the other parameter types), but out of backward compatibility (e.g. the boxplot tool) suggest this accept either tag name? Would a patch doing that be acceptable?
Furthermore, regardless of the numerical setting, the defaults must not include the leading c (e.g. 2 rather than c2), see: https://github.com/peterjc/galaxy_blast/commit/eb9a26b21bf55266184cf00cfe692...
Regards,
Peter ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Thanks John, For now I am setting both the value and default_value tags, e.g. https://github.com/peterjc/galaxy_blast/blob/master/tools/blastxml_to_top_de... However, in usability testing I have found a related problem/issue. In this tool I ask for several columns, including one which defaults to column 25. Provided the most recent tabular file in the history has this many (or more) columns, everything is fine. The problem is that if the most recent tabular file has less columns (e.g. 12), then the default value cannot be used - thus it is *silently* replaced with 1. The same problem of the column parameters being changed to column one can happen with switching the input file too. Once the user then switches to an appropriate tabular input file (which does have enough columns), but the column defaults are not reapplied, so column one gets used - and the output is wrong :( However, if I manually change a column option (e.g. to 24), then switch to an input file with less columns, rather than a *silent* substitution, although column one is picked, there is a nice red warning: "An invalid option was selected, please verify " I think the simplest fix would be to reapply the defaults everytime the associated input file is changed - but this might upset anyone who had for whatever reason manually picked different columns. Can we have this red warning when the default value is not possible and column one is substituted instead? Thanks, Peter P.S. Should this get a new Trello issue, or is the old one enough? https://trello.com/c/6ugfcLgI/435-507-default-value-for-data-column-not-work... On Mon, May 12, 2014 at 6:07 PM, John Chilton <jmchilton@gmail.com> wrote:
Hey Peter,
I opened a pull request to allow the use of the value attribute and to allow column numbers to be prefixed by c. I cannot see any problem with either change and I have added some unit tests. Hopefully, this makes things more intuitive.
https://bitbucket.org/galaxy/galaxy-central/pull-request/389/small-column-pa...
Thanks, -John
Hmm.... So my understanding of the way Galaxy sort of iteratively builds up tool parameters is that each time there is a state update it validates all of the old state (this is where the red errors come from) and then generates the new state - but it never validates the new state before re-rendering the form. At the beginning the whole state is "new" and this is why you don't get the red warning initially for the column not existing but you do upon subsequent form re-renders. The easiest way to demonstrate this behavior is take an empty history and click on the concatenate datasets tool. There are no warning initially even though the data parameter is empty and invalid - but if you click to "Add New Dataset" to the tool - it re-renders and you get a warning on the first data input but not on the new one. Same thing happens to the second input if you add another dataset to the repeat. I do not know why the initial state is not validated, but the following quick patch forces that new state to be validated if you want this behavior. It implements the red warning you were hoping for (at least on the initial rendering of the tool). A more complete patch might seek to validate all new state - or re-validate everything after state has been populated. https://gist.github.com/jmchilton/72767b794445fae63426 Anyone aware of pitfalls of enabling this behavior? Anyone besides Peter feel it is an issue that should be addressed? -John On Tue, May 13, 2014 at 6:16 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Thanks John,
For now I am setting both the value and default_value tags, e.g. https://github.com/peterjc/galaxy_blast/blob/master/tools/blastxml_to_top_de...
However, in usability testing I have found a related problem/issue. In this tool I ask for several columns, including one which defaults to column 25. Provided the most recent tabular file in the history has this many (or more) columns, everything is fine.
The problem is that if the most recent tabular file has less columns (e.g. 12), then the default value cannot be used - thus it is *silently* replaced with 1.
The same problem of the column parameters being changed to column one can happen with switching the input file too.
Once the user then switches to an appropriate tabular input file (which does have enough columns), but the column defaults are not reapplied, so column one gets used - and the output is wrong :(
However, if I manually change a column option (e.g. to 24), then switch to an input file with less columns, rather than a *silent* substitution, although column one is picked, there is a nice red warning:
"An invalid option was selected, please verify "
I think the simplest fix would be to reapply the defaults everytime the associated input file is changed - but this might upset anyone who had for whatever reason manually picked different columns.
Can we have this red warning when the default value is not possible and column one is substituted instead?
Thanks,
Peter
P.S. Should this get a new Trello issue, or is the old one enough? https://trello.com/c/6ugfcLgI/435-507-default-value-for-data-column-not-work...
On Mon, May 12, 2014 at 6:07 PM, John Chilton <jmchilton@gmail.com> wrote:
Hey Peter,
I opened a pull request to allow the use of the value attribute and to allow column numbers to be prefixed by c. I cannot see any problem with either change and I have added some unit tests. Hopefully, this makes things more intuitive.
https://bitbucket.org/galaxy/galaxy-central/pull-request/389/small-column-pa...
Thanks, -John
On Wed, May 14, 2014 at 1:51 AM, John Chilton <jmchilton@gmail.com> wrote:
Hmm.... So my understanding of the way Galaxy sort of iteratively builds up tool parameters is that each time there is a state update it validates all of the old state (this is where the red errors come from) and then generates the new state - but it never validates the new state before re-rendering the form. At the beginning the whole state is "new" and this is why you don't get the red warning initially for the column not existing but you do upon subsequent form re-renders.
The easiest way to demonstrate this behavior is take an empty history and click on the concatenate datasets tool. There are no warning initially even though the data parameter is empty and invalid - but if you click to "Add New Dataset" to the tool - it re-renders and you get a warning on the first data input but not on the new one. Same thing happens to the second input if you add another dataset to the repeat.
I do not know why the initial state is not validated, but the following quick patch forces that new state to be validated if you want this behavior. It implements the red warning you were hoping for (at least on the initial rendering of the tool). A more complete patch might seek to validate all new state - or re-validate everything after state has been populated.
https://gist.github.com/jmchilton/72767b794445fae63426
Anyone aware of pitfalls of enabling this behavior? Anyone besides Peter feel it is an issue that should be addressed?
-John
Hmm instead. This is a tricky one, and I don't know enough about the internals to have a technical opinion here. That sounds like it would solve my use-case, which is good. The potential downside of this is it could give red error boxes on things like required parameters with no default value - that might be considered scary/unfriendly? Peter
Yeah, I think you are right. It is probably best not to make that change. This request (both approaches you laid out) seem easy but turn out to be kind of awkward to implement. A high priority for the devteam is an AJAX rewrite of the tools page. Once all of this is client side I feel like we will be much more able to address this request cleanly. Parameters should then be able to interactively respond to update events on other parameters which I think is what we want to do here. Any objection to just creating a card now and waiting until the other side of the rewrite to address the issue? -John On Wed, May 14, 2014 at 5:27 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Wed, May 14, 2014 at 1:51 AM, John Chilton <jmchilton@gmail.com> wrote:
Hmm.... So my understanding of the way Galaxy sort of iteratively builds up tool parameters is that each time there is a state update it validates all of the old state (this is where the red errors come from) and then generates the new state - but it never validates the new state before re-rendering the form. At the beginning the whole state is "new" and this is why you don't get the red warning initially for the column not existing but you do upon subsequent form re-renders.
The easiest way to demonstrate this behavior is take an empty history and click on the concatenate datasets tool. There are no warning initially even though the data parameter is empty and invalid - but if you click to "Add New Dataset" to the tool - it re-renders and you get a warning on the first data input but not on the new one. Same thing happens to the second input if you add another dataset to the repeat.
I do not know why the initial state is not validated, but the following quick patch forces that new state to be validated if you want this behavior. It implements the red warning you were hoping for (at least on the initial rendering of the tool). A more complete patch might seek to validate all new state - or re-validate everything after state has been populated.
https://gist.github.com/jmchilton/72767b794445fae63426
Anyone aware of pitfalls of enabling this behavior? Anyone besides Peter feel it is an issue that should be addressed?
-John
Hmm instead. This is a tricky one, and I don't know enough about the internals to have a technical opinion here.
That sounds like it would solve my use-case, which is good.
The potential downside of this is it could give red error boxes on things like required parameters with no default value - that might be considered scary/unfriendly?
Peter
Thanks John, That sounds like a sensible compromise, especially if this AJAX rewrite is a high priority and likely to happen relatively soon. Peter On Wed, May 14, 2014 at 11:55 AM, John Chilton <jmchilton@gmail.com> wrote:
Yeah, I think you are right. It is probably best not to make that change.
This request (both approaches you laid out) seem easy but turn out to be kind of awkward to implement. A high priority for the devteam is an AJAX rewrite of the tools page. Once all of this is client side I feel like we will be much more able to address this request cleanly. Parameters should then be able to interactively respond to update events on other parameters which I think is what we want to do here. Any objection to just creating a card now and waiting until the other side of the rewrite to address the issue?
-John
participants (3)
-
John Chilton -
Kanwei Li -
Peter Cock