On 17/05/11 14:42, Anshuman Aggarwal wrote:

ModelAdmin.list_display answers this question:

1) Given a Python object that is a Model instance, what pieces of
information should we display about it in the admin change list?

It answers the question in this way:

We display string representations of A) attributes of the instance,
which can be defined by strings and B) where that does not suffice,
arbitrary callables, which can be defined by strings (referring to
ModelAdmin attributes), or can be actual callables.

However, once you've answered that question, you've got another:

2) Given only a ModelAdmin and/or Model class, how can we define
*titles* (i.e. column headers) for the pieces of information defined by
list_display?

The answer to this is harder, because in general we can't. However, we
can make some pretty good guesses that will cover 95%. These include:

  A) if the piece of information is an attribute that is a field on the
     class, use metadata from the Model field to create the title i.e.
     Field.verbose_name.

     This is a very good guess, because we can be pretty sure that the
     attribute will correspond to the field.

  B) if the attribute is '__str__', use the verbose_name of the Model

Failing this:

  C) Just turn 'some_attribute' into 'Some attribute'

and then:

  D) Allow complete customisation via the 'short_description'
     functionality

Given this is what list_display is about, the suggestion of supporting
'__' like in list_filter is just the wrong thing, because that syntax
has to do with traversing model relationships. Given question (1), which
is the primary question, and the answer we've come up with so far, a
much more appropriate suggestion would be to use dotted path syntax:

  'some_obj.some_field'

Using '__' only makes sense for answering question 2, and only for case
2.A, and this is the reason we end up with silly things like
'foo____str__', which, even if we could get it work robustly, is
extremely ugly.

Then comes the question - should we support the dot syntax? This is
sensible for answering Q1, but not for Q2, because you can't go from
attributes to fields in general. We could, perhaps, support dot syntax
and attempt to do field lookups, but then, firstly, we've got some
implementation problems:

We will either have to

 - duplicate some of the logic from the ORM about traversing fields,
   adding in the attribute lookups.

 - OR put logic into the core ORM that is there to support this
   admin functionality.

(This applies whether we use '__' or '.' syntax).

Both of these are big code smells.

Secondly, we also have a question of what we do this the field
information once we've got it. Suppose we have these models:

class Place(Model):
    short_name = CharField()
    realm = CharField('Country')

class Person(Model):
    full_name = CharField()
    level = CharField() # e.g. BA, PhD

class Department(Model):
    name = CharField()
    manager = ForeignKey(Person)
    location = ForeignKey(Place)

And then:

class DepartmentAdmin(ModelAdmin):
    list_display = ['name',
                    'manager.full_name',
                    'manager.level',
                    'location.short_name',
                    'location.realm'
                   ]

What should the display columns be called? I think I would want:

Name | Manager | Manager level | Location | Country

3 different rules would be required to satisfy all these, and all rules
give really bad results in some cases. Once you add i18n in, some rules
get completely impractical.

The success rate for this kind of guessing can't be much better than
50%, and that is just not worth it - we've already got a 95% solution,
with a method for handling the 5%, so I cannot see that adding a lot of
fragile machinery to get to a 97% solution is going to be worth it.

I could just about see a case for supporting the dotted syntax and not
attempting anything clever to answer Q2, but given the problems
highlighted above, you are very often going to need to use a callable
and 'short_description' to fix things, so I'm still unconvinced it is
worth it. If you have a problem with hundreds of fields that follow a
pattern, I'd suggest using a solution similar to the one I posted on the
ticket.

Best regards,

Luke

--
Sometimes I wonder if men and women really suit each other. Perhaps
they should live next door and just visit now and then. (Katherine
Hepburn)

Luke Plant || http://lukeplant.me.uk/