New context template tag

[Alex Robbins]

I am a huge fan of simple_tag and inclusion_tag. They take a common
template tag use case and make it very easy to write. It seems like a
common use case that isn't represented is adding a value to context. I
find myself writing tags to add a variable to context very often and
it seems like we should be able to abstract this out.

I'm thinking it would work like this, but would love to get feedback

@register.add_to_context_tag
def tag_name():
do_some_python()
return context_value

This would turn into a tag that worked like this:

{% tag_name as variable %}

Which puts context_value into the context as variable.
------------------------

It could optionally take takes_context, and work like this. This would
make context the required first argument to the function, like
inclusion_tag.

@register.add_to_context_tag(takes_context=True)
def tag_name(context):
do_some_python_that_needs_context(context)
return context_value
----------------------------------

Finally, it could take arguments like simple_tag or inclusion tag.

@register.add_to_context_tag
def tag_name(some, arguments, it, takes):
some_func(some, arguments)
return context_value

which would yield a tag that worked like this:

{% tag_name some arguments it takes as variable %}

-----------------------------
Is this a use case other people have? Can anyone think of a better
name than add_to_context_tag?

Thanks,
Alex

[Eric Holscher]

I usually use James Bennett's django-template-utils for this purpose. It has a nice, simple implementation:

http://bitbucket.org/ubernostrum/django-template-utils/src/tip/template_utils/nodes.py#cl-11

It still requires the annoying Node/function split though.

I know there have been a multitude of third party attempts at improving Django's template tags, and I think it's commonly agreed that they are one of the more boilerplatey bits. Sadly none of the third party libraries have really become defacto, so it's hard to think about including any of them in core. It does seem like a place that could use some expose either in the docs or in the general community though.

Cheers,

Eric

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

[Gregor Müllegger]

I'm a huge fan of Alex Gaynor's templatetag sugar syntax for defining
template tags:

# from the docs:

@tag(register, [Constant("for"), Variable(), Optional([Constant("as"),
Name()])]):
def example_tag(context, val, asvar=None):
if asvar:
context[asvar] = val
return ""
else:
return val

However I don't know how mature this is to be included in the core. It's also
a matter of taste if you like the syntax or not. But its quite intuitive after
you get the concept.

Maybe this clashes with the 1.3 goal of focusing on bug fixes, but it could be
worth to look at it again for the 1.4 release. In the long run there should
really be a much more easier way to define semi complex tags than with the
current Node approach.

So a +1 from me for every approach making template tags easier.

--
Servus,
Gregor Müllegger

2010/7/22 Alex Robbins <alexander...@gmail.com>:
> Eric,
>
> Thanks for the reply! django-template-utils does help some but, like
> you say, you still end up writing a function and a custom node.
>
> Is there a reason we couldn't add another template tag helper like
> simple_tag or inclusion_tag? (I'll write the code and tests) Adding to
> context seems (to me) to be a very common use case. With a helper like
> this, I'd be able to write most of my template tags without needing to
> drop down into the function/node paradigm. Maybe django does
> eventually need to incorporate one of the third party solutions to
> making template tags nice, but this could be a quick win that would
> address a lot of the pain now.
>
> Or maybe most people don't write lots of add_to_context type tags, or
> the current third-party solutions are sufficient. If it isn't a common
> problem for people, then it definitely doesn't belong in the core.
>
> Thanks,
> Alex

[Preston Timmons]

I'm a fan of this proposal. I find that most of the tags I build
return a variable to the context rather than just rendering a string.
And while a few of the tags I have built require more complexity than
the decorator approach could handle, the majority of them would be
trivial to make if this were in place.

The proposal because it covers a common use case and it fits in with
the pattern that Django already employs for tags rather than trying to
introduce something new. It's also not trying to over-generalize the
problem but make the simple things simple. Creating a tag that takes
one or two arguments, processes them, and returns a value to the
context feels like it should be simple but right now it's not.

For illustration, I'll word the proposal in terms of how it would read
in the Django documentation:

SHORTCUT FOR SIMPLE TAGS
Many template tags take a number of arguments -- strings or a template
variables -- and return a string after doing some processing based
solely on the input argument and some external information.

CONTEXT TAGS
Many template tags take a number of arguments -- strings or a template
variables -- and return a variable to the context after doing some
processing based solely on the input argument and some external
information.

This feels to me like a natural enhancement to the Django template
library.

Preston