I recently wrote some code to overcome the below limitation with the URL include mechanism:
''' Note that extra options will always be passed to every line in the included URLconf, regardless of whether the line's view actually accepts those options as valid. For this reason, this technique is only useful if you're certain that every view in the included URLconf accepts the extra options you're passing. ''' You can find more details here: http://www.djangosnippets.org/snippets/1444/ In writing this code, it occurs to me that other advanced users might want more control over URL resolution, and it seems to me that a valuable piece of information would be the "name" of the URL, i.e. the same name that gets used for reverse mappings. Then, if folks want to change the dispatch of URLs in some way, they can use the name as a guide for adding extra parameters, using a different callback, etc. So I'm wondering if it would make sense to have URRegexResolver have an alternative to resolve() called resolve_with_name() that returns not just the callback and arguments, but also the name, and I suppose also the regex could be useful in some cases. As my snippet is currently written, in order to change the dispatch for individual view functions, I have to hack into the internals more than I like. I don't think my code is too risky, but it would have been a lot simpler if I could have created a wrapper around URLRegexResolver with my own custom resolve() method that called URLRegexResolver.resolve_with_name() to do the heavy lifting. I'm not pushing hard for this feature...I am more interested in the discussion. I am still pretty new to Django, so I might be overlooking better ways to solve my problem. But I decided to post here, since I think a lot of what I'm interested in learning about are the internals and dev philosophy behind the current limitation. Cheers, Steve --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
