On Wed, 2007-03-28 at 08:22 +0400, Ivan Sagalaev wrote: > Malcolm Tredinnick wrote: > > I'd been slowly arriving at the same solution for a related set of > > problems. I was going to whack in another optional (fourth) argument to > > the tuple > > That was actually the second part of my proposal :-) > > >, but, you're right that a function call here makes things a > > bit easier. > > But I fail to see why having patterns as functions is easier... Fourth > parameter in a tuple is backwards compatible while url() is not.
It's not an either/or decision. Differentiating between a tuple and the object -- whatever it might be -- returned from url() inside the URL resolver is easy. Or it can be done as part of the patterns() call as Adrian suggested. There's no need to break backwards compatibility. Extending the URL resolving system is easier if we have an object to work with instead of a tuple for those entries. A lot of the real work can be given to the object, which has a method to do the equivalent of "do I match the path? If so, what should be called with what params?" Now think about how you can replace that object with an object that obeys the same interface but uses a different resolver. Not a compulsory addition, but nice to have without much cost. Feels a bit more declarative, too -- the URL patterns themselves answer the question as to whether they should be applied, rather than the container doing that work. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
