Outputs droppable on inputs from same Operation

That's neat, but putting this functionality in the drop function still causes the elements to be dropped where they shouldn't be allowed to be dropped. (Which means the droppables will still be highlighted, and that's bad for usability.)

Instead, we could use the "accept" property of droppable that can also be a function instead of a CSS class. So the best thing to do is to have a function (I'd probably name it transformationsUiIsDroppable(), as a name like transformationsFromSameOperation() limits the scope of what it can do - also, it lacks the "Ui" part in the function name!) and let that function check the CSS class that is currently assigned to the "accept" property, *plus* a check for same operation and pipeline parameter/output combinations that are not allowed. With that function, the user cannot even drop the connector, which means the check in the drop function is unnecessary.

Also, try hard to follow coding standards. (Sorry to nitpick on this, but they are indeed important.) In particular:

1. Correct indentation (lines 15 and 16 of the patch file)
2. No trailing spaces (lines 17, 35, 54 and 55)
3. A separating space between function arguments (lines 18 and 36)
4. A separating space between braces ("{" and "}") and other tokens, such as parentheses, "if" or "else" keywords, or other operators like "==" (lines 18, 36, 51, 55, 56 and 58)
5. "}" and "else {" go on separate lines (line 58)
6. Comments are preferred in command form ("Check blah") instead of explanation form ("Checks blah"), and are trailed by a period (lines 48 and 49)
7. Also regarding comments, be exact with the terminology: "operation" as a concept does not start with an uppercase character (that's only used for camel casing like "TfOperation") (line 48), and pipelines are always "pipelines" not "pipes" (line 49)
8. Not really against the coding style guidelines, but if functions with their arguments fit into one line and under 80 characters (such as in lines 19-21 and 37-39) then you don't necessarily need to linebreak, that makes it a bit easier to read usually. That's more a question of taste, though.

No testing yet, but this looks like it should work out from a UI behavior point of view.

Most coding standard issues that applied to the new function have not yet been fixed, though. I'll just reference the bullet points numbers from above, with updated line numbers:

#2: line 36 in the new patch
#4: line 31, 32, 35, 36, 37 and 39
#5: line 39
#6: line 28
#7: line 28 and 29

I could fix those by myself, but I thought you might want to do it by yourself for the learning effect :P

Nearly. There's still no space after "if", "else" and the second "==" on line 36, and the comment still says "Checks ..." instead of "Check ..." (plus a few spelling issues that I don't care about if you're not a native speaker) but other than that, it's fine now :]

I did the last few adaptations by myself, and restructured the code a bit to be yet cleaner and better readable. Attached to this comment, you can find the patch that I finally used.