Re: Vendoring Select2

[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 HoppeFon: +49 1511 4455 910www.johanneshoppe.comLennéstr. 1914469 PotsdamUSt-IdNr.: DE284754038
  

On Jun 14 2017, at 10:54 pm, Tim Graham  wrote:


  To learn about some history of noConflict, I'd use this Google search: jquery noConflict site:code.djangoproject.comThe first two results are some tickets with discussion:https://code.djangoproject.com/ticket/12882 - jQuery.noConflict() in admin breaks site specific code with jQueryhttps://code.djangoproject.com/ticket/16776 - jQuery.noConflict(false) in jquery.init.js leaks the admin jQuery into the global namespaceSearching 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-JohannesOn 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, vis

Re: Follow-up to #28307: Possible app_template improvements

[Adam Johnson]

I agree with Aymeric and Curtis too. You could distribute your startapp
template as a third party package, even overriding the built startapp
manage command to use your template by default.

On 15 June 2017 at 07:16, Curtis Maloney  wrote:

>
>
> On 15/06/17 16:14, Aymeric Augustin wrote:
>
>> Hello,
>>
>> The more files get generated to startapp, the more empty useless files
>> accrue in many projets, because devs don't take the time to delete those
>> they don't use.
>>
>
> Beat me to the punch... I agree the default template should be as light as
> possible.
>
> Encouraging people to improve the structure of their Django code is
>> worthwhile but I don't believe the startapp template is the right medium
>> for that.
>>
>
> There's no reason we can't provide an "advanced" template in core, surely?
>
> IMHO project/app templates are one of the least utilised features of
> Django, sadly.
>
> It deserves more marketing :)
>
> --
> Curtis
>
> --
> 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/ms
> gid/django-developers/9167ee89-f406-196b-28ec-5ba63ea1b049%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM0_e-xhDRRog4RM7TSj%2Bce3ib_5m6PigEJQmQxD5tZSuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Andrew Godwin]

Ah, I see, you are assuming sticky sockets. That makes things a lot easier
to architecture, but a whole lot harder to load-balance (you have to get
your load-balancer to deliberately close sockets when a server is
overloaded as many will not go away by themselves).

Still, it makes scaling down a lot easier, so it's nicer to program against
in that sense. Goes against the way most Python web code is written though
(imagine if you had to use sticky sessions for HTTP clients so they always
hit the same server!). I wonder if there is a way of doing something like
this well, so that it's easy to write but also lets you scale later.

Andrew

On Wed, Jun 14, 2017 at 9:53 PM, Tom Christie 
wrote:

> > I note that your examples do not include "receiving messages from a
> WebSocket and sending replies" - I would love to see how you propose to
> tackle this given your current API, and I think it's the missing piece of
> what I understand.
>
> I've just added an `echo` WebSocket example.
>
> I've also now added support for broadcast, currently implemented using
> Redis Pub/Sub.
> There's a full example for a chat server that can be properly distributed.
> (*)
>
> Aside: Right now that *happens* to be implemented as middleware, but
> there's no reason it couldn't equally well be integrated at the server
> level, so not a detail to get sidetracked by. More important is how the
> application interface for it looks.
>
> (*) Yes, you'd have sticky WebSockets.
>
> --
> 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/2da48b17-b47f-42e3-b1bb-
> 4a0e5a9b5709%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/CAFwN1upPew20giEHu%3D3NCtUD9e2WqHvcvNBsaVQg1nySm%3D232Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.