Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | A javascript wiring library to create web wirable interfaces for dataflow applications, visual programming languages or graphical modeling. edit |
-
Attach a DOM element to the wire that can contain some informations.
Use ful for modeling (adding liaisons informations)Need a way to add a description to a wire like 1,2,3 for numbering or anything else as a text.
Comments
-
0 votes
#wrapper { margin:auto; width:800px; } var layer = document.getElementById('layer'); new WireIt.Layer({parentEl:layer}); The above wraps the layer in a div that centres everything. You will note that if you try to drag a wire around, the end of the wire is not connected to your mouse cursor but is displaced by the same distance as the wrapper is moved from the side of the screen. * Comments and changes to this ticket * jgoeth jgoeth July 28th, 2009 @ 12:34 PM I'm facing exactly the above problem. I'm desperatly looking for a workaround. Is there a solution for it? Thanks edit * eric.abouaf (at gmail) eric.abouaf (at gmail) August 10th, 2009 @ 03:14 PM Hi, Ths solution would be to position the editing wire in the layer element. This is handled by WireIt.TerminalProxy (in Terminal.js) I'll have a look at it later... By the way, I'm moving the issue tracker on github (they have one now....) ++Comments
-
if terminal not visible, give the offset of the first parent DOM element visible ?
Comments
-
Adding a DOCTYPE stops the layer from rendering properly - it ends up at the top of the screen. To see this problem, add any DOCTYPE to the "Spring model layout" example, which currently has this at the top of the document:
<?xml version="1.0" encoding="UTF-8"?>
If you replace that with, for example: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
The problem appears.
J.
Comments
-
0 votes
highlights Terminals with compatible types in Layer
0 comments Created 4 months ago by neyricComments
-
2 votes
WiringEditor: treeview for module list (or accordion)
2 comments Created 4 months ago by neyricComments
This also is a feature I want for an XProc editor or Yahoo Pipes-like system. Yahoo Pipes already has the modules sorted by category. And for XProc, I was thinking it would be nice to have separate accordion lists for module categories, like core, standard lib, optional... and also to be able to load libraries of modules on the fly.
I can't agree more :)
As you can see in v0.5.0, I added the yui-accordion-view library on the right of the WiringEditor. I was thinking we could use the same for the left module list.
I'll vote for this ticket too ^^ ( I love this new issue tracker, right on GitHub !)Your second proposition: "loading modules on the fly" is also something I would vote for. I think it deserves its own ticket...
-
* lamp module * clock module * simulation modeComments
-
Comments
-
0 votes
Terminal.isValidWireTerminal() handles allowedTypes not well
1 comment Created 3 months ago by reedomI've made a fix against version 0.5.0, attached in the bottom.
background
First of all, excuse me that I can't describe the issue in English well. So I illustrate it.
Well, I've defined some FormContainers like:
| +-------------+ | | HTML Reader | | +------+------+ | | <- outputs `text' | | | | | ------------+-----------+ | | | | | | | | <- inputs `text' | <- inputs `text' or `feed' | +-------+--------+ +---+---+ | | Replace String | | XPath | | +-------+--------+ +---+---+And terminal definition is: (very simplified)
modules: [ { "name": "HTML Reader", "terminals": [ { "name": "out", "ddConfig": { "type": "textOutput" } } ] }, { "name": "Replace String", "terminals": [ { "name": "in", "ddConfig": { "type": "textInput", "allowedTypes": [ "textOutput" ] } } ] }, { "name": "XPath", "terminals": [ { "name": "in", "ddConfig": { "type": "feedInput", "allowedTypes": [ "textOutput", "feedOutput" ] } } ] } ]The current implementation doesn't allow to connect like as the graph above.
To allow, I needed to modify the code Terminal.js as below:--- js/Terminal.js:392 /** * @method isValidWireTerminal */ isValidWireTerminal: function(DDterminal) { if( !DDterminal.isWireItTerminal ) { return false; } // Check the allowSelfWiring if(this.terminal.container) { if(this.terminal.container.options.preventSelfWiring) { if(DDterminal.terminal.container == this.terminal.container) { return false; } } } // If this terminal has the type property: if(this.termConfig.type) { if(this.termConfig.type == DDterminal.termConfig.type) { return true; } if(this.termConfig.allowedTypes) { if(0 <= WireIt.indexOf(DDterminal.termConfig.type, this.termConfig.allowedTypes)) { return true; } } } // The other terminal may have type property too: if(DDterminal.termConfig.type) { if(DDterminal.termConfig.allowedTypes) { if(0 <= WireIt.indexOf(this.termConfig.type, DDterminal.termConfig.allowedTypes)) { return true; } } } return false; }Comments
-
See jsTalk email...
Comments
-
It see that when the wireit lib is included it sets the global YAHOO.util.DDM.mode to YAHOO.util.DDM.INTERSECT. Because we intensively use drag 'n drop in our application this seriously affects performance (intersect mode is slower than point). I wasn't able to do that anymore if i disable the intersect mode so it seems that this is needed to detect when a wire is over a terminal.
Is it an idea to only change YAHOO.util.DDM.mode on startDrag / endDrag in WireIt.Terminal? Then the intersect mode is only active when dragging a wire. This fixed the issue for us but it might be nice to have this included in master.
Comments
This would be very useful for representing a core XProc feature: Pipeline inputs can have a "select" statment on them, that filters which part of that pipe you want to to use as the input of your container. I was thinking something like this would be handy for representing that.
Maybe it's more fit into a "Terminal" Label ?
I think we need both: to be able to add a label on a Terminal (at both ends of the Wire)
or a label in the "middle" of the wire.
What do you think ?
Do you need your "select" statement to be editable ?
Editable would be helpful, but static would work for me.