Hi Wim,
On Wed, Feb 26, 2014 at 7:48 AM, Wim Feijen <[email protected]> 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 [email protected].
To post to this group, send email to [email protected].
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.
