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.j.robb...@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
>
>
> On Thu, Jul 22, 2010 at 10:23 AM, Eric Holscher <e...@ericholscher.com> wrote:
>> 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
>>
>> On Thu, Jul 22, 2010 at 9:26 AM, Alex Robbins
>> <alexander.j.robb...@gmail.com> wrote:
>>>
>>> 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
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To post to this group, send email to django-develop...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-developers+unsubscr...@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
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
