I know this has been discussed (not sure to what depth) but callables is not the solution. Please bear with me and help me (not force me) to understand why what I am suggesting is wrong. I did look in the list and have tried taking this discussion to the ticket system. http://code.djangoproject.com/ticket/5863
In a nutshell, list_display does not accept foreign key __ syntax which is being used everywhere (including list_filter as of 1.3)...Just because callables exist as an advanced way of doing custom items in list does not take away from the argument that __ fk is a very very common requirement in the list display. Here are the options currently available: 1. Write functions everywhere (this involves a lot of repetition for every single foreign field) 2. Write a wrapper like @lukeplant suggested in #5863 (even though it is far superior solution to individual functions in every model) These are all HUGE violation of DRY principles on which sensible programming is based toady. Most model fields already have a verbose_name, admin_sort_order etc. defined ...why should it be required to specify in just boilerplate code all of this all over again? Even in the wrapper function by @lukeplant, this verbose_name cannot be retrieved from the related model. Since the parent__child syntax is being used for list filter, search fields and everywhere else, is there a reason why the list_display has to be sacrosanct? The real question is, will this be accepted as a patch if contributed on the trunk with test cases et all? Regards, Anshuman -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
