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. On Tuesday, June 6, 2017 at 5:54:16 AM UTC-4, Johannes Hoppe wrote: > > 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/f92d7c25-8084-48ca-b671-7df30d19ef36%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
