Hey Robert --
Thanks for your work on this -- I've just had a chance to check out
the branch for the first time, and it's just amazingly awesome.
On Dec 16, 2005, at 8:09 PM, Robert Wittams wrote:
Ok, so in the magic-removal branch, I've refactored things in a way
which makes it very easy to extend the meta system as a third-party.
Sweet! The general idea you've outlined below is GREAT, but I'd like
to nitpick a bit if you don't mind:
class Something(Model):
name = CharField(maxlength=100)
tags = TagCollection()
comments = CommentCollection()
acls = ACLCollection()
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.
This might not apply specifically to order_with_respect_to -- the
idea of making Ordering a Field class is a very good one -- but it
certainly would apply to the horrific has_related_links hack that's
hard-coded in the metasystem and needs to die a short, brutal death.
I'm also itching for the ability to be able to be able to add domain-
specific "behavior" to models -- this would make it easy to create
behavior like "acts_as_versioned" (from Rails).
I discussed this with Adrian on IRC a few times, and we agreed that
events would be a good way to handle quite a number of the issues we
face - particularly loose coupling.
Yes -- great call.
/me scurries off to look at pydispatcher...
Yes, pydispatcher looks like a good idea. I'm +1 to adding it to
Django (I'd prefer django.core.dispatch but then I'm a fan of deep
namespaces) both because of the naming problem and so that we don't
have version mismatches in the past. It also fits with our
philosophy of having Django's core not rely on any external libraries.
I'll stash RuleDispatch away for a rainy day...
There are quite a number of other areas this can be applied to as
well.
I'll second what Brent asked: do you think we should do away with
middleware and use the events system instead? There will still need
to be a way to register event listeners in your settings file so
they'll get loaded, but I've never been really happy with the
middleware API and wouldn't mind replacing it with a bunch of events
in the handler... thoughts?
Thanks again,
Jacob
