Add data labels so the tools works in the workflow editor and added a conditional switches to some with collection params and multiple input data parameters to test some state-y logic in workflow editor.
Detail bug report from Michael Crusoe here : https://trello.com/c/0mdGCx4P.
This also fixes a test case added in 289e48b which was both attempting to assert something wrong and was incorrectly implemented. Augmenting the workflow editor test suite with some actually valid test cases that assert the correct behaviors.
For a longer explaination - workflow input terminals have two related concepts 'canAccept' and 'attachable'. An output terminal is 'attachable' if in the abstract it could be attached to the input regardless of whether the input is already filled or not. 'canAccept' is more stateful in that an output terminal is 'canAccept'able if the input terminal is not filled ('_inputFilled') and it is 'attachable'.
So - the problem was 'attachable' was not correctly defined for a multiple input data parameters. 'attachable' was asserting that any connected input terminal could not be 'attachable' by an collection output terminal - so on these asynchronous node state changes collections attached to multiple input data parameters were being wiped out. The more percise/correct distinction is that if a multiple input data parameter has single inputs connected to it - it cannot also have a collection connected to it (yet anyway). This fixes the mentioned bug.
The problematic test case was conflating 'attachable' and 'canAccept'able - I have fixed the test case to verify the correct 'attachable' logic and added newer, higher level test cases to test the canAccept logic and the actual behavior the end user would observe (of the connector being destroy).
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.
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).
Elminate stub, create mock tree off inputs (demonstrates what server is feeding), add test for direct and subtype. Add tests for PJA changing output connection datatypes.
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.
This work is based on QUnit and tests are runnable in-browser without any external dependencies or via command-line using grunt and PhantomJS. See README.txt in `test/qunit` directory for more information on how to run tests.
A test case is defined by an HTML and JavaScript source file. The file `test-common.js` will bootstrap most of the minimal HTML needed for qunit and configure require so nearly all testing logic is isolated into test js file. An example test is included that demonstrates how to build tests using requirejs's `define` and target backbone components. Tests can target non-backbone code as well.
Sinon is included for stubbing out server interactions, etc... when testing backbone components. This seems to be a popular fallback for backbone projects not using Jasmine.
Carl Eberhard