#5863: list_display does not allow functions of referenced objects
-------------------------------------+-------------------------------------
     Reporter:  Beat Bolli           |                    Owner:  nobody
  <me+django@…>                      |
         Type:  Uncategorized        |                   Status:  closed
    Component:  contrib.admin        |                  Version:  master
     Severity:  Normal               |               Resolution:  wontfix
     Keywords:  list_display         |             Triage Stage:  Design
                                     |  decision needed
    Has patch:  1                    |      Needs documentation:  1
  Needs tests:  0                    |  Patch needs improvement:  1
Easy pickings:  0                    |                    UI/UX:  1
-------------------------------------+-------------------------------------

Comment (by Michael):

 Replying to [comment:18 Ramiro Morales]:
 > I'd say this ticket can be closed (I found it when looking for material
 related to #10230).
 >
 > Using callables (bare functions for example, i.e. no model methods nor
 `ModelAdmin` subclasses methods) make the "It violates DRY: I have to
 define the same function on each model that references the foreign model"
 argument moot.
 >
 > Also, when it comes to the HTML table headers:
 >
 >  1. Seeing a bare 'Code' header (using the
 [http://code.djangoproject.com/ticket/5863#comment:6 comment 6] example)
 that refers to a `code` field of a `Client` model that is located one or
 more FK-hops away isn't necessarily a good idea, it can be confusing
 because the user could assume it refers about a (non-existent) `code`
 field local to the model being displayed.
 >  2. In the case of more that one level of indirection, having an
 automatically-generated `'Hop1 Model > ... > HopN Model > Field'` header
 wouldn´t be practical/scalable.
 >
 > It's more practical in that case that the developer sets explicitely an
 appropiate, unambiguous header literal using the `.short_description`
 facility.
 >
 > In other words, I'd say current functionality plus a bit of work satisfy
 the needs expressed in this ticket discussion for this arguably rare
 scenario.

 Unless I am missing something, I don't see how `1.` solves the issue. Say
 I have Model `A`, and it has a foreign key to `Z`. Then I have model B,
 which has a foreign key to 'A'. Now in model `B` and `A` I wish to show
 one of `Z`s field's admin, how do I use the common function?

 And with regards to it being rare, as mentioned above about `164K` views
 on stack overflow.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/5863#comment:48>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/090.ea4fe7e48522ae276f0c2741c94351d0%40djangoproject.com.

Reply via email to