Vendoring Select2

[Johannes Hoppe]

Hi,

as promised I started working on an autocomplete field for `django.contrib.admin` as a more convenient alternative to `row_id_fields`.

We had a longer discussion in the ticket and also at the sprints at DjangoConEU with some of the maintainers for famous 3rd party autocomplete integrations.

We concluded that select2 is the most mature and stable solution, that also doesn't require us to write our own JS code. (I know how much we hate it ;)

Notable:

1. In order to use `jQuery.noConflict(true);` I hat to add a wrapper around the vendored Select2 library. I think that is better than leaving `jQuery` in the global namespace.

2. `$.select2` will only be added to `django.jQuery` and therefore not interfere with other implementations. One should still be able to use 3rd party libraries.

3. Select2 is unter MIT license.

All in all I tried not to break anything and have this as new opt in solution. Lets see how it plays out.

All I need for you is to decided on wether or not with should vendor Select2.

PR is here: https://github.com/django/django/pull/6385

Thanks in advance!

Joe

[Collin Anderson]

Hi All,

I'm in favor of this change. This has the potential to replace the raw_id_fields and filter_horizontal which I think would be a huge win. Those widgets are out-dated not only in terms of code, but also from a UI point of view.

I'll try to give my answers to some questions before they come up.

- Aren't we having a discussion about adding hard-dependencies instead of vendoring code? Yes, and I think it's something we could consider down the road for this case, if our experiments with other libraries work out. This is little different though different because it's front-end code. For one thing, if we do a dependency on a 3rd party library, you'd have to add that library to INSTALLED_APPS for it to pick up the static files. Even then, it will only work if you use collectstatic (which I personally do not). Also, because this is front-end javascript, in theory there shouldn't be security holes in the code (we're not supposed to trust browser code in any case). Again, I think it's something we could consider down the road.

- Why select2? I haven't heard any serious proposals of a different library to use.

- Why not write the UI ourselves? Feel free. I spent a few hours at the Django Under the Hood sprints trying to write my own and it's a lot of work. You need to ajax-in the data, position the box in the right spot, handle keyboard events, etc. That's more javascript code we need to maintain (which, yes, we don't like doing :), and there's already a polished library we can use.

- Why not make it a generic form widget? I think this would be a lot more work. It would require adding a url endpoint and likely more configuration. If it's admin-only (for now), we can re-use the permission system and search_fields and keep it simple and seemless. I think making it generic is something we could consider down the road.

Thanks!

Collin

[Aymeric Augustin]

I’m OK with this. It's a reasonable solution.

-- 

Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/21cbed67-1ecb-4e04-a8d6-746cb363beab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marc Tamlyn]

Agreed. I recently was trying to use a fitler horizontal widget on my phone and thought the whole thing was broken because `<select multiple=mutliple>` looks so wrong. I'd love to see this experience improved, and select2 is a good reliable solution.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org.

[Andrew Ingram]

In previous projects (before moving to rolling my own UI components), I ended up favouring Selectize (http://selectize.github.io/selectize.js/) after getting fed up with Chosen and Select2 - but this was a few years ago and I can't remember my reasons. But if it hasn't been considered, it might be worth a look.

Andy

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.com.

[Johannes Hoppe]

I understand that. Select2 used to be horrible before the version 4 release.

Selectize was on the table, but dropped because it doesn't allow configuration via `data`-attriburtes. We wanted to keep the JS party as minial as possible.

Select2 does a good job since version 4, you can configure everything via data attributes.

[Sven R. Kunze]

Hi, I hope I am not too late to the discussion (and I hope it's the right one). :)

Am Mittwoch, 6. April 2016 15:42:58 UTC+2 schrieb Collin Anderson:

- Why select2? I haven't heard any serious proposals of a different library to use.

Internally, we had the same debate of upgrading our widgets for ForeignKey/ManyToMany, so I would like to share the current result with you.

Unfortunately, we ended up with two different widgets:

1) django-selectable

2) select2

We found that select2 only makes sense for a very very small number of selected items but allows on-the-fly creation of items even for many-to-many relations. Thus, we use if for email address fields and tags: foreign keys but text input suffices for creation.

On the other hand, if you need to distribute 800 users among 70 groups, where even half the users can be in a single group, then select2 is not the right widget. That's where selectable comes in. The presentation of the selection as a list appears to be less confusing.

Just wanted to share this with you even if you might already have decided to use select2.

Sven

[Johannes Hoppe]

Hi Sven,

you are right. For this particular case select2 would be an ill advice. But I didn't initially add support for m2m fields. I just added it later to my pull-requested, since it was only one line of code. And some people would have found a usecase for It.

At the end this will be an optional feature and I wouldn't enable it for users and groups ether. But than I don't have too.

Thanks for the feedback!

Joe

[Sven R. Kunze]

Hi Johannes,

Am Sonntag, 24. April 2016 10:16:53 UTC+2 schrieb Johannes Hoppe:

Hi Sven,

you are right. For this particular case select2 would be an ill advice. But I didn't initially add support for m2m fields. I just added it later to my pull-requested, since it was only one line of code. And some people would have found a usecase for It.

I look forward to it.

 

At the end this will be an optional feature and I wouldn't enable it for users and groups ether. But than I don't have too.

Interesting. I didn't know one could choose a particular widget for foreign keys/m2m in the admin interface. Admittedly, I don't work on it regularly.

 

Thanks for the feedback!

You are welcome. :)

Sven 

[is_null]

Hi all,

In our experience, it would be worth removing noConflict, but we need Django to have a recent jQuery release, it's wasn't always the case but now it's good. I don't know who relies on that except grappeli, but they would probably be happy to get rid of their double jquery loading because that's been the source of many user issues, at least in DAL's repo.

Another library that would be worth proposing is jquery-autocomplete-light (disclamer: I'm the author), particularely because it is built to let the server render the suggestions box, and because it's pretty light by essence (does nothing on selection but trigger an event, it's up to the developer to implement the callback). But I should do some crowdfunding or something to cover it with JS unit tests, currently it's abandoned except by most django-autocomplete-light < 3.0 users, some v3 users are using it already even thought it's not been officially released / supported, because I was maintaining it with selenium tests and that was too much of a pain of course to have no unit tests.

If you need generic form widgets, I think we've got ok ones in django-autocomplete-light v3. Again what's missing for developer experience is just the ability to override the default form, without having to subclass the world just to pass it: when you need an autocomplete on a field, you most likely need it everywhere, ie. because the select would load too many options to be usable.

We'd be very happy to see noConflict removed, and try to all rely on the latest jQuery, rather than all try to load our own and deal with different variables names for jQuery. Perhaps I should try this in a fork, even if that means DAL will require extra steps for users not on that specific Django fork, at least we'd figure out if removing noConflict had unseen drawbacks.

Best

[Johannes Hoppe]

Hi!

I didn't get your name, but this address the latest post.

I think we made some good progress in the regarding this issue. The inclusion of select2 is at a stage where I wouldn't want to jump to a different library. Especially considering that now one acted at this ticket for seven years and it took me 2 years to work on the issue and it still isn't merged.

That being said, the major question remaining is whether or not to disable `noConflict(true)`. I don't mind, I made it work without it. But maintenance wise, it's simpler to just disable it.

I would love to see some feedback from the core team here. I really like to get this resolved.

Cheers

-Johannes

[Jamesie Pic]

Thanks for asking, my name is ∞, but you've known my as James Pic /
YourLabs. Nice to speak with you again <3

I think it would make sense for a core dev to advocate against this
change, because we'd be breaking BC before having enough information
to know if this is going to have a generally more positive than
negative impact, I wouldn't be able to tell without trying it myself
with a community for a couple of years, and have the opportunity to
try it out with a bunch of app/widget combinations, because the Django
ecosystem (at least, the part I rely on and love) is so huge :D

Best
<3

[Florian Apolloner]

On Tuesday, June 6, 2017 at 11:54:16 AM UTC+2, Johannes Hoppe wrote:

I think we made some good progress in the regarding this issue. The inclusion of select2 is at a stage where I wouldn't want to jump to a different library. Especially considering that now one acted at this ticket for seven years and it took me 2 years to work on the issue and it still isn't merged.

Absolutely, changing select2 to something different is a nogo.

[Jamesie Pic]

I was just thinking that changing the js widget would not require to
rewrite the python code, barely the js widget support. I'm not trying
to push it, just make sure we are taking the right facts into
consideration, but I'm happy with select2 myself.

[Tim Graham]

To learn about some history of noConflict, I'd use this Google search: jquery noConflict site:code.djangoproject.com

The first two results are some tickets with discussion:
https://code.djangoproject.com/ticket/12882 - jQuery.noConflict() in admin breaks site specific code with jQuery
https://code.djangoproject.com/ticket/16776 - jQuery.noConflict(false) in jquery.init.js leaks the admin jQuery into the global namespace

Searching this mailing list for noConflict:
https://groups.google.com/d/topic/django-developers/yR2jY-8zVik/discussion - Using jQuery.noConflict() instead of jQuery.noConflict(true) in contrib.admin (2010)
https://groups.google.com/d/topic/django-developers/BENOHGuwsOQ/discussion - jQuery.noConflict() vs. jQuery.noConflict(true) (2011)

Maybe reading those tickets/discussions gives you some insight. I don't have much expertise to offer.

I'd think it'd be feasible to upgrade the admin's copy of jQuery to the latest release in each Django major version, but I'm not sure if doing that and dropping noConflict woudl be a hindrance to third-party apps that want to support multiple Django versions.

[Johannes Hoppe]

Hello again!

After some consideration, I am against dropping noConflict and will not rely on it in my pull request. I also found a work around. For that workaround to work I will need to fix a bug in django.forms first. I will do that in a separate PR.

I hope I can get all this done before the 2.0 feature deadline... *fingers crossed*

Cheers

-Joe

--
Johannes Hoppe

Fon: +49 1511 4455 910
www.johanneshoppe.com

Lennéstr. 19
14469 Potsdam

USt-IdNr.: DE284754038

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/tCNWnLP8jzM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f92d7c25-8084-48ca-b671-7df30d19ef36%40googlegroups.com.

[Jamesie Pic]

Awesome, hope this will help drag in maintainer activity on select2 <3

Best

[Johannes Hoppe]

Hi there,

I worked on a fix for form media today. No it will keep the order and we can include our own scripts before calling noConflict.

This way we don't have to wrapp all vendored JS libraries.

Furthermore it makes the order of your assets more reliable than before and throws a warning if there are conflicts.

https://github.com/django/django/pull/8667

Enjoy :)

-Joe

--
Johannes Hoppe

Fon: +49 1511 4455 910
www.johanneshoppe.com

Lennéstr. 19
14469 Potsdam

USt-IdNr.: DE284754038

On Jun 18 2017, at 10:48 pm, Jamesie Pic <jp...@yourlabs.org> wrote:

Awesome, hope this will help drag in maintainer activity on select2 <3

Best

-- 
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/tCNWnLP8jzM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op1_P-cvdqT_XeTGPrsuRSXN%3DRS3aF_MokofVVS_eF12_JA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jamesie Pic]

Note that jquery-autocomplete could be a backup solution in case select2 looses maintainer traction in the future.

​

https://www.devbridge.com/sourcery/components/jquery-autocomplete/

Best

<3

[Mithlesh Kumar]

Hi,

I'm very new to Open Source. I like to contribute to `Django`. How can I do so ?

Thanks 

Mithlesh K

[Dylan Reinhold]

Mithlesh,
The django project web sites has a page about how to contribute : https://code.djangoproject.com/#Gettinginvolved

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/748d95d9-4964-4bed-ac01-d4e8d2512dcc%40googlegroups.com.

[Mithlesh Kumar]

Thanks a lot, Dylan !.

Mithlesh K

On Sunday, December 17, 2017 at 8:41:06 AM UTC+5:30, Dylan Reinhold wrote:

Mithlesh,
The django project web sites has a page about how to contribute : https://code.djangoproject.com/#Gettinginvolved

On Sat, Dec 16, 2017 at 5:35 PM, Mithlesh Kumar <mithlesh....@gmail.com> wrote:

Hi,

I'm very new to Open Source. I like to contribute to `Django`. How can I do so ?

Thanks 

Mithlesh K

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.