> I've done some thinking on this, too, and I think the cleanest way to
> solve it would be to introduce optional names for URL patterns.
Sounds really nice. And it doesn't even enforce to break the {% url %} tag:
{% url some.view ... %} -> view lookup
{% url "some name" ... %} -> name lookup
But my current problem with reverse URLs is not generic views. I'm using
include() to put comments and full-history under the url of the object
(/article/foo/ -> /article/foo/comments/ or /article/foo/history/). As
these views are used for multiple objects (articles, news, ...) the
reverse lookup is not possible. Could be solved easily by having the
parameters used for the include() available when resolving the url (I
pass an argument that tells the views how to load the object). Even
nicer would be to be able to put this argument into the name.
Example:
article-patterns:
-----------8<--------------------------------------------------------
urlpatterns = patterns('foo.article.views',
(r'^$', 'index'),
# [...]
(r'^(?P<slug>[a-z0-9-]+)/comments/', include('foo.comment.urls'),
{'load_func': 'foo.article.views.get_article'}),
)
# load_func is passed the args/kwargs got from the resolver (slug here)
-------------------------------------------------------->8-----------
comment-patterns:
-----------8<--------------------------------------------------------
urlpatterns = patterns('foo.comment.views',
(r'^$', 'view_comments'),
(r'^post$', 'post_comment'),
)
-------------------------------------------------------->8-----------
Now, something like this would be nice (a additional parameter should
look cleaner, but this shows what I mean I think):
-----------8<--------------------------------------------------------
urlpatterns = patterns('foo.comment.views',
url(r'^$', 'view_comments', name="%(load_func)s.view_comments"),
url(r'^post$', 'post_comment', name="%(load_func)s.post_comment"),
)
-------------------------------------------------------->8-----------
Perhaps this case is to specific to be added to a {% url %} refactoring,
but if it can be done on the way it should be considered. Would really
improve what you can do with include().
Greetings, David Danier
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
