> So is the behavior of the optional="true" tag that if the field form is left 
> empty for that parameter then it will not be passed to the tool?

Optional is enforced at the UI level; a wrapper can choose to handle optional 
parameters differently.

> I am wondering if a more sophisticated behavior on the UI side of things for 
> the "optional" tag would still allow for recording that the parameter is 
> using the default value for the version of that tool but not actually pass 
> that parameter on the command line in case it influences the behavior of the 
> tool? Thinking of parameters that should have a default value but whose 
> actual presence on the command line changes what happens. Though, I guess 
> this could be done by simply deleting the default value in the optional 
> parameter has one?
> Maybe if the optional tag enabled the parameter itself to be toggled on/off 
> (grayed out/regular text)? This way a block of advanced parameters could be 
> enabled without requiring that they all be passed to the tool (or deleting 
> all their values if they are marked optional).

There are two issues to consider:

(1) Whether the UI is friendly when a tool has many parameters. Clearly, there 
are improvements to be made, but Galaxy makes it relatively easy to ignore 
parameters that aren't of interest. A novel UI approach might try to make it 
easier to hide unwanted parameters from view or selectively set certain 

(2) Whether optional parameters should be passed to the wrapper. IMHO, there's 
no reason not to make all user input available to the wrapper. A tool that 
doesn't produce the same output when (a) parameter values are not specified and 
(b) default parameter values are specified is buggy and should be fixed.

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:


Reply via email to