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.