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

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.

Anyone aware of pitfalls of enabling this behavior? Anyone besides
Peter feel it is an issue that should be addressed?


On Tue, May 13, 2014 at 6:16 AM, Peter Cock <> wrote:
> Thanks John,
> For now I am setting both the value and default_value tags, e.g.
> 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?
> On Mon, May 12, 2014 at 6:07 PM, John Chilton <> 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.
>> Thanks,
>> -John
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:

To search Galaxy mailing lists use the unified search at:

Reply via email to