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 On Tuesday, June 6, 2017 at 9:36:04 AM UTC+2, is_null wrote: > > 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 > -- 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/076f436b-1c02-49c7-b174-d400b3b1ec9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
