On Thu, Aug 23, 2012 at 10: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.
I can't say I can see the benefit here. The 'future' change was made
specifically to normalise the syntax for the first argument to {% url
%}; changing the parsing of the first argument to make it not evaluate
callables strikes me as something that would undo that good work.
I'd be inclined to treat this as a documentation problem, pointing out
that {% url %} isn't a direct connection to reverse() - that the first
argument must be a URL name, dotted path to a view name, or a context
variable that evaluates as such.
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.
