Hate to bump a thread, but any thoughts on the last proposal, Luke?
On May 20, 4:13 pm, Anshuman Aggarwal wrote:
> Usage would be: list_display = (ff('model__field__fkfield',
> short_description='FK Field') but ideally, the short_description
> should be optional with the default logic being used to fetch it out
> of the FK.
>
> We can change the __ to a . easily enough without any impact to
> anything else.
>
> On May 20, 4:08 pm, Anshuman Aggarwal wrote:
>
>
>
>
>
>
>
> > Hi Luke,
> > Thanks for a detailed reply. I have gone over your points carefully
> > and agree on most except a few key ones.
>
> > Based on your response:
> > - The question here is really how often is the guesswork right and
> > for how many different projects/use cases.
> > I have overseen Django used at more than a few projects and my
> > observation is that the guesswork logic that you described that is
> > presently followed for the headers will work very well (~75%) for FK
> > fields (i.e. take short description/verbose_name/name of field itself)
> > from the final model.
> > I realize that this may not be perfect and for advanced cases a
> > fallback to callables would be required. its anybody guess without
> > analyzing every single django project out there to say how many people
> > would benefit.
>
> > All in all, without this estimation maybe not worth the effort you
> > described building the . syntax
>
> > I have an alternate suggestion:
> > Can we develop the accessor callable that you described to be able to
> > access the short descrition/verbose_name etc and make it available as
> > a shortcut/decorator in the admin? With that, it won't complicate code
> > for the main admin, while keeping a quickie around for others??
> > I have taken your example and developed it a bit (though it still
> > violates DRY IMHO), but was wondering how the admin can pass in a
> > parameter with the model description so that it can be traversed to
> > obtain the field verbose_name/short_description parameters
>
> > def ForeignFieldFunc(field_name, short_description=None,
> > admin_order_field=None):
> > def accessor(obj):
> > val = obj
> > for part in field_name.split('__'):
> > val = getattr(val, part)
> > return val
> > if short_description:
> > accessor.short_description = short_description
> > else:
> > accessor.__name__ = field_name
> > if admin_order_field:
> > accessor.admin_order_field = admin_order_field
> > else:
> > accessor.admin_order_field = (field_name,)
> > return accessor
>
> > Regards,
> > Anshuman
>
> > On May 17, 11:35 pm, Luke Plant wrote:
>
> > > Hi Anshuman,
>
> > > On 17/05/11 14:42, Anshuman Aggarwal wrote:
>
> > > > list_display
> > > > allows for callables and hence arbitrary names can be used which are
> > > > similar to the syntax for foreign key fields.
> > > > However, this problem exists for list_filter also: someone may define
> > > > a
> > > > field with the name class__field and try to use that in list_filter as
> > > > a
> > > > foreign key field. (i've just checked that you can indeed name a field
> > > > like that)
>
> > > > So we can't really be compensating for dev stupidity at the cost of
> > > > functionality as we haven't done in list_filter also.
> > > > Since all FKs always start with an alphabet are in the regex format
> > > > (.+__.+.*), the __unicode etc cases can be easily and correctly
> > > > filtered
> > > > as is required to be done in list_filter.
>
> > > OK, back to basics:
>
> > > 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