Move method properties for admin list customisation to ModelAdmin

The reason I suggested filters be specified like this was because I thought it would be simpler for users to re-use this element of template syntax than to import the actual filter functions, especially because these would have to be curried to pass arguments.

ListColumn would probably also need to take a load_filters=[] kwarg to address templatetag library loading.

Initial patch

I have tried coding up an implementation of this ticket (exactly as described above except the kwarg is 'header' not 'heading'). Patch needs improvement as it isn't pep8-compliant.

Not much time to get this in before feature-freeze.

Fixed sorting with ListColumns?

I am going to take a step back and put this on 1.0-beta. However, the implementation is a bit too much for this. I want to just decouple the list_display methods from the model. It will be backward incompatible.

@brosner: allow list_display methods/functions to also exist on the model instance would be good, though. There are plenty of methods that naturally belong on models that are useful in the admin display.

@malcolmt: Good point. I was just talking with Joseph and I was wondering about the naming of admin_order_field. If we have methods in ModelAdmin? that admin bit is redundant. Should that be dropped or maintained?

Would you just search both the model instance and the ModelAdmin for callables matching the list_display column? My patch should be backwards compatible, so it could be backwards compatible with yours if you are implementing it like that.

This turned out to be quite a nice refactor, as it broke up the monolithic functions for rendering ChangeLists (actually they were template inclusion tags) into distinct stages of working out how to render each column, then what to render, then rendering it, so that's something else to be said for developing this post-1.0, not least the neat separation between content and presentation that the filters kwarg allows.

@Daniel: I have sort of hijacked this ticket. You sort of described two different things one of which needs to get in before 1.0. The new API bits you have described above are worthy once we look at modified the API a bit more for the ChangeList stuff. The way I have it setup is it looks at the ModelAdmin first and if not found looks at the model level for non-field, non-callable (a new feature i am adding) in list_display.

That's fine. So you'll also implement #7503?

Yes, I realise it was really two separate things. It started out as just noting that in ModelAdmin there's now space to tidy up the system of method attributes, but somewhere along the way my main motivation became wanting to apply template filters. I noticed it made a lot of sense not just for the existing modifiers I mentioned, but practical sense in several of my apps, and that's a much bigger win than just API pointling.

For instance, you can add useful columns entirely with ListColumn, for example:

class SpecialOffer(models.Model):
    name = models.CharField(...)
    ends = models.DateTimeField()

class SpecialOfferAdmin(admin.ModelAdmin):
    list_display = [
        'name',
        'ends',
         admin.ListColumn('ends', filter='timeuntil', heading="Ending in")
    ]

(In [8352]) Fixed #7503 -- Allow callables in list_display. This also does a lookup on the ModelAdmin? for the method if the value is a string before looking on the model. Refs #8054. Thanks qmanic and Daniel Pope for tickets and patches.

Moving to post-1.0 for the API changing parts. This should be looked at with a ChangeList and templatetag refactor of the admin. Not sure when or how, but this is related.

Milestone post-1.0 deleted