On Sep 10, 2013, at 7:05 PM, Russell Keith-Magee <russ...@keith-magee.com> 
wrote:

> I share James' reservations about this as a feature -- attaching flags to 
> Meta is something I can see being abused in all sorts of ways -- but that 
> doesn't mean there's no legitimate uses for extensions to Meta. For example, 
> the USERNAME_FIELD added in support of custom users should, arguably, be a 
> Meta option -- but there was no way we could add that without making a Meta 
> option available to every class.

For what it's worth, I've loosely copied Django's "metaclass w/ Meta options" 
pattern for several projects. In cases where I needed a bit more flexibility, 
the metaclass looked for a well named attribute on the class that would specify 
the options class to use. For example:


class Model(object):
    # _meta is a ModelOptions instance
    __OPTIONS_CLASS__ = ModelOptions


class Foo(Model):
    # _meta is a ModelOptions instance, inheriting Model's __OPTION_CLASS__


class User(Model):
    # _meta is a UserModelOptions instance that looks
    # for a USERNAME_FIELD option
    __OPTIONS_CLASS__ = UserModelOptions

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to