Some questions on sortable: connectWith, dropOnEmpty

[Richard D. Worth]

Two quick questions that came to me as I was looking at the sortable API:

1. why is connectWith an array instead of a jQuery selector?

2. what's the use case for dropOnEmpty: false?

Thanks.

- Richard

[Scott González]

On Tue, Jan 20, 2009 at 10:29 AM, Richard D. Worth <rdw...@gmail.com> wrote:

1. why is connectWith an array instead of a jQuery selector?

 This is something we need to address for 1.7.  There are a lot of options across many plugins that support odd things for selecting elements.  We need to make all of them accept the following:
- jQuery selector
- DOMElement
- array of DOMElement's
- jQuery object
- function that returns a jQuery object

The logic for this should live in ui.core.js.

[Scott González]

I didn't realize that the array was an array of selectors, this seems very wrong.  Why not just specify one selector string with the individual selectors comma delimited?  I'd say this is a bug in the design and should be fixed for 1.6.

[Paul Bakaus]

Scott's right - I'll open a ticket.

However, concerning the acceptance: Accepting DOM elements or jQuery wrapped DOM elements is one of the most common reason for questions on the mailing lists, since those queries can't auto update themselves in a context. So everytime a context exists, that shouldn't be possible.

--
Paul Bakaus
UI Architect
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

[Scott González]

On Tue, Jan 20, 2009 at 11:32 AM, Paul Bakaus <paul....@googlemail.com> wrote:

However, concerning the acceptance: Accepting DOM elements or jQuery wrapped DOM elements is one of the most common reason for questions on the mailing lists, since those queries can't auto update themselves in a context. So everytime a context exists, that shouldn't be possible.

 I don't think we should disallow the use of DOM/jQuery objects in these contexts, just that we should recommend against it.  I view this to be the exact same problem as using .bind() in combination with ajax; it's entirely possible to do right, but much easier to just use .live().

For those that don't know what context Paul is talking about, think about specifying which items in a list are sortable.  Specifying a specific list of elements works fine if you can't add to the list.  As soon as you make it possible to add to the list, you need to manually update the set of items.

[Scott González]

On Tue, Jan 20, 2009 at 10:46 AM, Scott González <scott.g...@gmail.com> wrote:

I didn't realize that the array was an array of selectors, this seems very wrong.  Why not just specify one selector string with the individual selectors comma delimited?  I'd say this is a bug in the design and should be fixed for 1.6.

To be clear, I do not think we should maintain backward compatibility for an array of selectors as it is not jQuery-like.

[Paul Bakaus]

While I agree it's not very jQuery like, I'd like to keep it in for 1.6 because it's a major compatibility break (again), and I know many people use that syntax (because I pointed them to, duh..). We can mark it as deprecated and not even document it anymore though, and kill it for 1.7.

[Jörn Zaefferer]

On the other hand, we are breaking a lot of compability already
anyway. Deprecating it probably just defers the issue; if we change it
now and provide good information about how to migrate, we get it
solved now. And we need a migration guide anyway.

Jörn

[Paul Bakaus]

Who's for migrating, who against? Let's make the decision right away.

[Richard D. Worth]

+1 remove array syntax completely in 1.6

- Richard

[Richard D. Worth]

On Tue, Jan 20, 2009 at 10:29 AM, Richard D. Worth <rdw...@gmail.com> wrote:

2. what's the use case for dropOnEmpty: false?

bump.

- Richard

[Paul Bakaus]

I'm not sure but people requested it a couple times :)
 

- Richard

[Wichert Akkerman]

-1

You can't remove a feature in a release candidate. Perhaps deprecate it, but I would prefer to even postpone that until 1.7 and then remove in 1.8.

Wichert.

[Richard D. Worth]

On Wed, Jan 21, 2009 at 6:19 AM, Paul Bakaus <paul....@googlemail.com> wrote:

On Wed, Jan 21, 2009 at 12:18 PM, Richard D. Worth <rdw...@gmail.com> wrote:

On Tue, Jan 20, 2009 at 10:29 AM, Richard D. Worth <rdw...@gmail.com> wrote:

2. what's the use case for dropOnEmpty: false?

bump.

I'm not sure but people requested it a couple times :)

Are you sure? I wondered if maybe before this option existed, drop on empty was not possible. So people requested that that be a feature. But does it have to be an option? That is, is there a real need to selectively make it so that when you pick up a sortable element, you can drop it on a non-empty list, but not on an empty list.

And notice that when other items are added to that non-empty list, those dropOnEmpty: false items can then be dropped on that list. In my view, if they're connected, they're connected. If you don't want items dropped between one list and another, don't connect them.

The way it is currently, it seems to mean "I'm in a list of that can't be the first item added to an empty list. But I can be added to that same list once other items have been added" That's the use case I'm try to envision, and it's not coming to me. Am I missing something?

- Richard

[Richard D. Worth]

We're not removing a feature, we're fixing a bug. You'll be able to accomplish the same, with a fix in syntax. As Joern mentioned, there a large breaking API changes between 1.5 and 1.6. One of the points of 1.6rc5 (and rc4) is to ensure we have completed the making consistent of APIs between all these components. This is a case where it's not yet consistent. If we do make the change in 1.6, do you think it would warrant an additional rc?

- Richard

[Wichert Akkerman]

Changing the API at the end of a release candidate series is just as bad. In this case I would suggest:

• add the syntax change to a document which lists all changes people have to make when upgrading from 1.5 to 1.6
• still implement, but no longer document the old syntax
• if possible (I don't know if there is a framework for this) make use of the old syntax trigger a deprecation warning in the log
• remove from trunk directly after releasing 1.6 final

That way you do not break code that is already using 1.6 release candidates while introducing a clear path forwards.

Wichert.

[Richard D. Worth]

On Wed, Jan 21, 2009 at 8:01 AM, Wichert Akkerman <wic...@wiggy.net> wrote:

Changing the API at the end of a release candidate series is just as bad. In this case I would suggest:

• add the syntax change to a document which lists all changes people have to make when upgrading from 1.5 to 1.6
• still implement, but no longer document the old syntax

+1

• if possible (I don't know if there is a framework for this) make use of the old syntax trigger a deprecation warning in the log

we don't really have anything like this

• remove from trunk directly after releasing 1.6 final

+1
 

Thanks Wichert.

- Richard

[Paul Bakaus]

Thanks everyone, let's keep it in then and remove it directly after 1.6.

[Richard D. Worth]

Reopened ticket to update docs

http://ui.jquery.com/bugs/ticket/3892

Are any further code changes needed?

- Richard

[Paul Bakaus]

On Wed, Jan 21, 2009 at 2:33 PM, Richard D. Worth <rdw...@gmail.com> wrote:

Reopened ticket to update docs

http://ui.jquery.com/bugs/ticket/3892

Are any further code changes needed?

No, the code is good.
 

[Scott González]

On Wed, Jan 21, 2009 at 8:03 AM, Richard D. Worth <rdw...@gmail.com> wrote:

• remove from trunk directly after releasing 1.6 final

+1

 

I created a ticket for this (set to 1.next) and linked to it from the original ticket.

[Scott González]

On Wed, Jan 21, 2009 at 7:44 AM, Richard D. Worth <rdw...@gmail.com> wrote:

Are you sure? I wondered if maybe before this option existed, drop on empty was not possible. So people requested that that be a feature. But does it have to be an option? That is, is there a real need to selectively make it so that when you pick up a sortable element, you can drop it on a non-empty list, but not on an empty list.

And notice that when other items are added to that non-empty list, those dropOnEmpty: false items can then be dropped on that list. In my view, if they're connected, they're connected. If you don't want items dropped between one list and another, don't connect them.

The way it is currently, it seems to mean "I'm in a list of that can't be the first item added to an empty list. But I can be added to that same list once other items have been added" That's the use case I'm try to envision, and it's not coming to me. Am I missing something?

I agree, this is an odd feature to continue supporting.  Let's start a discussion after 1.6 settles down about whether this should be removed in 1.7.

[Eduardo Lundgren]

+1

--
Eduardo Lundgren
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.