duplicate id's sometimes are given to endpoints and connectors

[GoogleCodeExporter]

It appears that sometimes, endpoints and connectors can end up with duplicate 
ID's. In the generated HTML below, you can see the id for the endpoint and the 
connector are the same. This caused me some confusion when trying to manipulate 
the connectors with jQuery scripts and the getConnections(). Some scripts were 
getting executed on the endpoints rather than the connector because they shared 
the same ID. 

Each generated element should have a unique id.

<canvas style="position: absolute; height: 2px; width: 2px; left: 318px; top: 
207px; " class="_jsPlumb_endpoint " id="jsPlumb_1318996524609" height="2" 
width="2"></canvas>
<canvas style="position: absolute; height: 151px; width: 60.5px; left: 318.5px; 
top: 57.5px;" class="_jsPlumb_connector " id="jsPlumb_1318996524609" 
height="151" width="60"></canvas>

I found a work-around for my script, by selecting the class type in conjunction 
with the id, but that may not always work.

Original issue reported on code.google.com by john.dil...@gmail.com on 19 Oct 2011 at 4:02

[GoogleCodeExporter]

can you tell me what the code was that produced this? does it happen 
consistently, or just randomly (i suspect randomly)?

Original comment by simon.po...@gmail.com on 19 Oct 2011 at 4:28

[GoogleCodeExporter]

Sorry it took so long to put this together, I got distracted...

Here's a jsFiddle with the code where the issue is visible. It does seem to be 
random as to which elements end up with duplicate IDs, but it does occur 
consistently.

http://jsfiddle.net/johndilworth/vDmdR/

Original comment by john.dil...@gmail.com on 2 Nov 2011 at 4:40

[GoogleCodeExporter]

thanks for that.  marking this issue accepted.

for quite some time my preference has been for jsPlumb to stop assigning ids 
itself - i'm not a fan of software that imposes itself on the environment to 
such an extent - so i've been thinking about just using a jsPlumb internal id.  
but obviously if i do that i will still have to ensure that the ids i'm giving 
out are unique.

it uses a primitive mechanism for assigning ids at the moment - a datestamp.  i 
haven't stepped through the code but i suppose it would appear to be running 
fast enough for the "new Date()" call to return the same date to consecutive 
calls.  probably it would just be safe for me to increment an integer, in fact. 
 i can't really imagine a situation in which jsPlumb will be required to serve 
2^53 element ids!

Original comment by simon.po...@gmail.com on 2 Nov 2011 at 10:29

• Changed state: Accepted
• Added labels: Milestone-1.3.4

[GoogleCodeExporter]

um, actually, can you tell me what you're trying to have happen in that demo?  
there's a whole bunch of code in there.  is it broken when i land on it, or 
working? 

Original comment by simon.po...@gmail.com on 3 Nov 2011 at 1:34

[GoogleCodeExporter]

The demo is working - I just noticed the duplicate id issue and wrote a work 
around for it.

The demo shows how hovering over one element will highlight all of the 
connected elements, and set the z-index of the connector so that it is on top 
of the other connectors.

The line of javascript containing the following only works if I select the 
element ID along with the _jsPlumb_connector class, otherwise it will not work 
due to the duplicate id problem.

Here's a version that is broken and does not work. You'll notice that the when 
you hover over elements, the connectors are set to hover state, but on some 
elements (those with duplicate id's) the line may be below other lines.

broken: ($(theid).css("z-index", '1'); 
http://jsfiddle.net/johndilworth/vDmdR/3/

with jquery work-around $(theid+'._jsPlumb_connector').css("z-index", '1'); 

http://jsfiddle.net/johndilworth/vDmdR/2/

There is quite a bit of code there, if you could suggest a better way to 
accomplish the same thing that would be bonus points..

Thanks,

John

Original comment by john.dil...@gmail.com on 3 Nov 2011 at 1:57

[GoogleCodeExporter]

ha, yes, bonus points.  

that jsFiddle, the one you said was broken, actually works for me.  but given 
the nature of the issue, and the likely cause, it's not entirely surprising for 
it to work sometimes and not others.  i reloaded it quite a few times and it 
always worked.  but anyway. switching the timestamp() method to return a 
monotonically increasing integer will guarantee that no id clash can ever occur.

as for the complexity of the code, yeah it does seem like a lot of hoops to 
have to jump through to achieve what you want.  it feels related (not exactly 
the same, since this one talks about dragging, but near enough) to the request 
outlined here:

http://code.google.com/p/jsplumb/issues/detail?id=46

which i flagged as "sometime in the future".  maybe that time is soon.

Original comment by simon.po...@gmail.com on 3 Nov 2011 at 3:13

[GoogleCodeExporter]

this is fixed in dev now, the timestamp bit anyway.

the other stuff, about possibly adding a css class to everything affected by 
some mouse event, we can track that in the other issue if needs be.

Original comment by simon.po...@gmail.com on 5 Nov 2011 at 7:36

• Changed state: Fixed