Hi Wim,
On Wed, Feb 26, 2014 at 7:48 AM, Wim Feijen <w...@go2people.nl> wrote:
> Hello,
>
> Right now I have a School model containing a OneToOne-relation to User.
>
> In the admin, in search_fields, I can use double underscores to search in
> related fields, for example:
> search_fields = ('place__name', 'school__name')
>
> But in list_display, I can't. For example,
> list_display = ['school', 'school__user', 'place', ]
> gives an error.
>
> I find this totally confusing. More people do.
>
> A ticket has been made six years ago and was eventually closed as won't
> fix. Currently, the proposed solution is to write a custom method or
> callable. I'd like to raise a discussion to reopen that ticket.
>
> For reference, see:
> https://code.djangoproject.com/ticket/5863
> https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8
>
> My arguments to allow such a syntax are:
>
> 1. allowing 'school__user' in list_display is consistent with the
> behaviour of search_fields, list_filter in the admin, and get() and
> filter() query syntax in general.
>
Arguable. As Luke points out in his post to django-dev, the list_display
serves a different purpose to search_fields and list_filter. The latter are
direct database analogs; the former is a display directive. I agree that
consistency is a good thing (I'll even admit that I've inadvertantly put
foo__bar in list_display definitions when I wasn't thinking clearly), but
as Luke points out, the answer isn't *quite* as simple as "just be
consistent", because list_display needs to support modes of interaction
that search_fields and list_filter doesn't.
There's also an argument to be made that in order to achieve "consistency",
support for dunder syntax should be taken *out* of search_fields and
list_filter, to be replaced by richer mechanisms, along the line of custom
filter objects.
2. it saves many people duplicating two to four lines of custom code, and
> in my opinion, allows for a more concise yet extremely easy to understand
> notation.
>
The counterargument to this is that Django should provide a shortcut
function to make it easy. Luke even provides a sample implementation on the
ticket; if we put this in contrib.admin, your "lines of code" argument
would be void.
> 3. ideally, a solution would use select_related in order to save database
> queries and thus be longer than two to four lines of code.
>
I'm a little wary about code being too smart, but yes, there's an
opportunity for optimisation here.
> 4. the need is common, and in onetoonefields specifically.
>
I haven't seen any evidence to support this claim. *You* definitely
need/want it, and there are a handful of participants on the ticket that
clearly want it - but Admin hasn't had this behaviour since the
beginning, and this is the first time in 3 years that the issue has been
raised on the mailing list. We haven't been flooded with requests for this
feature.
> Many people have expressed their interest in this feature, and a core
> developer initially accepted it.
>
True - but many more subsequently rejected it, and have provided detailed
arguments why.
> 5. a long time has passed since then and our policy of accepting tickets
> has changed.
>
Erm... it has? That's news to me.
I'm certainly sympathetic to your request. As I said - I've even made the
mistake of assuming this feature exists. However, Luke makes some very
valid points in his post that you haven't addressed.
The two biggest practical issues he raises:
* Differentiating between '__unicode__' and 'foo__bar'
* The appropriate default column name for 'foo__bar'
If you've got reponses to these issues, please make them, otherwise, I'm
inclined to stick with Luke's analysis. However, I'm a weak -0; I could
live with the pragmatic argument that it's more confusing to not have this
feature, even though the column naming will likely be weird.
I *would* however, be in favour of adding a shortcut along the lines of the
one Luke provided in the ticket.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAJxq84-pfaj079spYahCej-FuiH5aciA7t3dXZ1Y_L344GZzcw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
