Re: Vendoring Select2

[Mithlesh Kumar]

Thanks a lot, Dylan !.

Mithlesh K

On Sunday, December 17, 2017 at 8:41:06 AM UTC+5:30, Dylan Reinhold wrote:
>
> Mithlesh,
> The django project web sites has a page about how to contribute : 
> https://code.djangoproject.com/#Gettinginvolved
>
>
> On Sat, Dec 16, 2017 at 5:35 PM, Mithlesh Kumar  > wrote:
>
>> Hi,
>>
>> I'm very new to Open Source. I like to contribute to `Django`. How can I 
>> do so ?
>>
>> Thanks 
>> Mithlesh K
>>
>>
>>
>>
>>
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/748d95d9-4964-4bed-ac01-d4e8d2512dcc%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/24644f50-d5bd-4a41-93b7-0d7f183bc9c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Dylan Reinhold]

Mithlesh,
The django project web sites has a page about how to contribute :
https://code.djangoproject.com/#Gettinginvolved


On Sat, Dec 16, 2017 at 5:35 PM, Mithlesh Kumar <
mithlesh.kumar.4...@gmail.com> wrote:

> Hi,
>
> I'm very new to Open Source. I like to contribute to `Django`. How can I
> do so ?
>
> Thanks
> Mithlesh K
>
>
>
>
>
>
> --
> 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/748d95d9-4964-4bed-ac01-
> d4e8d2512dcc%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/CAHtg44D-%2Bu3GBnpjX9uUj7C0D-U77FKYu%3D7nichWoOhX7j2uKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Mithlesh Kumar]

Hi,

I'm very new to Open Source. I like to contribute to `Django`. How can I do 
so ?

Thanks 
Mithlesh K






-- 
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/748d95d9-4964-4bed-ac01-d4e8d2512dcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Jamesie Pic]

Note that jquery-autocomplete could be a backup solution in case select2
looses maintainer traction in the future.
​
https://www.devbridge.com/sourcery/components/jquery-autocomplete/

Best
<3

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

Re: Vendoring Select2

[Johannes Hoppe]

Hi there,I worked on a fix for form media today. No it will keep the order and we can include our own scripts before calling noConflict.This way we don't have to wrapp all vendored JS libraries.Furthermore it makes the order of your assets more reliable than before and throws a warning if there are conflicts.https://github.com/django/django/pull/8667Enjoy :)-Joe--Johannes HoppeFon: +49 1511 4455 910www.johanneshoppe.comLennéstr. 1914469 PotsdamUSt-IdNr.: DE284754038
  

On Jun 18 2017, at 10:48 pm, Jamesie Pic  wrote:


  Awesome, hope this will help drag in maintainer activity on select2 <3

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/CAC6Op1_P-cvdqT_XeTGPrsuRSXN%3DRS3aF_MokofVVS_eF12_JA%40mail.gmail.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-cfaf00d3-7c9b%40nylas-mail.nylas.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Jamesie Pic]

Awesome, hope this will help drag in maintainer activity on select2 <3

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/CAC6Op1_P-cvdqT_XeTGPrsuRSXN%3DRS3aF_MokofVVS_eF12_JA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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 

Re: Vendoring Select2

[Tim Graham]

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.

Re: Vendoring Select2

[Jamesie Pic]

I was just thinking that changing the js widget would not require to
rewrite the python code, barely the js widget support. I'm not trying
to push it, just make sure we are taking the right facts into
consideration, but I'm happy with select2 myself.

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

Re: Vendoring Select2

[Florian Apolloner]

On Tuesday, June 6, 2017 at 11:54:16 AM UTC+2, Johannes Hoppe wrote:
>
> 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.
>

Absolutely, changing select2 to something different is a nogo. 

-- 
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/b99de1b4-82e3-42f3-9bbd-6f2fb2594f1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Jamesie Pic]

Thanks for asking, my name is ∞, but you've known my as James Pic /
YourLabs. Nice to speak with you again <3

I think it would make sense for a core dev to advocate against this
change, because we'd be breaking BC before having enough information
to know if this is going to have a generally more positive than
negative impact, I wouldn't be able to tell without trying it myself
with a community for a couple of years, and have the opportunity to
try it out with a bunch of app/widget combinations, because the Django
ecosystem (at least, the part I rely on and love) is so huge :D

Best
<3

-- 
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/CAC6Op1_AjF8xMnbi7ym8Ceu45oDeiR8woaN-0K_4PZmzYT0CrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Johannes Hoppe]

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.

Re: Vendoring Select2

[is_null]

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/43f81fe5-6999-4400-90a7-68585ca51c49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Sven R. Kunze]

Hi Johannes,

Am Sonntag, 24. April 2016 10:16:53 UTC+2 schrieb Johannes Hoppe:
>
> Hi Sven,
>
> you are right. For this particular case select2 would be an ill advice. 
> But I didn't initially add support for m2m fields. I just added it later to 
> my pull-requested, since it was only one line of code. And some people 
> would have found a usecase for It.
>

I look forward to it.
 

> At the end this will be an optional feature and I wouldn't enable it for 
> users and groups ether. But than I don't have too.
>

Interesting. I didn't know one could choose a particular widget for foreign 
keys/m2m in the admin interface. Admittedly, I don't work on it regularly.
 

> Thanks for the feedback!
>

You are welcome. :)

Sven 

-- 
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/bc197574-9819-4211-ba6d-711776362f7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Johannes Hoppe]

Hi Sven,

you are right. For this particular case select2 would be an ill advice. But 
I didn't initially add support for m2m fields. I just added it later to my 
pull-requested, since it was only one line of code. And some people would 
have found a usecase for It.

At the end this will be an optional feature and I wouldn't enable it for 
users and groups ether. But than I don't have too.

Thanks for the feedback!

Joe

On Saturday, April 23, 2016 at 11:32:22 PM UTC+2, Sven R. Kunze wrote:
>
> Hi, I hope I am not too late to the discussion (and I hope it's the right 
> one). :)
>
> Am Mittwoch, 6. April 2016 15:42:58 UTC+2 schrieb Collin Anderson:
> - Why select2? I haven't heard any serious proposals of a different 
> library to use.
>
> Internally, we had the same debate of upgrading our widgets for 
> ForeignKey/ManyToMany, so I would like to share the current result with you.
>
> Unfortunately, we ended up with two different widgets:
>
> 1) django-selectable
> 2) select2
>
>
> We found that select2 only makes sense for a *very very small number* of 
> selected items but allows on-the-fly creation of items even for 
> many-to-many relations. Thus, we use if for email address fields and tags: 
> foreign keys but text input suffices for creation.
>
>
> On the other hand, if you need to distribute 800 users among 70 groups, 
> where even half the users can be in a single group, then select2 is not the 
> right widget. That's where selectable comes in. The presentation of the 
> selection *as a list* appears to be less confusing.
>
> Just wanted to share this with you even if you might already have decided 
> to use select2.
>
> Sven
>

-- 
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/ac69257d-e01a-46fa-b24c-cd7810dda636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Sven R. Kunze]

Hi, I hope I am not too late to the discussion (and I hope it's the right 
one). :)

Am Mittwoch, 6. April 2016 15:42:58 UTC+2 schrieb Collin Anderson:
- Why select2? I haven't heard any serious proposals of a different library 
to use.

Internally, we had the same debate of upgrading our widgets for 
ForeignKey/ManyToMany, so I would like to share the current result with you.

Unfortunately, we ended up with two different widgets:

1) django-selectable
2) select2


We found that select2 only makes sense for a *very very small number* of 
selected items but allows on-the-fly creation of items even for 
many-to-many relations. Thus, we use if for email address fields and tags: 
foreign keys but text input suffices for creation.


On the other hand, if you need to distribute 800 users among 70 groups, 
where even half the users can be in a single group, then select2 is not the 
right widget. That's where selectable comes in. The presentation of the 
selection *as a list* appears to be less confusing.

Just wanted to share this with you even if you might already have decided 
to use select2.

Sven

-- 
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/6dc267db-390e-4587-a3fe-c391303655c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Johannes Hoppe]

I understand that. Select2 used to be horrible before the version 4 release.
Selectize was on the table, but dropped because it doesn't allow 
configuration via `data`-attriburtes. We wanted to keep the JS party as 
minial as possible.
Select2 does a good job since version 4, you can configure everything via 
data attributes.

On Wednesday, April 6, 2016 at 4:25:23 PM UTC+2, Andrew Ingram wrote:
>
> In previous projects (before moving to rolling my own UI components), I 
> ended up favouring Selectize (http://selectize.github.io/selectize.js/) 
> after getting fed up with Chosen and Select2 - but this was a few years ago 
> and I can't remember my reasons. But if it hasn't been considered, it might 
> be worth a look.
>
> Andy
>
> On 6 April 2016 at 15:20, Marc Tamlyn  
> wrote:
>
>> Agreed. I recently was trying to use a fitler horizontal widget on my 
>> phone and thought the whole thing was broken because `> multiple=mutliple>` looks so wrong. I'd love to see this experience 
>> improved, and select2 is a good reliable solution.
>>
>> On 6 April 2016 at 15:11, Aymeric Augustin > > wrote:
>>
>>> I’m OK with this. It's a reasonable solution.
>>>
>>> -- 
>>> Aymeric.
>>>
>>> On 06 Apr 2016, at 15:25, 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-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@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/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org
>>>  
>>> 
>>> .
>>>
>>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, 

Re: Vendoring Select2

[Andrew Ingram]

In previous projects (before moving to rolling my own UI components), I
ended up favouring Selectize (http://selectize.github.io/selectize.js/)
after getting fed up with Chosen and Select2 - but this was a few years ago
and I can't remember my reasons. But if it hasn't been considered, it might
be worth a look.

Andy

On 6 April 2016 at 15:20, Marc Tamlyn  wrote:

> Agreed. I recently was trying to use a fitler horizontal widget on my
> phone and thought the whole thing was broken because ` multiple=mutliple>` looks so wrong. I'd love to see this experience
> improved, and select2 is a good reliable solution.
>
> On 6 April 2016 at 15:11, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> I’m OK with this. It's a reasonable solution.
>>
>> --
>> Aymeric.
>>
>> On 06 Apr 2016, at 15:25, 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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org
>> 
>> .
>>
>> 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/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.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 

Re: Vendoring Select2

[Marc Tamlyn]

Agreed. I recently was trying to use a fitler horizontal widget on my phone
and thought the whole thing was broken because ``
looks so wrong. I'd love to see this experience improved, and select2 is a
good reliable solution.

On 6 April 2016 at 15:11, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> I’m OK with this. It's a reasonable solution.
>
> --
> Aymeric.
>
> On 06 Apr 2016, at 15:25, 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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org
> 
> .
>
> 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/CAMwjO1EkkH9SGG-Pss2JQTj0%3DJ8dRYnF3_Stt1hbqZrYqGYh0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Aymeric Augustin]

I’m OK with this. It's a reasonable solution.

-- 
Aymeric.

> On 06 Apr 2016, at 15:25, 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/21cbed67-1ecb-4e04-a8d6-746cb363beab%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/C7278AB9-9018-4BC0-A7A8-CACFA361A5A3%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Vendoring Select2

[Collin Anderson]

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.