On Wed, 2008-02-13 at 22:35 -0800, grahamu wrote:
>
> 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).
That's because you are expecting things from reverse() that it
explicitly doesn't do. In particular, the "args" and "kwargs" parameters
to reverse are only checked against capturing groups in the URL's
regular expression.
The reason for this is that to also permit people to specify things in
extra_dict will rapidly (in fact, already has when people suggested
this) lead to confusion about what is and isn't possible and how Python
actually works. String matching is easy: all strings with the same value
compare as equal. But then people start wanting to put QuerySets in
there or other class instances or complex objects that have interesting
equality comparison behaviour and the slippery slope leads straight to
hell. So, to maintain sanity all around, you can't do that, as you've
discovered. That's intentional.
Fortunately, there's a solution, I'm pretty sure:
(r'^(?P<myname>drink)/', include(app.urls))
(r'^(?P<myname>eat)/', include(app.urls))
or, even more succintly:
r'^(?P<myname>eat|drink)/', include(app.urls))
These might trip across other urlresolver bugs, from memory (I have a
feeling the bug still exists where if we don't match the first item
that's a potential candidate, we fail unconditionally, rather than
testing everything). In any case, I'll check out those side cases in the
next few hours, since I'm doing some trunk work at the moment and this
has come up.
So either the alternatives work right now or will work within a day or
two. That's certainly the way to approach this, though, because the
other way just opens up the door to far too many user problems.
Regards,
Malcolm
--
The sooner you fall behind, the more time you'll have to catch up.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
