dont trigger the jsPlumbConnection event when a connection is programmatic created.

[GoogleCodeExporter]

When a new connection is made with the 'connect' function, this function 
trigger the 'jsPlumbConnection' event. This is in some cases not desired and 
needs to turned off. 

I persistent store the created graph in a database. When the user draws a 
connection, the connection is register with the jsPlumbConnection event. 
When the page gets refreshed, all connections are restored with the 'connect' 
function. But this triggers the jsPlumbConnection event again!
Yes, this can be checked with the scopeid (the solution now), but I lose a lot 
of speed (80 events are triggered for nothing)

Original issue reported on code.google.com by j.verdur...@2bmore.nl on 6 Jan 2012 at 7:27

[GoogleCodeExporter]

This is an enchantment. Dunno how to set in the issue.

Original comment by j.verdur...@2bmore.nl on 6 Jan 2012 at 7:29

[GoogleCodeExporter]

version 1.3.3

Original comment by j.verdur...@2bmore.nl on 6 Jan 2012 at 7:35

[GoogleCodeExporter]

yeah i can see what you mean with this.  the event stuff was added to support 
callbacks from user actions;  hacing the programmatic API fire the events was 
never the original intention and i would expect most people's use cases would 
be like yours.  what i think i will do is turn off the event fire by default, 
but allow the user to supply a parameter indicating they want it to fire, so 
like

jsPlumb.connect({source:d1, target:d2, fireEvent:true});

this will cover those rarer cases where someone does want the behaviour, as 
well as providing a hook for backwards compatibility purposes in case there are 
people relying on it already.

your timing is good with this issue; i was about to release 1.3.4.  but i think 
i'll sneak this in before i do so.

Original comment by simon.po...@gmail.com on 6 Jan 2012 at 11:27

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

[GoogleCodeExporter]

...i will have to also update the jsPlumb.detach method with the same parameter 
of course.

Original comment by simon.po...@gmail.com on 6 Jan 2012 at 11:47

[GoogleCodeExporter]

i've done this, but the opposite way round to what i said i would do: you have 
to supply the directive to jsPlumb that you do not want to fire the event.

jsPlumb.connect({source:d1, target:d2, fireEvent:false});

ie. the default behaviour is still to fire the connect event.  same goes for 
detach:

jsPlumb.detach(someConnection, {fireEvent:false});

or

jsPlumb.detach({source:someId, target:someId, fireEvent:false});

also i updated detachEveryConnection:

jsPlumb.detachEveryConnection({fireEvent:false});

and detachAllConnections:

jsPlumb.detachAllConnections(someId, {fireEvent:false});

this will be in the 1.3.4 release.

Original comment by simon.po...@gmail.com on 7 Jan 2012 at 4:51

• Changed state: Fixed

[GoogleCodeExporter]

Great news! THX

Original comment by j.verdur...@2bmore.nl on 7 Jan 2012 at 12:53

[GoogleCodeExporter]

1.3.4 was released today.

Original comment by simon.po...@gmail.com on 9 Jan 2012 at 6:59

• Changed state: Verified

[GoogleCodeExporter]

Hi,

I'm upgrading to 1.3.7, but I see that 'fireEvent' is only documented with 
'detach' and not with 'connect'. Is this intended? 

Original comment by j.verdur...@2bmore.nl on 9 Mar 2012 at 3:01

[GoogleCodeExporter]

i'm not sure what you mean. fireEvent is an internal method, not exposed as 
part of the public API.  1.3.7 supports all of the events that previous 
versions supported.

Original comment by simon.po...@gmail.com on 9 Mar 2012 at 9:50

[GoogleCodeExporter]

I sorry, I meant the parameter 'fireEvent' with the functions 'detach' and 
'connect'

So, the parameter is documented with detach:
http://jsplumb.org/apidocs/files/jquery-jsPlumb-1-3-7-all-js.html#detach
http://jsplumb.org/apidocs/files/jquery-jsPlumb-1-3-7-all-js.html#Endpoint.detac
h

but not with connect:
http://jsplumb.org/apidocs/files/jquery-jsPlumb-1-3-7-all-js.html#connect

Original comment by j.verdur...@2bmore.nl on 12 Mar 2012 at 3:32

[GoogleCodeExporter]

oh i see. yes i think it is still supported. have you tried it?

Original comment by simon.po...@gmail.com on 12 Mar 2012 at 6:34

[GoogleCodeExporter]

It just added in 1.3.4, so I think it's supported ;) (see this issue).

Anyway, it works and it saves a lot of unnecessary events which increased the 
performance! :) (tested with 80 connections programmatic created).

Original comment by j.verdur...@2bmore.nl on 12 Mar 2012 at 8:56

[GoogleCodeExporter]

yeah i quite like it.

you might also want to look at 

jsPlumb.setSuspendDrawing( true );

if you're creating a bunch of connections at page load - it suspends all 
painting until you do this:

jsPlumb.setSuspendDrawing( false );
jsPlumb.repaintEveryConnection();

or 

jsPlumb.setSuspendDrawing( true, true );

(optional second argument that tells jsPlumb to a full repaint immediately 
afterwards)

Original comment by simon.po...@gmail.com on 12 Mar 2012 at 9:01

[GoogleCodeExporter]

Thx for the advice. I already uses that option, and i'm very happy with that :)

But I noticed that setSuspendDrawing doesn't influence the creation of 
endpoints? 

Original comment by j.verdur...@2bmore.nl on 12 Mar 2012 at 9:07