On Tue, Oct 20, 2009 at 5:34 AM, Ivan Sagalaev
<[email protected]> wrote:
>
> Hello!
>
> I've just stumbled upon a difficult to understand problem. I have an app
> that has an urlconf which is included in a project under a namespace:
>
> (r'^blog/', include('app.urls', namespace='blog')),
>
> This namespace allows things like {% url blog:article ... %} which is
> very nice. But reversing doesn't work when an app itself tries to
> reverse its own urls having a callable at hand:
>
> reverse(views.article, args=[...])
>
> It doesn't work because namespaced URLs are basically excluded from
> resolver's reverse_dict and are put in their own resolvers under
> namespace_dict. And reverse doesn't traverse those when it gets a callable.
>
> On one hand I can see logic here: trying to reverse a namespaced URL
> without specifying a namespace can lead to ambiguous results. But in
> practice it means that one can break any third-party app that reverses
> its URLs (using models.permalink, redirect, or reverse) just by
> including its urlconf under a namespace. Because an app doesn't know its
> namespace and then has no way of constructing a correct URL.
>
> Am I missing something or is it an evil bug?
A little bit of both.
On the 'missing something' front, reverse() now takes a 'current_app'
argument that gives context to the app lookup, which resolves the
ambiguity from the point of view of the reverse() function.
This solves the problem as long as applications have been built to
provide a namespace. However, this doesn't fully address the 'bug' you
describe - an application that hasn't been built to accept namespaces
will have problems if it is deployed in a namespace. contrib.comments
is one example of an application that you just can't deploy in a
namespace. It hasn't been written to allow this mode of deployment.
I'm not sure of the best solution to this problem, though.
This is at least partially a documentation problem. contrib.comments
simply isn't namespace-ready. The docs should probably say so, as
should the docs for any other app that provides an URLpattern that
needs be deployed.
However, it isn't *just* a documentation problem. We should probably
also provide some API-level protection to make sure that mistakes like
this aren't made by accident.
One possible approach would be to allow an application to mark its URL
patterns as "namespace safe"; include() would then raise an error if
the URLpattern that is included with a namespace doesn't have this
flag set (and/or raise an error if the urls are included without a
namespace and the flag *is* set).
The default would need to be 'not safe', so this would be a backwards
incompatible change for anyone that is currently using include with a
namespace on an app that doesn't have the flag set. This would be
slightly backwards incompatible for any existing uses that don't use
reverse() internally, or ship with sample templates that use {% url
%}.
However, I'm open to any other suggestions.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
