jsPlumb's dependency on jQuery

[Oliver Kopp]

Dear Simon,

2013/7/18 jsPlumb News wrote:

> Also in 1.5.0 will be the first steps to removing jsPlumb's dependency on an underlying library such as jQuery, something I've wanted to do for quite some time, for various reasons (not for dragging...well, maybe for dragging. I can't decide whether to support dragging natively in jsPlumb or whether it's actually more useful for people to use some library. I suspect the latter).

I think, depending on jQuery is not an issue. The main thing is the dependency on jQueryUI: We recently switched from jQuery+jQuery.UI to jQuery+Bootstrap. When using jsPlumb, we still need (parts of) jQuery.UI. Although it would be nice to have that dependency removed, I think, reimplementing drag'n'drop is hard, isn't it?

Cheers,

Oliver

[Simon Porritt]

There are a couple of reasons why the jQuery dependency is a problem - firstly, it doesn't handle SVG elements very well; it can't add classes, for instance, so jsPlumb's addClass function has to take this into account, and it may as well just do the whole thing itself. Secondly, and more importantly, jQuery doesn't support CSS3 transforms properly, and jsPlumb's main usage of jQuery is for the `offset()` and `size()` functions, both of which do not report correct values when a CSS3 transform is applied to the element in question.  Given that many applications that use jsPlumb are the sorts of apps in which you wish to be able to support zooming, this is problematic, and suggests I should do something to support CSS3 transforms.  But rather than try to work around jQuery's shortcomings I may as well just ditch the dependency entirely and do it myself.

As for jQuery UI, it's interesting to hear you say that in your opinion it is that dependency which is more problematic.  I've never really gone out to canvas people's opinions about it, but I've been under the impression that most people would prefer to use jQuery UI for dragging than have jsPlumb provide it, since jsPlumb managed elements also need to interact with other parts of a UI from time to time.  Also, of course, supporting drag is a slippery slope, since I can foresee that if I provide a rudimentary drag option sooner or later someone will write to me and ask for such things as containment within a parent, grid, etc etc.  Those would all be valid requests, of course; I'm just not really keen to reinvent that particular wheel.

One thing I *could* do, however, is handle connection dragging without a dependency on an underlying library, and just provide a hook for attaching a drag manager for elements.  This would actually bring several advantages for jsPlumb itself: I could finally implement multiple scopes, for instance. And I could support CSS3 transforms seamlessly.  This would of course increase the size of the library, which I find unappealing. It's already too big and I'm on the lookout for ways to reduce the size of the codebase, so I'm unlikely to look at this before I get it down to a size I find a bit more acceptable.

[Oliver Kopp]

Is there possiblity to fix jQuery's CSS3 handlings? I think, many users would appricate if jQuery worked correctly. Think, they are open for patches :-). And it would also keep your code small :-)

I'm also a fan of code-reuse, therefore I understand that keeping jQuery UI is a "better" option. Did I get it correctly, that jQuery UI is always used, but one has the choice between jQuery/mootools/yui for DOM manipulation (guessed based on the filenames in build/js)

[Simon Porritt]

Here's a ticket that shows jQuery's attitude about transforms:

http://bugs.jquery.com/ticket/11114

It's not correct that jQuery UI is always required if you want to support dragging; that is the case only when you use jQuery as the underlying library:

http://jsplumbtoolkit.com/doc/setup#imports

[Roland Guijt]

Dear Simon,

I totally agree with Oliver about the jQuery UI dependency.

The only reason I have jQuery UI hanging around in projects, is because jsPlumb needs it.

I'm using Kendo UI for the widgets.

Bye,

Roland

[Simon Porritt]

Thanks for the update Roland.

It sounds like a good first step might be for me to look at ways to make the dragging pluggable...

[Wojciech Makowiecki]

Hi Simon,

I also ran into troubles with jQuery UI Draggable and CSS3,

when implementing CSS3 zooming (I was using browser zooming before ;)

When I zoom, mouse handling scales and creating arrows is getting really weird.

And as you said before jQuery UI people decided on not fixing that !!!

here is one more link with status WON'T FIX : http://bugs.jqueryui.com/ticket/6844

This is really frustrating as, I guess, I must stick with the browser's zoom which is really ugly, slow 

and definitely temporary solution as it scales other areas of my app that should stay the same size. 

So yes, I would definitely support your decision to abandon jQuery UI, the sooner the better !!!

Maybe you could switch to some other library that supports CSS3 with draggable ?

Have you made any progress on this issue ? 

or maybe there is some workaround ? 

(I'd really like to make my diagrams zoomable).

-- 

Best,

Wojciech

[Simon Porritt]

people are having mixed results - mostly good, but a couple of misses - with the setup described here:

http://jsplumbtoolkit.com/doc/zooming

i actually just realised there's a big typo in the code that shows you how to set the transform via css, but if you go here:

http://jsplumbtoolkit.com/flowchart/jquery.html

and put this into the console:

var setZoom = function(z, el) {
    var p = [ "-webkit-", "-moz-", "-ms-", "-o-", "" ],
         s = "scale(" + z + ")";

    for (var i = 0; i < p.length; i++)
        el.css(p[i] + "transform", s);

    jsPlumb.setZoom(z);    
};

then

jsPlumb.setZoom(0.75, $("#main"));

you should see it working. you can also drag new connections with it zoomed too.

[Wojciech Makowiecki]

Thank you very much Simon!

Actually, there are 2 ways to make zooming:

1. The one that you suggested works fine

$("#drawing").css("-webkit-transform","scale(0.75)");    // I'm only using Chrome

jsPlumb.setZoom(0.75);

Actually I forgot I already used it before, so I just paste link here for future reference:

https://groups.google.com/forum/?hl=en#!topic/jsplumb/1tpkvs29Vco

2. This one doesn't work well - arrows get misplaced etc.

$("#drawing").css("zoom",75%);

jsPlumb.setZoom(0.75);

-- 

Many thanks,

Wojciech

--
You received this message because you are subscribed to the Google Groups "jsPlumb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsplumb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Simon Porritt]

Glad you got it working!

I don't think this is something you're concerned with, but for anyone else who's watching this topic or comes across it, I am messing around with a way to support zoom in IE8 too, using the Matrix filter. I will update the docs and the group threads when I have it sorted.

[Wojciech Makowiecki]

Actually, there is one more important thing that I need to ask you Simon.

There is a known issue with "jumping" draggable jQuery UI, 

that happens as I starting moving the entire zoomed-in diagram.

I solved it by applying the patch as described in here: 

http://stackoverflow.com/questions/3523747/webkit-and-jquery-draggable-jumping 

(the answer with patch_draggable.js with 6 likes) 

However, when I do use this patch, then I have jsPlumb related problem 

- with creating connections (arrows appear off source and target).

This happens only when the diagram is zoomed, by using -webkit-transform and jsPlumb.setZoom()

The solution to this would be awesome!

-- 

Best,

Wojciech

On Wed, Aug 28, 2013 at 10:42 PM, Simon Porritt <simon....@gmail.com> wrote:

Glad you got it working!

I don't think this is something you're concerned with, but for anyone else who's watching this topic or comes across it, I am messing around with a way to support zoom in IE8 too, using the Matrix filter. I will update the docs and the group threads when I have it sorted.

--

[Simon Porritt]

What do you mean when you say "I started moving the entire zoomed-in diagram" ?  With the code I pasted I don't see any jumping on drag of the sort that people are talking about there.

[Wojciech Makowiecki]

Simon, I'm using the code you pasted and there are 2 bug cases:

A. In my case I have a parent div containing other divs which can be connected together.

Moving nested divs and connecting them together works just fine!

but when I start moving the parent div, then I got a jump !

but it's much easier to explain it on your example B.)

B. In your case http://jsplumbtoolkit.com/flowchart/jquery.html

when you use the code you pasted 3 posts ago on this topic (I copy it below), you also get into trouble!!!

After pasting the code below into the console, try moving any of the windows, and the window will first make a "jump" into the correct spot (aligned with arrows), but if you start dragging it later it will make a jump every time you start moving it! It jumps into the right and down direction.

It's the same bug as I notice in my case A, but with a twist ;)

you have the problem with moving nodes,

and I have the problem with moving the parent div containing the nodes.

This bug difference is may be caused by different position:absolute, position: relative that we might use,

but the bug is there, it just manifests itself differently.

Just in case it may help - I'm using the newest Chrome (29.0.1547.62 m, on Win7 64bit.)

var setZoom = function(z, el) {
    var p = [ "-webkit-", "-moz-", "-ms-", "-o-", "" ],
         s = "scale(" + z + ")";

    for (var i = 0; i < p.length; i++)
        el.css(p[i] + "transform", s);

    jsPlumb.setZoom(z);    
};

then

jsPlumb.setZoom(0.75, $("#main"));

On Thu, Aug 29, 2013 at 3:40 AM, Simon Porritt <simon....@gmail.com> wrote:

What do you mean when you say "I started moving the entire zoomed-in diagram" ?  With the code I pasted I don't see any jumping on drag of the sort that people are talking about there.

--

[Simon Porritt]

actually that code i pasted is wrong - the second bit should be just

setZoom(0.75, $("#main"));

without jsPlumb. in front of it.

btw you shouldn't use relative positioning with draggable elements. jQuery UI writes left and top styles on the elements. when an element is positioned relative these values are interpreted to be offsets from the element‘s “normal” position, which is calculated by the page flow. they are not relative to the 0,0 point of the node’s first relatively positioned ancestor.

[Wojciech Makowiecki]

Ah!!! :) of course!

Thank you and sorry for that!

this way your example works fine :)

but mine still does not, 

even though all my elements have position: absolute

Actually in your example (http://jsplumbtoolkit.com/flowchart/jquery.html) 

the <div id="main"> has position: relative.

Anyway, as this is a problem beyond jsPlumb,

I won't bother you with that.

I'll just mention that right now I suspect it might have to do with few nested divs,

overflow: hidden, etc.

Best,

Wojciech

--

[Simon Porritt]

yes, #main has position relative, that's correct. An absolutely positioned div is positioned with respect to the 0,0 point of the first of its ancestors that is explicitly positioned relative. All of the window divs are positioned absolute and are children of #main, and #main is setup as the jsPlumb container, so everything is a child of that div and it all hangs together.

[Wojciech Makowiecki]

Ok, finally got it to work ! :) 

Thank you for help Simon!

For future reference:

I set position:relative on the <div> that contains nodes

(the parent of nodes).

On Thu, Aug 29, 2013 at 3:22 PM, Simon Porritt <simon....@gmail.com> wrote:

yes, #main has position relative, that's correct. An absolutely positioned div is positioned with respect to the 0,0 point of the first of its ancestors that is explicitly positioned relative. All of the window divs are positioned absolute and are children of #main, and #main is setup as the jsPlumb container, so everything is a child of that div and it all hangs together.

--

[Simon Porritt]

yes, you set relative on the parent. that's it. i think perhaps i need to make the documentation a little more clear!

[Wojciech Makowiecki]

I think you do a fantastic job with this forum so it serves as docs :)

BTW, your response times are amazing! :)

On Thu, Aug 29, 2013 at 3:36 PM, Simon Porritt <simon....@gmail.com> wrote:

yes, you set relative on the parent. that's it. i think perhaps i need to make the documentation a little more clear!

--

[Simon Porritt]

just to prove your point i am replying immediately, ha.

jsPlumb has kind of morphed into a full time pursuit for me, one way or another...this forum is as useful for me as it is for users: i get good feedback on where the docs are unclear, or where the API is a little wonky etc. and i respond as quickly as i do because otherwise my mailbox gets full and things get lost...

anyway i'm glad zoom is working for you now too.  i will be doing another release soon so i will improve the docs when i do so, and make sure everyone knows to set the parent relative....

[Wojciech Makowiecki]

:) I'm really happy, as I started to think this was not possible until you get rid of jQuery UI :)

Actually I'm now surprised it works even though so many people reported these jQuery UI bugs.

BTW, you might want to have a look at my app (which will now include zooming as well as panning).

I'll send you a link soon, when I make another public release.

Many thanks again!

--

[Wojciech Makowiecki]

I'm getting spoiled on this one and have one more question :)

I plugged the mousewheel to make the zoom and it works great!

but ... I will need to change the -webkit-transform-origin property

to mouse position or something like that, so the zoom zooms the area which lies under mouse

(normal zoom, that everyone is used to).

Should I do something with jsPlumb as well, or it may just work ?

[Wojciech Makowiecki]

It works just fine! :)

[erans...@gmail.com]

 

Hi Simon,

I hope i'm in the right place for asking question about jsPlumb...

I'm using jsPlumb (no dependency version -   with  'katavorio' library )   >  jquery.jsPlumb-1.4.1-all.js

I defined a containment and scroll + 100% height ( it reproduced also if the height is fix). when the page is rendered (before dragging) I can scroll down in my div(it also defined as the containment) and every thing is fine. the problem start when i first start drag one of the elements the scroll  turn to much shorter and the dragged elements are "jumping in side the containment that seems to be suddenly shorter" and all the elements stuck inside the containment that should be much hegira then it is and I can't be scrolled down.

This scenario is  not reproduced when using jsPlumb with jqueryUI (but there are other problems that prevent me from using it)

My UI in general is :

Wrapper div with position relative which also defined as the containment with scroll:auto in the CSS .

Children divs position absolute to the wrap div.

My question is if you are familiar with this kind of behavior and if you have any suggestions?

Because right now i decided to remove the containment...but it is not a solution for the long run :)

Thanks

Eran

 

בתאריך יום ראשון, 21 ביולי 2013 14:29:59 UTC+3, מאת simon....@gmail.com:dl

[Simon Porritt]

The "no dependency" version of jsPlumb is 1.6.0 +...what do you mean when you say you are using 1.4.1?

[Eran Sigal]

sorry, My mistake!

I'm using 1.6.2 

On Thu, Jul 3, 2014 at 10:13 AM, Simon Porritt <si...@jsplumbtoolkit.com> wrote:

The "no dependency" version of jsPlumb is 1.6.0 +...what do you mean when you say you are using 1.4.1?

--

You received this message because you are subscribed to the Google Groups "jsPlumb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsplumb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.