Element endpoints, grouping and z order.

Will Comeaux

unread,

Dec 23, 2019, 12:08:30 PM12/23/19

to jsPlumb

Hello all:

I am dynamically adding elements to a canvas via drag/drop and then using drag/drop to nest elements inside of groups.

What I find is that endpoints do not stay with the element. Seems like my endpoints are staying behind in the parent div even though the element I am dropping on the group is having it's dom added to the group.

An example for clarity.

If I start with a canvas that has a rectangle with endpoints on the top and bottom, and a single group container.

<div>

</div>

After I drag the rectangle onto the group, I see the dom change to this:

<div>

</div>

Is there something I need to override to make sure the endpoints (and anything else that belongs to an element) are properly migrated in the DOM?

The problem this is causing (right now) is that ordering doesn't work. The rectangle inside the group should always appear on top of the group (along with its endpoints), but what I'm experiencing is that the endpoints are left underneath the group.

Thanks,

Will

Simon Porritt

unread,

Dec 23, 2019, 12:49:00 PM12/23/19

to jsPlumb

This is by design. You need to use z index to bring the endpoints up.

I dont think making the endpoints children of the group, as the node elements are, has ever been considered. While it would certainly help with the case that endpoints in some group can "bleed" through onto another group positioned on top of the group to which they logically belong, there still would be the problem that connections between endpoints belonging to two different groups could bleed through (there is no way to avoid that). So its generally recommended to ensure that groups do not overlap. In the Toolkit edition you can do that with the surface's magnetizer. In the Community edition you need to roll something of your own.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsplumb/52d1b931-8982-407d-81d5-b2d0a99bbfa7%40googlegroups.com.

Will Comeaux

unread,

Dec 23, 2019, 1:34:00 PM12/23/19

to jsPlumb

Ok, given that, how does one go about identifying which endpoints belong to each element?

To unsubscribe from this group and stop receiving emails from it, send an email to jsp...@googlegroups.com.

Simon Porritt

unread,

Dec 23, 2019, 1:38:51 PM12/23/19

to jsPlumb

Not sure what you mean. Why do you need to?

Will Comeaux

unread,

Dec 23, 2019, 1:40:48 PM12/23/19

to jsPlumb

if I implement a "bring to front" for an element, I'm also going to have to manually bring the endpoints associated with it to the front as well, right?

Looks like there is a jsPlumb.getEndpoints(id) function exposed. Looking at it now to see if I can use that.

Or is there a better way to go about this?

Simon Porritt

unread,

Dec 23, 2019, 1:46:41 PM12/23/19

to jsPlumb

That approach sounds like it would work. You can use addClass/removeClass on each of the Endpoints returned from getEndpoints.

Will Comeaux

unread,

Dec 23, 2019, 1:57:07 PM12/23/19

to jsPlumb

Yes. Trying to figure out a mechanism such that it brings them just far enough forward. Such that groups overlap each other but elements inside the group in the back of the stack do not show on top of elements in a higher group.

The way I'm handling the bring to front is just some jquery to make the element the first child of the parent. This has the desired outcome except for the dangling endpoints.

Reply all

Reply to author

Forward