Hate to bump a thread, but any thoughts on the last proposal, Luke?
On May 20, 4:13 pm, Anshuman Aggarwal <anshu...@brillgen.com> 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 <anshu...@brillgen.com> 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 <l.plant...@cantab.net> 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 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/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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.
