Opened 13 years ago

Closed 10 years ago

Last modified 10 years ago

#17551 closed Cleanup/optimization (invalid)

Namespaces declared in different places

Reported by: German M. Bravo Owned by: Grzegorz Nosek
Component: Documentation Version: 1.4-alpha-1
Severity: Normal Keywords:
Cc: German M. Bravo Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently, if the same namespace is declared for different included urls, only one included urls module gets the namespace.

In this scenario:

urlpatterns = patterns('',
    url(r'^first/', include('first.urls')),
    url(r'^first_default/', include('first.urls', app_name='first', namespace='first')),
    url(r'^first_in_a/', include('first.urls', app_name='first', namespace='A')),
    url(r'^first_in_b/', include('first.urls', app_name='first', namespace='B')),
    url(r'^second/', include('second.urls')),
    url(r'^second_default/', include('second.urls', app_name='second', namespace='second')),
    url(r'^second_in_a/', include('second.urls', app_name='second', namespace='A')),
    url(r'^second_in_b/', include('second.urls', app_name='second', namespace='B')),
)

The expected output is:

reverse('first') -> /first/
reverse('second') -> /second/
reverse('A:first') -> /first_in_a/
reverse('A:second') -> /second_in_a/
reverse('B:first') -> /first_in_b/
reverse('B:second') -> /second_in_b/

But instead is:

reverse('first') -> /first/
reverse('second') -> /second/
reverse('A:first') -> /first_in_a/
reverse('A:second') -> NoReverseMatch
reverse('B:first') -> /first_in_b/
reverse('B:second') -> NoReverseMatch

Attachments (3)

#17551-multiple_namespaces.tar.bz2 (4.1 KB ) - added by German M. Bravo 13 years ago.
Example which fails
#17551-multiple_namespaces.diff (7.4 KB ) - added by German M. Bravo 13 years ago.
Added tests (makes just two of them fail)
17551.diff (6.4 KB ) - added by Grzegorz Nosek 13 years ago.

Download all attachments as: .zip

Change History (16)

by German M. Bravo, 13 years ago

Example which fails

comment:1 by German M. Bravo, 13 years ago

Cc: German M. Bravo added

by German M. Bravo, 13 years ago

Added tests (makes just two of them fail)

comment:2 by Grzegorz Nosek, 13 years ago

Component: UncategorizedCore (URLs)
Has patch: set
Owner: changed from nobody to Grzegorz Nosek
Patch needs improvement: set
Status: newassigned

by Grzegorz Nosek, 13 years ago

Attachment: 17551.diff added

comment:3 by Grzegorz Nosek, 13 years ago

Patch needs improvement: unset

comment:4 by Jannis Leidel, 13 years ago

Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

comment:5 by Tomek Paczkowski, 13 years ago

Triage Stage: AcceptedReady for checkin

Good for me.

comment:6 by Tomek Paczkowski, 13 years ago

Version: 1.31.4-alpha-1

comment:7 by Paul McMillan, 13 years ago

Severity: NormalRelease blocker

Marking as a release blocker

comment:8 by Aymeric Augustin, 13 years ago

Severity: Release blockerNormal

After further discussion, this isn't really a release blocker, since it isn't a regression or a major bug in a new feature.

However, the patch looks correct and stands a good chance to be committed before 1.4.

I've spend a few hours on it, but I don't feel sufficiently familiar with the URL namespacing feature to commit it. I asked Russell (the original author) if he could take a look.

comment:9 by Aymeric Augustin, 12 years ago

Triage Stage: Ready for checkinAccepted

After discussion with Malcolm (the other author), this rather looks like a misuse of app_name.

This could be resolved by improving the documentation rather than changing the code.

comment:10 by German M. Bravo, 12 years ago

I really wish this could be checked in since, even of it's a "missuse" given the original design, I believe it to be a good addition which just further increases the url resolvers code isometry and flexibly by allowing the use of the same namespace name across apps... *plus* it doesn't really break anything, just covers what I believe to be a legit and intuitive use case for namespaces.

Any other thoughts about this ticket?

Last edited 12 years ago by German M. Bravo (previous) (diff)

comment:11 by Tim Graham, 10 years ago

Component: Core (URLs)Documentation
Has patch: unset
Type: BugCleanup/optimization

Moving to documentation based on Aymeric's comment 22. If someone wants to lobby for a design change, please start a thread on the DevelopersMailingList.

comment:12 by Tim Graham, 10 years ago

Resolution: duplicate
Status: assignedclosed

I think we can roll this documentation into #17707 - "Docs for URL namespaces should explain the motivation and use cases".

comment:13 by Tim Graham, 10 years ago

Resolution: duplicateinvalid

It's documented that "Instance namespaces should be unique across your entire project." That seems to be the issue here.

Note: See TracTickets for help on using tickets.
Back to Top