This commit enables the workflow editor to deal with input collection data parameter types and inputs (easy) and much more complicatedly reason about mappings and reductions over inputs and collection inputs. Not sure I can really describe the new interface in a changeset - essentially it is more complicated to determine if a input can be connected to by an output - and that connection affects what are valid other inputs and what the outputs are.
Allow users to select dataset collections in place of individual datasets for data tool parameters with multiple="true" enabled (if all elements of collection would be valid as input to this parameter).
Restrict collection reductions to flat collections. If a user wanted to reduce a nested collection they probably want to map of the subcollections reducing each and building a collection of the reductions. TODO: The sentence is probably unintelligiable, need to provide a concrete example.
A functional test demonstrating these reductions in included.
This makes room for a forth coming HistoryDatasetCollectionAssociation model that will be emitted from the history contents API. Same comment as previous changeset applies - this is a potentially crude way to share duplicated functionality and a better design would be most welcome.
In particular, add a new backbone parent model (HistoryContent) refactored out of HistoryDatasetAssociation. This makes room for a forth coming HistoryDatasetCollectionAssociation model that will be emitted from the history contents API.
There are likely better ways to share common functionality between a dataset and a dataset collection contents - more JS savy developers should feel free to refactor into smaller mixins for instance. For now HistoryContent is just composed of the overlap in functionality between dataset and collection representations downstream and is an quick and dirty way to share said functionality.
These have been nothing but trouble (they have been disabled some places) and are awkward in those places that have not been changed.
Is there any place in Galaxy where multi-select inputs + select2 are being used to create a desirable UX? If yes, can we just create a class for these particular widgets and target it with a boolean expression on the same line?
This fixes at least one subtle bug related to multiple input data parameters (actually probably two bugs) because the old logic assumed there was only one connector per input terminal.
This should be more efficient, lead to some code duplication deletion in subsequent changesets, and really help dataset collections where terminals are much more complex (there are data inputs and collection inputs, and each can be mapped over by collections) - this helps manage complexity downstream.
Workflow editor would preserve connections when a tool would update its state (for instance switching a conditional or adding repeat) - but conditional switching can result in connections being invalid (wouldn't have passed can_accept previously). Consider the following tool for instance which changes datatypes of an input based on a conditional (https://gist.github.com/jmchilton/11152628).
Want to reuse attachable right away to fix a bug - and the smaller pieces are good refactoring to support different kinds of input types in dataset collections downstream.
Was previously declined so that pull request #370 could be resolved first - but upon actually inspecting #370 I don't think these will conflict in anyway.
Martin Cech