On Feb 13, 7:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
[...]
> As Alex pointed out, you're calling reverse() on something that isn't a
> direct URL pattern. Don't do that. It makes no sense to call reverse()
> on something that is actually a collection of URL patterns. Instead,
> pick one of the URL patterns inside urls2 and call reverse on that.
Good point, one which I now understand from Alex' and your comments.
What I am trying to accomplish is two different project URLs which
both resolve to the same application urlconf, yet can be
differentiated by a view in the application. In other words, the app
view needs to determine the root URL used to reach the view.
A slightly different example is in order. In this example we have a
'mysite' project url config, and an application url config.
mysite.urls contains
[...]
(r'^drink/', include('app.urls'), {'myname':'drink'}),
(r'^eat/', include('app.urls'), {'myname':'eat'}),
[...]
URLs /mysite/drink/ and /mysite/eat/ are next resolved at the
application urlconf:
mysite.app.urls contains
[...]
url(r'^$', 'views.func', name='food-view'),
[...]
At this point /mysite/drink/ and /mysite/eat/ resolve to the same app
view function, "func".
mysite.app.views contains
def func(request, myname):
[...]
originating_url = reverse('food-view',
kwargs={'myname':myname})
This does not give me the results I expect, although it seems that it
should. I expected kwargs 'myname' to help reverse() differentiate
between the two URLs. Instead, both originating URLs (/mysite/drink/
and /mysite/eat/) reverse() resolve to /mysite/drink/ (the first URL
in the project urlconf).
Since this concept is proving difficult to implement while most other
tasks in Django are easy, I began wondering if my design needs
refactoring. For instance, I could have mysite.urls resolve /drink/
and /eat/ to separate app urlconfs:
(r'^drink/', include('app.urls.drink'), {'myname':'drink'}),
(r'^eat/', include('app.urls.eat'), {'myname':'eat'}),
That idea violates DRY, because both app urlconfs will contain exactly
the same subsequent patterns and function calls but with different
pattern names. Most of my refactoring ideas end with the same result,
duplication of code. Perhaps that is inevitable in this case.
Regardless thanks very much for clearing up my initial confusion about
where to name a pattern.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
