Hi All! Sorry for late response.

On Fri, Oct 29, 2010 at 7:47 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> ... which is something you can already do with a callable column::
>
> class MyModelAdmin(ModelAdmin):
>   def formatted_foobar(self, obj):
>       return slugify(truncatewords(obj.foobar, 2))
>
>    list_display = ('formatted_foobar', 'name', 'age')
>
> with the added benefit that you can do a lot more that just applying a
> template filter -- to pick a trivial example, you could conditionally
> apply *different* template filters, depending on the value of the
> attribute.
>
Yes, I know about it. Ticket #8054 is not cover this case, you need to
define a new function for this. Ticket #8054 is not about it. It's about how
you put in ModelAdmin meta data of this function related to display it in
admin change list. I'll try to explain it bellow, but now let's speak about
template filters. Most common case in change list customization is then you
need just apply some template filters to 1 model field for every model
objects. This ticket lets do it more easy. If you need more logic to render
field, you must define new callable for it of course.

The main benefits of #8054 is considerate all options related to admin
change list customization in list_display property of ModelAdmin.

It solves some little code organization problems with callable attributes.
For example, If you want customize change list header for column getting
form model method, you can use attribute short_description for it, but this
is related only for admin change list and not ever need anything else. It's
more logically to define it something in ModelAdmin and not creating new
callable or copy existing for customization needs. It's first proposed
benefits.

The second is a small refactoring of django.contrib.admin. This ticket adds
some changes to admin change list generation. Currently admin change list is
generating with a couple of template tags and most of all change list logic
considerate in this template tags. This ticket move logic of displaying
object field value and column header to special place - classes inherited
from ListColumn.


Honestly, I can't see the benefit in what you're proposing here.
> Before you spend a whole lot more time updating the patch to try and
> make and keep it trunk ready, you need to convince me (or another
> member of the core team) that the idea you're proposing is worth
> adding to trunk. Otherwise you're just going to be spending a lot of
> time maintaining a patch that won't ever get committed.
>
Hm. In this case why this ticket is on accepted triage stage and assigned on
the one from core team developers a long time?
It is my first experience to send my code in this community, this ticket was
related to my needs, and I followed only instructions from official Django
documentation.


Cheers,

Alex Kamedov

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to