date:20190118

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-18 Thread Carlton Gibson

> On 18 Jan 2019, at 17:20, Santiago Basulto  wrote:
> 
> Seems like everybody agrees that for large sites, it's necessary.

Hang on, slow down. 

Personally, I’m not sure it’s too onerous as-is. I’ve not yet seen exactly why 
subclassing ModelAdmin in one’s project isn’t good enough. It really depends on 
with the “it” is “it’s necessary” is taken to mean…

- Better examples in docs: Great, no problem. 
- **More** API on ModelAdmin: OK, maybe, but what does that look like exactly? 
- A setting: Really? Do we have to? Can we explore other options first?

Both the docs and adjustments to ModelAdmin options could be pushed forward 
with a PR. “Better handling of FK widgets for fields with large counts” — 
sounds great, but what does that involve?

Kind Regards,

Carlton

-- 
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/9A970D0F-B329-4D54-B89F-40536F0A03F1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

2019-01-18 Thread Jani Tiainen

Hi,

You said that this doesn't require any change in Django at all.

So this doesn't need to be in Django at all, it can survive as its own and
that way it should be.

So make your enhancement as reusable app and release it to public. Get
people to use it. Fix the bugs that appears. Write a good documentation.
Give the support.



On Sat, Jan 19, 2019 at 12:18 AM J. Pablo Martín Cobos 
wrote:

> I reply beetween lines,
>
> El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
> escribió:
>
>> Hi,
>>
>> Lets try this again.
>>
>> Your system could be nice if it really helps rendering speed.
>>
>
> Yes we get several miliseconds per request.
>
>
>>
>> But does it require changes in Django core itself, or is it completely
>> standalone package that doesn't require changing Django itself to operate?
>> If it requires changes in Django itself, it would be useful to describe
>> what changes are needed and why.
>>
>>
> You don't need any change in Django. This command generates a new
> template. I paste another time my first example:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}{% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preprocess every template of a settings variable and I
> get something like this:
>
> news.unify.html (or if you want the command can overwrite news.html)
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> 
> 
>
> It is only a preprocess to get time for each request.
>
> Note that you can even no build custom rendering engines since Django
>> supports those now (with default implementations for Django Templating
>> Language and Jinja2) your system actually might fall in this category.
>>
>>
> No, It is not a new render engine. It would be a pre render engine. It is
> a new feature.
>
>
>> Even code is bad you really need to start get some momentum for your
>> system. Otherwise it's really hard to provide any feedback for example
>> there might be some edgecases you might not have thought of.
>>
>
> I want to know if this is a nice feature for Django community, then I will
> create a ticket... and if nobody resolve it I will propose a change, but I
> know ifor experience it is very hard collaborate with code in Django, and
> more difficult with a new feature.
>
> To understand it, the best is to use the command with a simple template
> such as admin/index.html.
>
> Best,
>
>
>>
>> On Fri, Jan 18, 2019 at 7:23 PM J. Pablo Martín Cobos 
>> wrote:
>>
>>> Sorry, I reply beetween lines
>>>
>>> El vie., 18 ene. 2019 16:32, J. Pablo Martín Cobos 
>>> escribió:
>>>
 Hi another time,

 I am tring to reply every people in this email:

 Josh

 I was not using django.template.loaders.cached.Loader, but the result
 are very similar i.e:

 App Template Num templates rendered before unify Num templates
 rendered after unify AVG Time render template before unify (ms) AVG
 Time render template after unify (ms)
 Django admin admin/index.html 3 1 80 70
 Django constance admin/constance/change_list.html 7 1 330 180
 Django su su/login.html 5 3 10 5

 Pavlos:

1. Yes, I wrote this email to contribute another time. Actually I
am already Django contributor[1][2]
2. I didn't share my code, because it is not a nice code. *For me
it is a teoric question. I don't want anybody have a bad opinion of this
proposal for the implementation*. But I am sharing [3] it without
problems, but please I know this solution is incomplete for many reason.
3. About your question: "I am not sure I understood anything so
far. Are you just pre-rendering {% include %} tags, so the template 
 engine
doesn't have to do that in runtime?" Yes :-)
4. About it: "I think what you did is addressed more neatly with
the django.template.loaders.cached.Loader, as Josh Smeaton mentioned." 
 and
"Experimenting like this, even if you end up rediscovering something 
 that
exists" It is

Re: Add support for filter arguments in queryset.exists() and queryset.count()

2019-01-18 Thread Maciek Olko

Dear Sjoerd, dear all,

My thoughts:
* on one hand it feels natural to simplify calls and keep things simple,
from this perspective +1;
* on the other I can imagine new Django user that gets confused by
inconsistency in code snippets or StackOverflow: you can now filter not
only using filter() or get() methods, from this perspective -1;
* get() already supports field lookups, so count() and exists() would join
it to stand in one row, from this perspective +1;
* if introducing such change, for sure documentation should be very
carefully reviewed and updated to mirror the new preferred way of doing
count and exists queries;
* it would be quite a big change, I think it should be introduced with
preferably MAJOR or at least MINOR version of Django;
* maybe an e-mail encouraging community to update e.g. StackOverflow with
new Django syntaxt sections after the release to avoid confusion for
newcomers would be a good idea?;
* what about first() and delete()? (rest of queryset methods with no
arguments, that doesn't return a queryset); should they also support field
lookups?
* what about reverse() and all()? (rest of queryset methods with no
arguments that return a queryset); should they also support field lookups?

Kind regards,
Maciej Olko

pt., 18 sty 2019 o 22:12 użytkownik Sjoerd Job Postmus 
napisał:

> Dear all,
>
>
> This is probably a feature that has been proposed before, but I could
> not find a discussion on it, so I proposed it on the tracker, and Tim
> also couldn't find a discussion.
>
> (ticket: https://code.djangoproject.com/ticket/30118 )
>
> I would like to propose being able to write
> `SomeModel.objects.exists(field=value)` over
> `SomeModel.objects.filter(field=value).exists()` (and similar for
> `.count(**kwargs)`.
>
>
> As Tim rightfully commented: "There should be one-- and preferably only
> one --obvious way to do it.".
>
>
> I'm proposing this is a case where the obvious way would eventually be
> more in line with my suggestion instead of what we currently use.
>
>
> Consider the following code example (from
>
> https://github.com/django/django/blob/709a8b861de14204f0e13c9a0fbfd61c11b3565d/tests/auth_tests/test_management.py#L998
> ):
>
>
>  Permission.objects.filter(
>  content_type__model=opts.model_name,
>  content_type__app_label=opts.app_label,
>  codename=codename,
>  ).exists()
>
> There is a weird (to me, your mileage might vary) ").exists()" as a
> final line, and I would like to write this as
>
>  Permission.objects.exists(
>  content_type__model=opts.model_name,
>  content_type__app_label=opts.app_label,
>  codename=codename,
>  )
>
> This pattern seems to be quite rare in the Django codebase itself, but
> in the codebase at work we have several cases of `queryset.filter( of lines>).exists()` (and similar with count), and I am expecting this
> to also be prevalent in other codebases out there.
>
>
> Arguing against it however are the following lines of the Zen of Python:
>
> - "Explicit is better than implicit."
>
> - Maybe also "Special cases aren't special enough to break the rules.",
> because `.filter().count()` and `.exclude().count()` are both the same
> pattern, but this would only create an alternative for the first.
>
> - "There should be one-- and preferably only one --obvious way to do it."
>
>
> Beyond these short quips, I was hoping there might also be an earlier
> discussion covering this.
>
>
> Kind regards,
>
> Sjoerd Job Postmus
>
> --
> 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/63f21e13-4c6e-89f2-aca3-6961e98832df%40sjec.nl
> .
> 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/CALYYG83gUsf7uc-w8_hUVKYxd_i%3DPshguRB4VLrA-c4g2k9R6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

2019-01-18 Thread J . Pablo Martín Cobos

I reply beetween lines,

El vie., 18 ene. 2019 a las 21:25, Jani Tiainen ()
escribió:

> Hi,
>
> Lets try this again.
>
> Your system could be nice if it really helps rendering speed.
>

Yes we get several miliseconds per request.


>
> But does it require changes in Django core itself, or is it completely
> standalone package that doesn't require changing Django itself to operate?
> If it requires changes in Django itself, it would be useful to describe
> what changes are needed and why.
>
>
You don't need any change in Django. This command generates a new template.
I paste another time my first example:

1. news.html

{% extends "base.html" %}

{% block title %}
{% include "inc.news.title.html" %}
{% endblock %}

{% block content %}
{% for news_item in news %}
{{ news_item.title }}
{{ news_item.subtitle }}
{% endfor %}
{% endblock %}

2. base.html

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="{{
LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
%}>

{% block title %}{% endblock %}


{% block content %}{% endblock %}



3. inc.news.title.html
News

With this command I preprocess every template of a settings variable and I
get something like this:

news.unify.html (or if you want the command can overwrite news.html)

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="{{
LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
%}>

News


{% for news_item in news %}
{{ news_item.title }}
{{ news_item.subtitle }}
{% endfor %}



It is only a preprocess to get time for each request.

Note that you can even no build custom rendering engines since Django
> supports those now (with default implementations for Django Templating
> Language and Jinja2) your system actually might fall in this category.
>
>
No, It is not a new render engine. It would be a pre render engine. It is a
new feature.


> Even code is bad you really need to start get some momentum for your
> system. Otherwise it's really hard to provide any feedback for example
> there might be some edgecases you might not have thought of.
>

I want to know if this is a nice feature for Django community, then I will
create a ticket... and if nobody resolve it I will propose a change, but I
know ifor experience it is very hard collaborate with code in Django, and
more difficult with a new feature.

To understand it, the best is to use the command with a simple template
such as admin/index.html.

Best,


>
> On Fri, Jan 18, 2019 at 7:23 PM J. Pablo Martín Cobos 
> wrote:
>
>> Sorry, I reply beetween lines
>>
>> El vie., 18 ene. 2019 16:32, J. Pablo Martín Cobos 
>> escribió:
>>
>>> Hi another time,
>>>
>>> I am tring to reply every people in this email:
>>>
>>> Josh
>>>
>>> I was not using django.template.loaders.cached.Loader, but the result
>>> are very similar i.e:
>>>
>>> App Template Num templates rendered before unify Num templates rendered
>>> after unify AVG Time render template before unify (ms) AVG Time render
>>> template after unify (ms)
>>> Django admin admin/index.html 3 1 80 70
>>> Django constance admin/constance/change_list.html 7 1 330 180
>>> Django su su/login.html 5 3 10 5
>>>
>>> Pavlos:
>>>
>>>1. Yes, I wrote this email to contribute another time. Actually I am
>>>already Django contributor[1][2]
>>>2. I didn't share my code, because it is not a nice code. *For me it
>>>is a teoric question. I don't want anybody have a bad opinion of this
>>>proposal for the implementation*. But I am sharing [3] it without
>>>problems, but please I know this solution is incomplete for many reason.
>>>3. About your question: "I am not sure I understood anything so far.
>>>Are you just pre-rendering {% include %} tags, so the template engine
>>>doesn't have to do that in runtime?" Yes :-)
>>>4. About it: "I think what you did is addressed more neatly with the
>>>django.template.loaders.cached.Loader, as Josh Smeaton mentioned." and
>>>"Experimenting like this, even if you end up rediscovering something that
>>>exists" It is something different than django cache loader, of course I
>>>know django cache loader, I fixed a problem with django cached loader [4]
>>>five years ago :-). With django cache loader, we get django get a 
>>> template
>>>quickly. But If your view finally render 3 templates, django cached 
>>> loader
>>>will have to get 3 templates (from cache). With my proposal your view
>>>render only 1 template (This is not 100% true, 1 + templates about
>>>templatetags except extends and include)
>>>
>>> Jani:
>>>
>>> Currently you only need move the new template result to the old path of
>>> the template.

Add support for filter arguments in queryset.exists() and queryset.count()

2019-01-18 Thread Sjoerd Job Postmus


Dear all,


This is probably a feature that has been proposed before, but I could 
not find a discussion on it, so I proposed it on the tracker, and Tim 
also couldn't find a discussion.


(ticket: https://code.djangoproject.com/ticket/30118 )

I would like to propose being able to write 
`SomeModel.objects.exists(field=value)` over 
`SomeModel.objects.filter(field=value).exists()` (and similar for 
`.count(**kwargs)`.



As Tim rightfully commented: "There should be one-- and preferably only 
one --obvious way to do it.".



I'm proposing this is a case where the obvious way would eventually be 
more in line with my suggestion instead of what we currently use.



Consider the following code example (from 
https://github.com/django/django/blob/709a8b861de14204f0e13c9a0fbfd61c11b3565d/tests/auth_tests/test_management.py#L998):



    Permission.objects.filter(
    content_type__model=opts.model_name,
    content_type__app_label=opts.app_label,
    codename=codename,
    ).exists()

There is a weird (to me, your mileage might vary) ").exists()" as a 
final line, and I would like to write this as


    Permission.objects.exists(
    content_type__model=opts.model_name,
    content_type__app_label=opts.app_label,
    codename=codename,
    )

This pattern seems to be quite rare in the Django codebase itself, but 
in the codebase at work we have several cases of `queryset.filter(of lines>).exists()` (and similar with count), and I am expecting this 
to also be prevalent in other codebases out there.



Arguing against it however are the following lines of the Zen of Python:

- "Explicit is better than implicit."

- Maybe also "Special cases aren't special enough to break the rules.", 
because `.filter().count()` and `.exclude().count()` are both the same 
pattern, but this would only create an alternative for the first.


- "There should be one-- and preferably only one --obvious way to do it."


Beyond these short quips, I was hoping there might also be an earlier 
discussion covering this.



Kind regards,

Sjoerd Job Postmus

--
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/63f21e13-4c6e-89f2-aca3-6961e98832df%40sjec.nl.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

2019-01-18 Thread Jani Tiainen

Hi,

Lets try this again.

Your system could be nice if it really helps rendering speed.

But does it require changes in Django core itself, or is it completely
standalone package that doesn't require changing Django itself to operate?
If it requires changes in Django itself, it would be useful to describe
what changes are needed and why.

Note that you can even no build custom rendering engines since Django
supports those now (with default implementations for Django Templating
Language and Jinja2) your system actually might fall in this category.

Even code is bad you really need to start get some momentum for your
system. Otherwise it's really hard to provide any feedback for example
there might be some edgecases you might not have thought of.


On Fri, Jan 18, 2019 at 7:23 PM J. Pablo Martín Cobos 
wrote:

> Sorry, I reply beetween lines
>
> El vie., 18 ene. 2019 16:32, J. Pablo Martín Cobos 
> escribió:
>
>> Hi another time,
>>
>> I am tring to reply every people in this email:
>>
>> Josh
>>
>> I was not using django.template.loaders.cached.Loader, but the result are
>> very similar i.e:
>>
>> App Template Num templates rendered before unify Num templates rendered
>> after unify AVG Time render template before unify (ms) AVG Time render
>> template after unify (ms)
>> Django admin admin/index.html 3 1 80 70
>> Django constance admin/constance/change_list.html 7 1 330 180
>> Django su su/login.html 5 3 10 5
>>
>> Pavlos:
>>
>>1. Yes, I wrote this email to contribute another time. Actually I am
>>already Django contributor[1][2]
>>2. I didn't share my code, because it is not a nice code. *For me it
>>is a teoric question. I don't want anybody have a bad opinion of this
>>proposal for the implementation*. But I am sharing [3] it without
>>problems, but please I know this solution is incomplete for many reason.
>>3. About your question: "I am not sure I understood anything so far.
>>Are you just pre-rendering {% include %} tags, so the template engine
>>doesn't have to do that in runtime?" Yes :-)
>>4. About it: "I think what you did is addressed more neatly with the
>>django.template.loaders.cached.Loader, as Josh Smeaton mentioned." and
>>"Experimenting like this, even if you end up rediscovering something that
>>exists" It is something different than django cache loader, of course I
>>know django cache loader, I fixed a problem with django cached loader [4]
>>five years ago :-). With django cache loader, we get django get a template
>>quickly. But If your view finally render 3 templates, django cached loader
>>will have to get 3 templates (from cache). With my proposal your view
>>render only 1 template (This is not 100% true, 1 + templates about
>>templatetags except extends and include)
>>
>> Jani:
>>
>> Currently you only need move the new template result to the old path of
>> the template. But it is only because I want. If you change this line [5]
>> for this other you don't need any change:
>>
>> destination_name = template.origin.name
>>
>>
>> 8 years ago I requested a feature related with templates
>>
>
> [6]
>
>
> , now I have a new request :-) 8 years ago I tried resolved my proposal,
>> now I only want propose something :-D
>>
>> I think in this change for Django :-)
>>
>>
>> REF's
>>
>> 1.
>> https://github.com/django/django/pulls?q=is%3Apr+author%3Agoinnn+is%3Aclosed
>> 2.
>> https://code.djangoproject.com/query?status=assigned=closed=new=~pmartin=id=summary=status=owner=type=component=version=1=id
>> 3. https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6
>> (tested in Django 1.8 - 1.11)
>> 4.
>> https://github.com/django/django/pull/1936/commits/e669bca5c8fe6d13ea745d338203cd9e7470ae6b
>> 5.
>> https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6#file-unify_templates-py-L58
>> 6. https://code.djangoproject.com/ticket/15053
>>
>>
>> Best,
>>
>>
>> El vie., 18 ene. 2019 a las 14:11, Jani Tiainen ()
>> escribió:
>>
>>> Hi.
>>>
>>> Does this require changes to django internals or can it work as an
>>> external package?
>>>
>>> Also you should release it as a package so people can start using it,
>>> also preferably releasing it with BSD license like Django itself is.
>>> Otherwise there are very little chances that your solution would make to
>>> django it self.
>>>
>>> Improvements to rendering are always welcome, but they must come without
>>> too much maintenance burden.
>>>
>>> On Thu, Jan 17, 2019 at 11:02 AM J. Pablo Martín Cobos 
>>> wrote:
>>>
 Hi,

 From one year ago, I am using an own command for Django templates that
 unify them. With an example it is easy to see. If I am to render for
 example a template call news.html like it:

 1. news.html

 {% extends "base.html" %}

 {% block title %}
 {% include "inc.news.title.html" %}
 {% endblock %}

 {% block content %}
 {% for news_item in news

Re: bulk_update: add exclude arg

2019-01-18 Thread Tom Forbes

Hey Mohammad,
Thanks for your suggestion. I considered this while implementing bulk
update but I decided against it.

In my opinion you should be very explicit about the fields you wish to
update, due to the way that bulk update works it can generate very large
and expensive queries if a lot of columns are updated, so it's better to be
upfront about what you want to update rather than potentially having s
situation where adding a large text field suddenly causes performance
issues (or even database errors) anywhere you use bulk update with that
model.

Tom

On Fri, 18 Jan 2019, 19:49 Mohammad Etemaddar  Dear Django developers,
> Thank you very much for great work and team-work on our beloved Django.
>
> I suddenly saw the new great feature *bulk_update *for models and so
> updated to the dev branch.
> As other similar situations like forms, we have exclude argument for *lazy
> programmers.*
>
> *Thank you,*
> *Mohammad Etemaddar*
>
> --
> 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/9cbf3c99-70b5-49d4-a141-d317652ff66a%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/CAFNZOJOfKK8rgKmcV%2BWDsOn3DLptNBzTJKU8pUfCLivKZ--krw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

bulk_update: add exclude arg

2019-01-18 Thread Mohammad Etemaddar

Dear Django developers,
Thank you very much for great work and team-work on our beloved Django.

I suddenly saw the new great feature *bulk_update *for models and so 
updated to the dev branch.
As other similar situations like forms, we have exclude argument for *lazy 
programmers.*

*Thank you,*
*Mohammad Etemaddar*

-- 
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/9cbf3c99-70b5-49d4-a141-d317652ff66a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-18 Thread Santiago Basulto

@Harro, it does work if the field is not part of the admin. It doesn't add 
the way to link it directly, but it does resolve the problem of prefetching 
a list and building the large select field. Here's an quick 
example: https://i.imgur.com/uNRPCK6.png (the Country field is a FK and 
doesn't have an admin class).

Seems like everybody agrees that for large sites, it's necessary. We've all 
been bitten by it. I could post to the Users email list to receive some 
feedback.

On Friday, January 18, 2019 at 7:25:43 AM UTC-5, Harro wrote:
>
> The problem is that you can't just use it everywhere, like mentioned 
> earlier it only works if the other side of the relation is also available 
> in the admin (which might not be the case, or only for some of the fields.)
>
> I would say add it to the good old djangosnippets 
>  website. 
>
> But that's just my 2 cents.
>
> On Friday, 18 January 2019 12:50:52 UTC+1, Josh Smeaton wrote:
>>
>> If we were happy with that particular implementation, then I'd prefer 
>> adding it as an official subclass thats importable for users rather than 
>> just dumping the code to the docs. But I guess the issue is a slippery 
>> slope - how many subclasses do we add for various ModelAdmin use cases. 
>> It's definitely an issue that bites many people, and I'd like to see some 
>> way forward.
>>
>> On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>>>
>>> Ok, sorry for the Fake News, seems like it's not so complicated to make 
>>> one ModelAdmin parent class that provides this behavior. Here's a working 
>>> example:
>>>
>>>
>>> from django.contrib import admin
>>>
>>> from django.contrib.admin import widgets
>>>
>>>
>>> class RawFieldModelAdmin(admin.ModelAdmin):
>>> def formfield_for_foreignkey(self, db_field, request, **kwargs):
>>> db = kwargs.get('using')
>>> if 'widget' not in kwargs:
>>> if db_field.name not in (self.get_autocomplete_fields(
>>> request), self.radio_fields):
>>> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(
>>> db_field.remote_field, self.admin_site, using=db)
>>>
>>>
>>> return super().formfield_for_foreignkey(db_field, request, **
>>> kwargs)
>>>
>>> Do you folks think we should add this to the docs? I still think that 
>>> having a one-off setting for the "default foreign key" widget would be 
>>> valuable, at least for me as a user.
>>>
>>> What do you think?
>>>
>>> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto 
>>> wrote:

 I think the proposed solution of "you can just extend/subclass 
 ModelAdmin" doesn't work, because the fields on different models can have 
 different names. I can't just write one global ModelAdmin and then use it 
 for all my models, because they'll have different names for their fields. 
 Or if it works, it'll need A LOT of introspection (to dynamically check 
 which fields are FKs and making them part of raw_id_fields).

 Maybe I'm wrong and I'm missing the point, do you folks have an 
 implementation of that ModelAdmin superclass to show?

 On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson 
 wrote:
>
>
>
> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>
>> One problem with any of the alternatives (besides making it readonly 
>> by default) is that it requires the other model to be registered in the 
>> admin
>>
>
> Off-hand I don't follow you here. Can you explain. 
>
>  
>
>> I hope there's _something_ we can do to somehow improve the 
>> situation. Maybe we could at least improve the examples in the 
>> documentation? Maybe give an example in the docs of a ModelAdmin 
>> subclass 
>> that defaults to using raw_id?
>>
>
> An example definitely.
>
> Maybe we could add an attribute to ModelAdmin with a number: More than 
> this use raw_id — but what would that look like? 
> (Easy subclass rather than a setting...)
>


-- 
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/63293e84-aa00-41e3-87ee-8272a5c17478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

2019-01-18 Thread J . Pablo Martín Cobos

Sorry, I reply beetween lines

El vie., 18 ene. 2019 16:32, J. Pablo Martín Cobos 
escribió:

> Hi another time,
>
> I am tring to reply every people in this email:
>
> Josh
>
> I was not using django.template.loaders.cached.Loader, but the result are
> very similar i.e:
>
> App Template Num templates rendered before unify Num templates rendered
> after unify AVG Time render template before unify (ms) AVG Time render
> template after unify (ms)
> Django admin admin/index.html 3 1 80 70
> Django constance admin/constance/change_list.html 7 1 330 180
> Django su su/login.html 5 3 10 5
>
> Pavlos:
>
>1. Yes, I wrote this email to contribute another time. Actually I am
>already Django contributor[1][2]
>2. I didn't share my code, because it is not a nice code. *For me it
>is a teoric question. I don't want anybody have a bad opinion of this
>proposal for the implementation*. But I am sharing [3] it without
>problems, but please I know this solution is incomplete for many reason.
>3. About your question: "I am not sure I understood anything so far.
>Are you just pre-rendering {% include %} tags, so the template engine
>doesn't have to do that in runtime?" Yes :-)
>4. About it: "I think what you did is addressed more neatly with the
>django.template.loaders.cached.Loader, as Josh Smeaton mentioned." and
>"Experimenting like this, even if you end up rediscovering something that
>exists" It is something different than django cache loader, of course I
>know django cache loader, I fixed a problem with django cached loader [4]
>five years ago :-). With django cache loader, we get django get a template
>quickly. But If your view finally render 3 templates, django cached loader
>will have to get 3 templates (from cache). With my proposal your view
>render only 1 template (This is not 100% true, 1 + templates about
>templatetags except extends and include)
>
> Jani:
>
> Currently you only need move the new template result to the old path of
> the template. But it is only because I want. If you change this line [5]
> for this other you don't need any change:
>
> destination_name = template.origin.name
>
>
> 8 years ago I requested a feature related with templates
>

[6]


, now I have a new request :-) 8 years ago I tried resolved my proposal,
> now I only want propose something :-D
>
> I think in this change for Django :-)
>
>
> REF's
>
> 1.
> https://github.com/django/django/pulls?q=is%3Apr+author%3Agoinnn+is%3Aclosed
> 2.
> https://code.djangoproject.com/query?status=assigned=closed=new=~pmartin=id=summary=status=owner=type=component=version=1=id
> 3. https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6
> (tested in Django 1.8 - 1.11)
> 4.
> https://github.com/django/django/pull/1936/commits/e669bca5c8fe6d13ea745d338203cd9e7470ae6b
> 5.
> https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6#file-unify_templates-py-L58
> 6. https://code.djangoproject.com/ticket/15053
>
>
> Best,
>
>
> El vie., 18 ene. 2019 a las 14:11, Jani Tiainen ()
> escribió:
>
>> Hi.
>>
>> Does this require changes to django internals or can it work as an
>> external package?
>>
>> Also you should release it as a package so people can start using it,
>> also preferably releasing it with BSD license like Django itself is.
>> Otherwise there are very little chances that your solution would make to
>> django it self.
>>
>> Improvements to rendering are always welcome, but they must come without
>> too much maintenance burden.
>>
>> On Thu, Jan 17, 2019 at 11:02 AM J. Pablo Martín Cobos 
>> wrote:
>>
>>> Hi,
>>>
>>> From one year ago, I am using an own command for Django templates that
>>> unify them. With an example it is easy to see. If I am to render for
>>> example a template call news.html like it:
>>>
>>> 1. news.html
>>>
>>> {% extends "base.html" %}
>>>
>>> {% block title %}
>>> {% include "inc.news.title.html" %}
>>> {% endblock %}
>>>
>>> {% block content %}
>>> {% for news_item in news %}
>>> {{ news_item.title }}
>>> {{ news_item.subtitle }}
>>> {% endfor %}
>>> {% endblock %}
>>>
>>> 2. base.html
>>>
>>> >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>>> http://www.w3.org/1999/xhtml; lang="{{
>>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>>> %}>
>>> 
>>> {% block title %}{% endblock %}
>>> 
>>> 
>>> {% block content %}{% endblock %}
>>> 
>>> 
>>>
>>> 3. inc.news.title.html
>>> News
>>>
>>> With this command I preproces every template of a settings variable and
>>> I get something like this:
>>>
>>> news.unify.html
>>>
>>> >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>>> http://www.w3.org/1999/xhtml; lang="{{
>>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>>> %}>
>>> 
>>> News
>>> 
>>>

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-18 Thread Collin Anderson

> > One problem with any of the alternatives (besides making it readonly by
default) is that it requires the other model to be registered in the admin
> Off-hand I don't follow you here. Can you explain.

I stand corrected. raw_id_fields doesn't actually require the other model
to be registered.

On Fri, Jan 18, 2019 at 7:25 AM Harro  wrote:

> The problem is that you can't just use it everywhere, like mentioned
> earlier it only works if the other side of the relation is also available
> in the admin (which might not be the case, or only for some of the fields.)
>
> I would say add it to the good old djangosnippets
>  website.
>
> But that's just my 2 cents.
>
> On Friday, 18 January 2019 12:50:52 UTC+1, Josh Smeaton wrote:
>>
>> If we were happy with that particular implementation, then I'd prefer
>> adding it as an official subclass thats importable for users rather than
>> just dumping the code to the docs. But I guess the issue is a slippery
>> slope - how many subclasses do we add for various ModelAdmin use cases.
>> It's definitely an issue that bites many people, and I'd like to see some
>> way forward.
>>
>> On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>>>
>>> Ok, sorry for the Fake News, seems like it's not so complicated to make
>>> one ModelAdmin parent class that provides this behavior. Here's a working
>>> example:
>>>
>>>
>>> from django.contrib import admin
>>>
>>> from django.contrib.admin import widgets
>>>
>>>
>>> class RawFieldModelAdmin(admin.ModelAdmin):
>>> def formfield_for_foreignkey(self, db_field, request, **kwargs):
>>> db = kwargs.get('using')
>>> if 'widget' not in kwargs:
>>> if db_field.name not in (self.get_autocomplete_fields(
>>> request), self.radio_fields):
>>> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(
>>> db_field.remote_field, self.admin_site, using=db)
>>>
>>>
>>> return super().formfield_for_foreignkey(db_field, request, **
>>> kwargs)
>>>
>>> Do you folks think we should add this to the docs? I still think that
>>> having a one-off setting for the "default foreign key" widget would be
>>> valuable, at least for me as a user.
>>>
>>> What do you think?
>>>
>>> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto
>>> wrote:

 I think the proposed solution of "you can just extend/subclass
 ModelAdmin" doesn't work, because the fields on different models can have
 different names. I can't just write one global ModelAdmin and then use it
 for all my models, because they'll have different names for their fields.
 Or if it works, it'll need A LOT of introspection (to dynamically check
 which fields are FKs and making them part of raw_id_fields).

 Maybe I'm wrong and I'm missing the point, do you folks have an
 implementation of that ModelAdmin superclass to show?

 On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson
 wrote:
>
>
>
> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>
>> One problem with any of the alternatives (besides making it readonly
>> by default) is that it requires the other model to be registered in the
>> admin
>>
>
> Off-hand I don't follow you here. Can you explain.
>
>
>
>> I hope there's _something_ we can do to somehow improve the
>> situation. Maybe we could at least improve the examples in the
>> documentation? Maybe give an example in the docs of a ModelAdmin subclass
>> that defaults to using raw_id?
>>
>
> An example definitely.
>
> Maybe we could add an attribute to ModelAdmin with a number: More than
> this use raw_id — but what would that look like?
> (Easy subclass rather than a setting...)
>
 --
> 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/f888916c-78b9-4a06-aa83-c880a114d034%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

Re: What do you think about unify templates feature?

2019-01-18 Thread J . Pablo Martín Cobos

Hi another time,

I am tring to reply every people in this email:

Josh

I was not using django.template.loaders.cached.Loader, but the result are
very similar i.e:

App Template Num templates rendered before unify Num templates rendered
after unify AVG Time render template before unify (ms) AVG Time render
template after unify (ms)
Django admin admin/index.html 3 1 80 70
Django constance admin/constance/change_list.html 7 1 330 180
Django su su/login.html 5 3 10 5

Pavlos:

   1. Yes, I wrote this email to contribute another time. Actually I am
   already Django contributor[1][2]
   2. I didn't share my code, because it is not a nice code. *For me it is
   a teoric question. I don't want anybody have a bad opinion of this proposal
   for the implementation*. But I am sharing [3] it without problems, but
   please I know this solution is incomplete for many reason.
   3. About your question: "I am not sure I understood anything so far. Are
   you just pre-rendering {% include %} tags, so the template engine doesn't
   have to do that in runtime?" Yes :-)
   4. About it: "I think what you did is addressed more neatly with the
   django.template.loaders.cached.Loader, as Josh Smeaton mentioned." and
   "Experimenting like this, even if you end up rediscovering something that
   exists" It is something different than django cache loader, of course I
   know django cache loader, I fixed a problem with django cached loader [4]
   five years ago :-). With django cache loader, we get django get a template
   quickly. But If your view finally render 3 templates, django cached loader
   will have to get 3 templates (from cache). With my proposal your view
   render only 1 template (This is not 100% true, 1 + templates about
   templatetags except extends and include)

Jani:

Currently you only need move the new template result to the old path of the
template. But it is only because I want. If you change this line [5] for
this other you don't need any change:

destination_name = template.origin.name

8 years ago I requested a feature related with templates, now I have a new
request :-) 8 years ago I tried resolved my proposal, now I only want
propose something :-D

I think in this change for Django :-)

REF's

1.
https://github.com/django/django/pulls?q=is%3Apr+author%3Agoinnn+is%3Aclosed
2.
https://code.djangoproject.com/query?status=assigned=closed=new=~pmartin=id=summary=status=owner=type=component=version=1=id
3. https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6 (tested
in Django 1.8 - 1.11)
4.
https://github.com/django/django/pull/1936/commits/e669bca5c8fe6d13ea745d338203cd9e7470ae6b
5.
https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6#file-unify_templates-py-L58
6. https://code.djangoproject.com/ticket/15053

Best,

El vie., 18 ene. 2019 a las 14:11, Jani Tiainen ()
escribió:

> Hi.
>
> Does this require changes to django internals or can it work as an
> external package?
>
> Also you should release it as a package so people can start using it, also
> preferably releasing it with BSD license like Django itself is. Otherwise
> there are very little chances that your solution would make to django it
> self.
>
> Improvements to rendering are always welcome, but they must come without
> too much maintenance burden.
>
> On Thu, Jan 17, 2019 at 11:02 AM J. Pablo Martín Cobos 
> wrote:
>
>> Hi,
>>
>> From one year ago, I am using an own command for Django templates that
>> unify them. With an example it is easy to see. If I am to render for
>> example a template call news.html like it:
>>
>> 1. news.html
>>
>> {% extends "base.html" %}
>>
>> {% block title %}
>> {% include "inc.news.title.html" %}
>> {% endblock %}
>>
>> {% block content %}
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> {% endblock %}
>>
>> 2. base.html
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> {% block title %}{% endblock %}
>> 
>> 
>> {% block content %}{% endblock %}
>> 
>> 
>>
>> 3. inc.news.title.html
>> News
>>
>> With this command I preproces every template of a settings variable and I
>> get something like this:
>>
>> news.unify.html
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> News
>> 
>> 
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> 
>> 
>>
>> So I have a two improves:
>>
>>1. It is more fast. And in a real project a view can render easyly 50
>>

Re: What do you think about unify templates feature?

2019-01-18 Thread Jani Tiainen

Hi.

Does this require changes to django internals or can it work as an external
package?

Also you should release it as a package so people can start using it, also
preferably releasing it with BSD license like Django itself is. Otherwise
there are very little chances that your solution would make to django it
self.

Improvements to rendering are always welcome, but they must come without
too much maintenance burden.

On Thu, Jan 17, 2019 at 11:02 AM J. Pablo Martín Cobos 
wrote:

> Hi,
>
> From one year ago, I am using an own command for Django templates that
> unify them. With an example it is easy to see. If I am to render for
> example a template call news.html like it:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}{% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preproces every template of a settings variable and I
> get something like this:
>
> news.unify.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> 
> 
>
> So I have a two improves:
>
>1. It is more fast. And in a real project a view can render easyly 50
>templates
>2. I use news.html to develop and news.unify.html to production. So I
>don't lose legilibility.
>
>
> What do you think about "unify templates feature"? Do you know if exists a
> similar public project in github/gitlab/bitbucket etc?
>
>
> Best,
>
> --
> Pablo Martín Cobos
> Computer engineer
> Python/Django developer
> 652 53 37 36
> goi...@gmail.com
>
> --
> 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/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Jani Tiainen

- Well planned is half done, and a half done has been sufficient before...

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

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-18 Thread Harro

The problem is that you can't just use it everywhere, like mentioned 
earlier it only works if the other side of the relation is also available 
in the admin (which might not be the case, or only for some of the fields.)

I would say add it to the good old djangosnippets 
 website. 

But that's just my 2 cents.

On Friday, 18 January 2019 12:50:52 UTC+1, Josh Smeaton wrote:
>
> If we were happy with that particular implementation, then I'd prefer 
> adding it as an official subclass thats importable for users rather than 
> just dumping the code to the docs. But I guess the issue is a slippery 
> slope - how many subclasses do we add for various ModelAdmin use cases. 
> It's definitely an issue that bites many people, and I'd like to see some 
> way forward.
>
> On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>>
>> Ok, sorry for the Fake News, seems like it's not so complicated to make 
>> one ModelAdmin parent class that provides this behavior. Here's a working 
>> example:
>>
>>
>> from django.contrib import admin
>>
>> from django.contrib.admin import widgets
>>
>>
>> class RawFieldModelAdmin(admin.ModelAdmin):
>> def formfield_for_foreignkey(self, db_field, request, **kwargs):
>> db = kwargs.get('using')
>> if 'widget' not in kwargs:
>> if db_field.name not in (self.get_autocomplete_fields(request
>> ), self.radio_fields):
>> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(db_field
>> .remote_field, self.admin_site, using=db)
>>
>>
>> return super().formfield_for_foreignkey(db_field, request, **
>> kwargs)
>>
>> Do you folks think we should add this to the docs? I still think that 
>> having a one-off setting for the "default foreign key" widget would be 
>> valuable, at least for me as a user.
>>
>> What do you think?
>>
>> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto 
>> wrote:
>>>
>>> I think the proposed solution of "you can just extend/subclass 
>>> ModelAdmin" doesn't work, because the fields on different models can have 
>>> different names. I can't just write one global ModelAdmin and then use it 
>>> for all my models, because they'll have different names for their fields. 
>>> Or if it works, it'll need A LOT of introspection (to dynamically check 
>>> which fields are FKs and making them part of raw_id_fields).
>>>
>>> Maybe I'm wrong and I'm missing the point, do you folks have an 
>>> implementation of that ModelAdmin superclass to show?
>>>
>>> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote:



 On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>
> One problem with any of the alternatives (besides making it readonly 
> by default) is that it requires the other model to be registered in the 
> admin
>

 Off-hand I don't follow you here. Can you explain. 

  

> I hope there's _something_ we can do to somehow improve the situation. 
> Maybe we could at least improve the examples in the documentation? Maybe 
> give an example in the docs of a ModelAdmin subclass that defaults to 
> using 
> raw_id?
>

 An example definitely.

 Maybe we could add an attribute to ModelAdmin with a number: More than 
 this use raw_id — but what would that look like? 
 (Easy subclass rather than a setting...)

>>>

-- 
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/f888916c-78b9-4a06-aa83-c880a114d034%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

2019-01-18 Thread Pavlos Georgiadis

Hi,

I guess the reason you wrote to this list about your unify command, is
because you don't mind contributing it to the django project.

So maybe you could show the code of this command, so people can
understand what improvements it can offer.

I am not sure I understood anything so far. Are you just pre-rendering
{% include %} tags, so the template engine doesn't have to do that in
runtime?


--

Pavlos Georgiadis


On 18/01/19 11:31, J. Pablo Martín Cobos wrote:
> I answer between lines
>
> El jue., 17 ene. 2019 a las 18:42, Maciek Olko ( >) escribió:
>
> Did you try to measure the difference in time of rendering
> standard and your way?
>
>
> Yes. I have several examples:
>
> App   TemplateNum templates rendered before unify Num templates
> rendered after unify  Time render template before unify (ms)  Time
> render template after unify (ms)  Improve
> Django admin  admin/index.html3   1   75 - 11071 - 79 
> 22%
> Django admin  admin/change_list.html  26  Command error   180-300
> Command error 
> Django admin  admin/change_form.html  16  Command error   350-400
> Command error 
> Django constance  admin/constance/change_list.html7   1   
> 350-400
> 150-250   75%
> Django su su/login.html   5   3   15- 20  10 - 12 54%
>
>
> My command currently does not work with several complex templates like
> admin/change_list.html or admin/change_form.html But we can improve
> it, currently it works with almost all.
>
> If there is a nice improve with views that render few templates...
> imagine with views with a lot of templates.
>
> I have measure these times with django-debug-toolbar-template-timings
>
> With this email only I want to know if you see it can be a important
> feature to add to Django framework... or it is a silly thing.
>
> Best,
>
>  
>
> Regards,
> Maciej
>
> czw., 17.01.2019, 10:02 użytkownik J. Pablo Martín Cobos
> mailto:goi...@gmail.com>> napisał:
>
> Hi,
>
> From one year ago, I am using an own command for Django
> templates that unify them. With an example it is easy to see.
> If I am to render for example a template call news.html like it:
>
> 1. news.html
>
>     {% extends "base.html" %}
>
>     {% block title %}
>         {% include "inc.news.title.html" %}
>     {% endblock %}
>
>     {% block content %}
>         {% for news_item in news %}
>             {{ news_item.title }}
>             {{ news_item.subtitle }}
>         {% endfor %}
>     {% endblock %}
>
> 2. base.html
>
>      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>     http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI
> %}dir="rtl"{% endif %}>
>         
>             {% block title %}{% endblock %}
>         
>         
>             {% block content %}{% endblock %}
>         
>     
>
> 3. inc.news.title.html
>     News
>
> With this command I preproces every template of a settings
> variable and I get something like this:
>
> news.unify.html
>
>      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>     http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI
> %}dir="rtl"{% endif %}>
>         
>             News
>         
>         
>             {% for news_item in news %}
>                 {{ news_item.title }}
>                 {{ news_item.subtitle }}
>             {% endfor %}
>         
>     
>
> So I have a two improves:
>
>  1. It is more fast. And in a real project a view can render
> easyly 50 templates
>  2. I use news.html to develop and news.unify.html to
> production. So I don't lose legilibility.
>
>
> What do you think about "unify templates feature"? Do you know
> if exists a similar public project in github/gitlab/bitbucket etc?
>
>
> Best,
>
> -- 
> Pablo Martín Cobos
> Computer engineer
> Python/Django developer
> 652 53 37 36 
> goi...@gmail.com 
> -- 
> 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
>

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-18 Thread Josh Smeaton

If we were happy with that particular implementation, then I'd prefer 
adding it as an official subclass thats importable for users rather than 
just dumping the code to the docs. But I guess the issue is a slippery 
slope - how many subclasses do we add for various ModelAdmin use cases. 
It's definitely an issue that bites many people, and I'd like to see some 
way forward.

On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>
> Ok, sorry for the Fake News, seems like it's not so complicated to make 
> one ModelAdmin parent class that provides this behavior. Here's a working 
> example:
>
>
> from django.contrib import admin
>
> from django.contrib.admin import widgets
>
>
> class RawFieldModelAdmin(admin.ModelAdmin):
> def formfield_for_foreignkey(self, db_field, request, **kwargs):
> db = kwargs.get('using')
> if 'widget' not in kwargs:
> if db_field.name not in (self.get_autocomplete_fields(request
> ), self.radio_fields):
> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(db_field.
> remote_field, self.admin_site, using=db)
>
>
> return super().formfield_for_foreignkey(db_field, request, **
> kwargs)
>
> Do you folks think we should add this to the docs? I still think that 
> having a one-off setting for the "default foreign key" widget would be 
> valuable, at least for me as a user.
>
> What do you think?
>
> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto wrote:
>>
>> I think the proposed solution of "you can just extend/subclass 
>> ModelAdmin" doesn't work, because the fields on different models can have 
>> different names. I can't just write one global ModelAdmin and then use it 
>> for all my models, because they'll have different names for their fields. 
>> Or if it works, it'll need A LOT of introspection (to dynamically check 
>> which fields are FKs and making them part of raw_id_fields).
>>
>> Maybe I'm wrong and I'm missing the point, do you folks have an 
>> implementation of that ModelAdmin superclass to show?
>>
>> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote:
>>>
>>>
>>>
>>> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:

 One problem with any of the alternatives (besides making it readonly by 
 default) is that it requires the other model to be registered in the admin

>>>
>>> Off-hand I don't follow you here. Can you explain. 
>>>
>>>  
>>>
 I hope there's _something_ we can do to somehow improve the situation. 
 Maybe we could at least improve the examples in the documentation? Maybe 
 give an example in the docs of a ModelAdmin subclass that defaults to 
 using 
 raw_id?

>>>
>>> An example definitely.
>>>
>>> Maybe we could add an attribute to ModelAdmin with a number: More than 
>>> this use raw_id — but what would that look like? 
>>> (Easy subclass rather than a setting...)
>>>
>>

-- 
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/ec47fd5a-5c34-47ad-805d-d2036d430aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

2019-01-18 Thread Josh Smeaton

Are you 
using 
https://docs.djangoproject.com/en/2.1/ref/templates/api/#django.template.loaders.cached.Loader
 
in your tests? And you should find a way to test rendering from the command 
line, which will allow you to get much better timing information.

On Friday, 18 January 2019 20:40:29 UTC+11, Goinnn wrote:
>
> I answer between lines
>
>
> El vie., 18 ene. 2019 a las 5:03, shiva kumar ( >) escribió:
>
>> Could you please explain about it. I hadn't understood ur idea.
>>
>
>
>1. Currently: with you render a view, this render a template. But 
>usually, this template extends of another and include others. So Django 
> has 
>to get these templates to create an HTML. This process get time.
>2. My proposal: Preprocess templates for some (or all) them. Creating 
>a template without extends or includes. So, in my previous email you can 
>see, Django render less templates, so Django win time.
>
> We can get a backend a  little faster with very little effort.
>
> Best!
>
>  
>
>> On Thu 17 Jan, 2019 2:32 pm J. Pablo Martín Cobos >  wrote:
>>
>>> Hi,
>>>
>>> From one year ago, I am using an own command for Django templates that 
>>> unify them. With an example it is easy to see. If I am to render for 
>>> example a template call news.html like it:
>>>
>>> 1. news.html
>>>
>>> {% extends "base.html" %}
>>>
>>> {% block title %}
>>> {% include "inc.news.title.html" %}
>>> {% endblock %}
>>>
>>> {% block content %}
>>> {% for news_item in news %}
>>> {{ news_item.title }}
>>> {{ news_item.subtitle }}
>>> {% endfor %}
>>> {% endblock %}
>>>
>>> 2. base.html
>>>
>>> >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>>> http://www.w3.org/1999/xhtml; lang="{{ 
>>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif 
>>> %}>
>>> 
>>> {% block title %}{% endblock %}
>>> 
>>> 
>>> {% block content %}{% endblock %}
>>> 
>>> 
>>>
>>> 3. inc.news.title.html
>>> News
>>>
>>> With this command I preproces every template of a settings variable and 
>>> I get something like this:
>>>
>>> news.unify.html
>>>
>>> >> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>>> http://www.w3.org/1999/xhtml; lang="{{ 
>>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif 
>>> %}>
>>> 
>>> News
>>> 
>>> 
>>> {% for news_item in news %}
>>> {{ news_item.title }}
>>> {{ news_item.subtitle }}
>>> {% endfor %}
>>> 
>>> 
>>>
>>> So I have a two improves:
>>>
>>>1. It is more fast. And in a real project a view can render easyly 
>>>50 templates
>>>2. I use news.html to develop and news.unify.html to production. So 
>>>I don't lose legilibility.
>>>
>>>
>>> What do you think about "unify templates feature"? Do you know if exists 
>>> a similar public project in github/gitlab/bitbucket etc?
>>>
>>>
>>> Best,
>>>
>>> -- 
>>> Pablo Martín Cobos
>>> Computer engineer
>>> Python/Django developer
>>> 652 53 37 36
>>> goi...@gmail.com 
>>>
>>> -- 
>>> 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/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%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-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/CAMsYeuFV3EV_3H%2BR0q9xi5Q6EQq6L2cLkatcvrTtSYW%3D2zRk7A%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Juan Pablo Martín Cobos
> Ingeniero informático
> Desarrollador Python/Django
> 652 53 37 36all 
>

Re: What do you think about unify templates feature?

2019-01-18 Thread J . Pablo Martín Cobos

I answer between lines


El vie., 18 ene. 2019 a las 5:03, shiva kumar (<
kannamshivakumar...@gmail.com>) escribió:

> Could you please explain about it. I hadn't understood ur idea.
>


   1. Currently: with you render a view, this render a template. But
   usually, this template extends of another and include others. So Django has
   to get these templates to create an HTML. This process get time.
   2. My proposal: Preprocess templates for some (or all) them. Creating a
   template without extends or includes. So, in my previous email you can see,
   Django render less templates, so Django win time.

We can get a backend a  little faster with very little effort.

Best!



> On Thu 17 Jan, 2019 2:32 pm J. Pablo Martín Cobos 
>> Hi,
>>
>> From one year ago, I am using an own command for Django templates that
>> unify them. With an example it is easy to see. If I am to render for
>> example a template call news.html like it:
>>
>> 1. news.html
>>
>> {% extends "base.html" %}
>>
>> {% block title %}
>> {% include "inc.news.title.html" %}
>> {% endblock %}
>>
>> {% block content %}
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> {% endblock %}
>>
>> 2. base.html
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> {% block title %}{% endblock %}
>> 
>> 
>> {% block content %}{% endblock %}
>> 
>> 
>>
>> 3. inc.news.title.html
>> News
>>
>> With this command I preproces every template of a settings variable and I
>> get something like this:
>>
>> news.unify.html
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> News
>> 
>> 
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> 
>> 
>>
>> So I have a two improves:
>>
>>1. It is more fast. And in a real project a view can render easyly 50
>>templates
>>2. I use news.html to develop and news.unify.html to production. So I
>>don't lose legilibility.
>>
>>
>> What do you think about "unify templates feature"? Do you know if exists
>> a similar public project in github/gitlab/bitbucket etc?
>>
>>
>> Best,
>>
>> --
>> Pablo Martín Cobos
>> Computer engineer
>> Python/Django developer
>> 652 53 37 36
>> goi...@gmail.com
>>
>> --
>> 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/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%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/CAMsYeuFV3EV_3H%2BR0q9xi5Q6EQq6L2cLkatcvrTtSYW%3D2zRk7A%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Juan Pablo Martín Cobos
Ingeniero informático
Desarrollador Python/Django
652 53 37 36all  <652%2053%2037%2036>
goi...@gmail.com

-- 
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

Re: What do you think about unify templates feature?

2019-01-18 Thread J . Pablo Martín Cobos

I answer between lines

El jue., 17 ene. 2019 a las 18:42, Maciek Olko ()
escribió:

> Did you try to measure the difference in time of rendering standard and
> your way?
>
>
Yes. I have several examples:

App Template Num templates rendered before unify Num templates rendered
after unify Time render template before unify (ms) Time render template
after unify (ms) Improve
Django admin admin/index.html 3 1 75 - 110 71 - 79 22%
Django admin admin/change_list.html 26 Command error 180-300 Command error
Django admin admin/change_form.html 16 Command error 350-400 Command error
Django constance admin/constance/change_list.html 7 1 350-400 150-250 75%
Django su su/login.html 5 3 15- 20 10 - 12 54%

My command currently does not work with several complex templates like
admin/change_list.html or admin/change_form.html But we can improve it,
currently it works with almost all.

If there is a nice improve with views that render few templates... imagine
with views with a lot of templates.

I have measure these times with django-debug-toolbar-template-timings

With this email only I want to know if you see it can be a important
feature to add to Django framework... or it is a silly thing.

Best,



> Regards,
> Maciej
>
> czw., 17.01.2019, 10:02 użytkownik J. Pablo Martín Cobos 
> napisał:
>
>> Hi,
>>
>> From one year ago, I am using an own command for Django templates that
>> unify them. With an example it is easy to see. If I am to render for
>> example a template call news.html like it:
>>
>> 1. news.html
>>
>> {% extends "base.html" %}
>>
>> {% block title %}
>> {% include "inc.news.title.html" %}
>> {% endblock %}
>>
>> {% block content %}
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> {% endblock %}
>>
>> 2. base.html
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> {% block title %}{% endblock %}
>> 
>> 
>> {% block content %}{% endblock %}
>> 
>> 
>>
>> 3. inc.news.title.html
>> News
>>
>> With this command I preproces every template of a settings variable and I
>> get something like this:
>>
>> news.unify.html
>>
>> > http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
>> http://www.w3.org/1999/xhtml; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> 
>> News
>> 
>> 
>> {% for news_item in news %}
>> {{ news_item.title }}
>> {{ news_item.subtitle }}
>> {% endfor %}
>> 
>> 
>>
>> So I have a two improves:
>>
>>1. It is more fast. And in a real project a view can render easyly 50
>>templates
>>2. I use news.html to develop and news.unify.html to production. So I
>>don't lose legilibility.
>>
>>
>> What do you think about "unify templates feature"? Do you know if exists
>> a similar public project in github/gitlab/bitbucket etc?
>>
>>
>> Best,
>>
>> --
>> Pablo Martín Cobos
>> Computer engineer
>> Python/Django developer
>> 652 53 37 36
>> goi...@gmail.com
>>
>> --
>> 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/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%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/CALYYG805GZFJL5b_9nortw8Sj%2Bkrx1p4xqki7C96Zd8vHeYsmw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Pablo Martín Cobos

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: What do you think about unify templates feature?

Re: Add support for filter arguments in queryset.exists() and queryset.count()

Re: What do you think about unify templates feature?

Add support for filter arguments in queryset.exists() and queryset.count()

Re: What do you think about unify templates feature?

Re: bulk_update: add exclude arg

bulk_update: add exclude arg

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: What do you think about unify templates feature?

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: What do you think about unify templates feature?

Re: What do you think about unify templates feature?

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: What do you think about unify templates feature?

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: What do you think about unify templates feature?

Re: What do you think about unify templates feature?

Re: What do you think about unify templates feature?

19 matches

Site Navigation

Mail list logo

Footer information