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?


On Wed, May 14, 2014 at 5:27 AM, Peter Cock <> wrote:
> On Wed, May 14, 2014 at 1:51 AM, John Chilton <> 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.
>> 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
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