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
On Jun 14 2017, at 10:54 pm, Tim Graham <timogra...@gmail.com> wrote:
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 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-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.
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/local-bc38e9f5-e85c%40nylas-mail.nylas.com.
For more options, visit https://groups.google.com/d/optout.
