2012/6/7 Andrew Ingram <a...@andrewingram.net>: > 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. >
Continuing on the auto-register approach. Would be a good idea to have just one more option on settings.py that would make all fields auto-registered? Despite being an "all or nothing" option, I don't know if it's that common choose to auto-migrate just part of the application database. This would also make the path more smooth to people wanting to change their app to be auto-migratable. Thanks, -- Dalton Barreto http://daltonmatos.com -- 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.
