Jacob Kaplan-Moss wrote:
> This rubs me the wrong way a bit. I talked to Adrian about this this
> afternoon in reference to how Managers are created -- another awesome
> improvement, BTW -- and I think my basic problem is the (potential)
> confusion between fields and "behavior" elements. Yes, all fields are
> called "FooField" but it still just looks cluttered to me.
>
> What I'd really like to see is a framework for adding options to the
> META options so that the above could be writen::
>
> class Something(Model):
> name = CharField(maxlength=100)
>
> class META:
> taggable = True
> allows_comments = True
> acls = ['create', 'delete', 'update']
>
> To me this syntax feels... well, it's hard to quantify, but I think
> "cleaner" is the best word. The whole point of having META is to
> differentiate between fields and what I'm calling "behavior" options
> (for want of a better word). Mixing them up feels crufty.
>
I really don't like this. It is *not extensible* from the outside. The
point about just having things in your class that are able to add to it
is that it just works like this anyway (it would be harder to forbid
it). The TagCollection etc can be completely third party, and only
provided in django.contrib as an app - the base system knows nothing
about it. Just think how crazy it would be to have support for every
random extension in META.
The point I'm trying to make is that the way I've architected it, this
will work anyway, because its a general "allow attributes to cooperate
to build up a class" framework rather than a "lets treat every random
nested attribute magically" framework.
The idea is that the class creation stuff becomes understandable, and
tractable, to almost all developers. Rather than thinking "ok, each
attribute is a database field in a table", they will think "ok, each
attribute does something to build up this class".
I really don't want to take something simple and understandable, and
then just add in an arbitrary rule like "subclasses of Field get treated
magically, and you have to jump through hoops to make anything else work".
I don't like this at all , but here is one idea:
class Something(Model):
name = CharField(maxlength=100)
class BEHAVIOUR:
tags = TagCollection()
comments = CommentCollection()
acls = ACLCollection()
Basically an optional group you can stick things in, and it gets
transormed to something that contributes each of its contents to the
class. We could just allow unknown nested classes to act like this, but
that would break for people who are using nested classes for something
else.
The really funny thing about this: All of the examples I gave are at
least as field-like as the existing ManyToMany field.
Robert
