On 7 June 2012 18:17, Andrew Godwin <and...@aeracode.org> wrote: > This means either having to register custom fields (like admin classes, > for example), or requiring fields to live in a fields.py or fields > package (like models and models.py). This is to provide for a > less-fragile way of referring to them than their full module path (which > might change based on project name or package location). > > Neither of these two options is perfect - registration means a little > more "boilerplate" code, while requiring them to be in a certain module > is going to hurt apps that don't have them there already. For that > reason, I prefer the registration approach - it will only be one extra > line per field, it's a pattern already used for admin classes and > filters/tags, and it will allow for field classes to be renamed while > keeping the same registered name (if someone wants).
I prefer the registration approach because it's more explicit. But there's also the third option of using both, auto-register anything in fields.py but allow explicit registration for anything found elsewhere. - Andy -- 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.
