Django:使用任意 URL 组件进行反向 URL 查找
假设有一个 Django 应用程序 shop
,其 urls.py 包含在主 urls.py 中:
# main urls.py
urlpatterns = patterns('',
(r'^[^/]+/shop/', include('shop.urls')),
)
请注意,/shop
之前有一个任意前缀。这对于 shop
应用程序来说不感兴趣,它只对某些中间件感兴趣。
shop.urls
可能如下所示:
# shop's urls.py
urlpatterns = patterns('',
url(r'^$', index, name="shop_index"),
url(r'^product/(?P<id>[^/]+)$', product, name="shop_product"),
)
我现在想在我的 shop
模板中使用 {% url %}
。推翻这个计划的是,生成的 URL 不包含全局 urls.py
中的前缀。生成的 URL 看起来更像,例如
/^/shop/product/1
问题: 现在,是否有可能(在 Django 1.2 或 svn trunk 中)启用反向查找以仅使用当前 URL 中的相同前缀?例如,如果 request.path
是 /foo/shop/
,则 {% urls shop_product id=1 %}
返回
/foo/shop/product/1
我的唯一方法想出来的是拥抱前缀并将其发送到 shop
应用程序视图,但这是一个非常糟糕的解决方案,因为 shop
然后必须处理它不处理的东西。根本不需要。
Assume a Django app, shop
, whose urls.py is included in the main urls.py:
# main urls.py
urlpatterns = patterns('',
(r'^[^/]+/shop/', include('shop.urls')),
)
Note, that there is an arbitrary prefix before /shop
. This is of no interest for the shop
app, it's only interesting to some middleware.
The shop.urls
could look like this:
# shop's urls.py
urlpatterns = patterns('',
url(r'^
I now want to use {% url %}
in my shop
templates. What overthrows this plan is, that the generated URL doesn't include the prefix from the global urls.py
. The generated URLs look more like, e.g.
/^/shop/product/1
Question: Now, is there a possibility (in Django 1.2 or svn trunk) to enable the reverse lookup to use just the same prefix, that is there in the current URL? For example, if request.path
is /foo/shop/
, that {% urls shop_product id=1 %}
returns
/foo/shop/product/1
The only way I came up with is to embrace the prefix and send it to the shop
app views, but this is a really bad solution, since shop
then has to deal with something it doesn't need at all.
, index, name="shop_index"),
url(r'^product/(?P<id>[^/]+)
I now want to use {% url %}
in my shop
templates. What overthrows this plan is, that the generated URL doesn't include the prefix from the global urls.py
. The generated URLs look more like, e.g.
Question: Now, is there a possibility (in Django 1.2 or svn trunk) to enable the reverse lookup to use just the same prefix, that is there in the current URL? For example, if request.path
is /foo/shop/
, that {% urls shop_product id=1 %}
returns
The only way I came up with is to embrace the prefix and send it to the shop
app views, but this is a really bad solution, since shop
then has to deal with something it doesn't need at all.
, product, name="shop_product"),
)
I now want to use {% url %}
in my shop
templates. What overthrows this plan is, that the generated URL doesn't include the prefix from the global urls.py
. The generated URLs look more like, e.g.
Question: Now, is there a possibility (in Django 1.2 or svn trunk) to enable the reverse lookup to use just the same prefix, that is there in the current URL? For example, if request.path
is /foo/shop/
, that {% urls shop_product id=1 %}
returns
The only way I came up with is to embrace the prefix and send it to the shop
app views, but this is a really bad solution, since shop
then has to deal with something it doesn't need at all.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
不,没有,无论如何都不是一个简单的 django 方式。 Django 不知道你的 [^/]+ 是什么意思,在你的情况下,它是一个应该动态添加到反向 URL 查找的前缀。
我还想知道为什么你将中间件特定信息添加到 url 中,甚至不作为 GET 参数添加,恕我直言,这样做只是自找麻烦。如果您说前缀是特定于中间件的,那么在中间件之外的某个地方弄乱它是没有意义的。
一个可行的解决方案(未测试)是在中间件中设置一个请求上下文变量,例如
environment_prefix
,然后手动将其附加在 url 之前。所以像这样:另一种可能性是尝试实现您自己的 url 模板标签(继承自 url templatetag)以始终包含当前前缀,该前缀又可以是中间件设置的上下文变量。
No there is not, not a straightforward django way anyway. Django has no idea of knowing what you mean with [^/]+, in your case that it is a prefix that should be dynamically be added to a reverse url lookup.
I wonder also why you add middleware specific info to an url and not even as GET paramters, doing something like this is jsut asking for trouble imho. If you say the prefix is middleware-specific, it doesn't make sense to mess with it somewhere outside of the middleware.
A solution that could work (did not test it) is setting in your middleware a request context variable like
environment_prefix
, then append this manually before the url. So something like this:Another possiblity is to try to implemented your own url template tag (inheritted from the url templatetag) to always include the current prefix which can again be a context variable set by the middleware.