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 On Wednesday, April 6, 2016 at 9:25:08 AM UTC-4, Johannes Hoppe wrote: > > 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 > -- 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+unsubscr...@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/c2c6fd19-da23-4f11-9465-6816681d3aa2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
