I've been using the patch from #1105 in my local branch of Django for
a long time now. To be honest, I've hit the need to have access to the
existing context in a simple_tag far more frequently than the need to
return a single value as a named variable in the context, and I'm
definitely +1 on adding a `takes_context` argument to `simple_tag` (or
something else that achieves the same thing).
However, regarding the `register.assignment_tag` proposal, we still
have the same problem -- some people will want access to the context
in there, too.
One suggestion from #1105 was to split out this functionality into
individual decorators, @takes_context, @takes_block. I'm not sure how
easy this would be technically to implement, but I think it would
solve the `takes_context_plus` sink problem Malcolm describes as we
potentially add more special case tag types (simple, inclusion,
assignment, etc.)
However, I guess this would be more involved and may involve some
backwards incompatibility and a deprecation path. I don't think any
full blown ideal solution should prevent us form committing just the
`takes_context` argument to `simple_tag` immediately (bringing it
inline with `inclusion_tag`, which has had this ability forever), a
request that has been around for a long time that would solve both use
cases mentioned here.
Even though it doesn't have the "as X" syntactic sugar of an
`assignment_tag`, it is more versatile -- you can update more than
just one variable, and if you need to name the variable it will go
into you could always just use the first argument to your simple tag
to define it e.g. `{% getfunction_as "varname" %}`
Cheers.
Tai.
--
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.
