No one ready to weigh in on this? :-( On Thu, Aug 23, 2012 at 4:17 PM, Klaas van Schelven < [email protected]> wrote:
> Hi all, > > I'm not really ready to post this as a bug, please help me correct any > possible misunderstandings before I do so. > > I was gently pushed towards the future url template tag due to my > screen filling up with DeprecationWarnings > > There isn't a whole lot of documentation about the new url tag. This > is what I could find: > > https://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-url-and-ssi > and the "Forwards compatability" box on > > https://docs.djangoproject.com/en/1.3/ref/templates/builtins/#std:templatetag-url > > Now, given the fact that the url tag is described as able to take a > variable, I assumed it would be possible to pass callables to it. (In > fact, I already had manually created such functionality myself for our > app, and was happy to notice that Django now appears to support it out > of the box). I.e. > > # views.py > def myview(request, obj_pk=None): > pass > > def other_view(request): > return render('template.html', {'link': myview}) > > # template.html > {% load url from future %} > {% url link obj_pk=1%} > > However, this fails, since the regular template variable resolution > process is reused to resolve 'link'. Since link is a callable Django > will attempt to call it. However, 'other_view' shouldn't really be > called (rather, it should be used as the input of a call to reverse). > In this case specifically it will fail since the parameters 'request' > and 'obj_pk' aren't provided. The url templatetag will then try to > reverse the empty string or any value given in TEMPLATE_DEBUG. > > I see the following 2 logical courses of action and a possible extra: > 1] the status quo is the desired behavior: improve the documentation > 2] allow for passing callables. However, this also makes certain use > cases impossible. I.e. > > def other_view(request): > return render('template.html', {'link': lambda: 'myapp.myview'}) > > will become impossible, including more meaningful equivalents. > > extra] don't silently continue when the url's first param fails to > evaluate properly only to fail 3 lines later with an incomprehensible > error message. > > Hope this prompts some discussion / resolution. I'm willing to copy > paste the above to track if necessary. > > ciao, > Klaas > -- Klaas van Schelven +31 6 811 599 10 -- 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.
