Thanks Greg for this nice example, I guess this is useful for others as
well!
I will try to put it into the Wiki soon.

Advertising

Am 30.09.2015 um 20:05 schrieb Greg Von Kuster:
> Here’s the answer to my question:
>
> The ability to use associated dynamic select lists on Galaxy tool forms where
> selecting an option in the first select list dynamically re-renders the
> options in the second select list is possible after this change:
>
> https://github.com/galaxyproject/galaxy/pull/815
> <https://github.com/galaxyproject/galaxy/pull/815>
>
> In my case, I am populating both dynamic select lists from metadata elements
> associated with my tool’s single input dataset. The 2 metadata elements I’m
> using look like this.
>
> MetadataElement( name="field_names", default=[], desc="Field names",
> readonly=True, optional=True,
> visible=True, no_value=[] )
> # The keys in the field_components map to the list of field_names in the
> above element
> # which ensures order for select list options that are built from it.
> MetadataElement( name="field_components", default={}, desc="Field names
> and components",
> readonly=True, optional=True, visible=True, no_value={} )
>
>
> My tool config includes a code file tag like this.
>
> <code file="tool_form_utils.py" />
>
>
> Here are the relevant input parameters in my tool config. The first
> parameter is the input dataset that includes the above metadata elements.
>
>
> <param name="input" type="data" format="vtkascii,vtkbinary"
> label="Shape with uncolored surface field">
> <validator type="expression" message="Shape must have an
> uncolored surface field.">value is not None and
> len(value.metadata.field_names) > 0</validator>
> </param>
>
>
> The following parameter dynamically renders a select list consisting of the
> elements in the “field_names” metadata element associated with the selected
> input dataset.
>
>
> <param name="field_name" type="select" label="Field name"
> refresh_on_change="True">
> <options>
> <filter type="data_meta" ref="input" key="field_names"/>
> <validator type="no_options" message="The selected shape has
> no uncolored surface fields." />
> </options>
> </param>
>
>
> The following parameter calls the “get_field_components_options() method in
> the “tool_form_utils.py” code file discussed above. This method returns the
> value of the input dataset’s “field_components” metadata element dictionary
> whose key is the currently selected “field_name” from the select list
> parameter above.
>
>
> <param name="field_component_index" type="select" label="Field
> component index" dynamic_options="get_field_components_options(input,
> field_name=field_name)" help="Color will be applied to the selected field's
> component associated with this index." />
>
>
> Changing the selected option in the “field_name” select list will dynamically
> re-render the options available in the associated “field_component_index”
> select list, which is the behavior we want.
>
>
> The “get_field_components_options() method looks like this.
>
> def get_field_components_options( dataset, field_name ):
> options = []
> if dataset.metadata is None:
> return options
> if not hasattr( dataset.metadata, 'field_names' ):
> return options
> if dataset.metadata.field_names is None:
> return options
> if field_name is None:
> # The expression validator that helps populate the select list of
> input
> # datsets in the icqsol_color_surface_field tool does not filter out
> # datasets with no field field_names, so we need this check.
> if len( dataset.metadata.field_names ) == 0:
> return options
> field_name = dataset.metadata.field_names[0]
> field_components = dataset.metadata.field_components.get( field_name, [] )
> for i, field_component in enumerate( field_components ):
> options.append( ( field_component, field_component, i == 0 ) )
> return options
>
>
> Greg Von Kuster
>
>
>> On Sep 20, 2015, at 9:51 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
>>
>> Hello all,
>>
>> I’m working on adding support to the Galaxy framework for datatypes in the
>> constructive solid geometry (CSG) space and I have several working Galaxy
>> tools and a visualization plugin that deal with 3d shapes in this
>> environment. All of this work will soon be contributed to open source.
>>
>> For one of the tools, I need to provide 2 select lists on the tool form that
>> are associated in such a way that when an option in select list 1 is chosen,
>> the options in select list 2 are altered and re-rendered. This behavior
>> would probably use a combination of dynamic options and refresh_on_change
>> between the 2 associated select lists.
>>
>> I’ve not seen a tool that does this precisely, so I’m hoping that if it is
>> currently possible to do this within Galaxy tools, someone will point me to
>> an example.
>>
>> If it is not currently possible, I will contribute a PR for supporting it,
>> but would like some input as to how it should be done.
>>
>> Dynamic options are currently rendered using 4 approaches; from_file,
>> from_dataset, from_parameter and from_data_table. One or more of several
>> filters can then be applied to the options to alter them if desired.
>>
>> Since these CSG tools involve new datatypes, I have flexibility into how the
>> metadata elements are set up that are needed to render these 2 select lists.
>> A dictionary may work where the metadata element contents look like this:
>>
>> {a: [‘1’, ‘2’], b: [‘3’, ‘4’] }
>>
>> The options in select list 1 would be ‘a’ and ‘b’. When ‘a’ is selected,
>> select list 2 would have options ‘1’ and ‘2’, and when ‘b’ is selected,
>> select list 2 would have options ‘3’ and ‘4’.
>>
>> To support this approach, perhaps dynamic options could be enhanced to
>> include a from_dict option. There would be some complxity involved in
>> associating the lists using refresh_on_change so that select list 2 is
>> refreshed with the correct options when select list one is changed. I
>> haven’t yet worked out these details.
>>
>> Also, using a dictionary will not keep order for the options, so perhaps a
>> list of tuples would be better?
>>
>> [ [ ‘a’, [‘1’, ‘2’]], [‘b’, [‘3’, ‘4’]]]
>>
>> Can someone let me know if this is currently possible, and if so, an example
>> tool that does it? If it’s not possible, does the above approach seem
>> reasonable, or is there a better way?
>>
>> Thanks very much,
>>
>> Greg Von Kuster
>> ___________________________________________________________
>> 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:
>> https://lists.galaxyproject.org/ <https://lists.galaxyproject.org/>
>>
>> To search Galaxy mailing lists use the unified search at:
>> http://galaxyproject.org/search/mailinglists/
>> <http://galaxyproject.org/search/mailinglists/>
>
>
>
> ___________________________________________________________
> 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:
> https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
> http://galaxyproject.org/search/mailinglists/
>
___________________________________________________________
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:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/