Jinja2 Focused Branch

[Carlos Daniel Ruvalcaba Valenzuela]

Following the suggestion by Michael Pedersen, I forked the development
branch to add some jinja2 focused changes, if anyone want to check it
out or fork/pull my stuff:

https://github.com/clsdaniel/tg2-jinja2-updates
git://github.com/clsdaniel/tg2-jinja2-updates.git

I'm just starting with the patches, but if there is comments or
feature requests (related to jinja2 support) drop me a mail or and
issue on github.

So far I just added support for loading extensions and simple filters
along with test cases (which also pass), I'll be adding more as I have
time (or need), I try to follow upstream repository on sourceforge
too.

Regards,
Carlos Ruvalcaba

[Alessandro Molina]

Great work Carlos,

I took a look at the patch and it seems fine, the only thing that I would like to point is that being it a patch that adds a feature it really requires documentation.

I think that the two new options for jinja should be added to http://www.turbogears.org/2.1/docs/main/Templates/Jinja.html and I would like to avoid merging in patches that do not have relative documentation if they introduce new features or behavioral changes. We already have doc problems without having to introduce new missing pieces ;)

If you can provide the doc for the two new configuration options for me it's a +1 for merge-in

Posting discussion to tg-trunk as it is more related to development.

[Carlos Daniel Ruvalcaba Valenzuela]

Thanks for all your comments, currently I'm focusing on adding custom
extensions and filter support to Jinja2 renderer, I would like to hear
a few opinions on this feature:

Should we have a special place where you can code custom filters and
extensions and have it loaded automatically if the Jinja2 renderer is
chosen (like django extensions/filters)?

If so, where would be the best place to put this? on lib?, maybe I can
make the loader look up at lib for extensions.py and filters.py, or
have a special directory for them?, currently django has a directory
called templatetags for this, we could have one in lib/

This special folder would not come with the main turbogears paster
template (it doesn't come with default django setup either), the user
would have to create it and add its files, the jinja2 renderer would
look it up and if available load it, otherwise load the given filters
and extensions from config, we could even have a config option to
disable auto_loading.

I also forked the tg2docs from Michael on github, but would like to
nail this first before updating the docs.

Regards,
Carlos Ruvalcaba

PD: Posting this to main turbogears list to poll users.

[Alessandro Molina]

One more thing,

the test case is currently testing for the autoescape extension, but there is no test case for filters.

I think that it can be quickly achieved by adding a simple filter and registering it in a test unit.

[Carlos Daniel Ruvalcaba Valenzuela]

On Thu, Jun 30, 2011 at 8:42 AM, Alessandro Molina
<alessand...@gmail.com> wrote:
> One more thing,
> the test case is currently testing for the autoescape extension, but there
> is no test case for filters.
> I think that it can be quickly achieved by adding a simple filter and
> registering it in a test unit.

Done

> I think that for extenions they are better managed in the configuration
> file.
> Filters, instead, might be a good candidate for being included in the
> project and automatically loaded as I see them more related to helpers.
> If we really want to do this we might consider creating a lib.something
> module and handle all the template related extensions and functions there.
> So that we will have lib.something.helpers, lib.something.jinja_filters,
> lib.something.whatever and people know that for any template filter, helper
> etc they can look there.
> I just don't have any idea on how "lib.something" should be called, but I
> think that it is better than putting everything in lib alone which might
> bring us to have lib.this, lib.that, lib.future_idea caos.

I don't really see people creating many custom extensions for each
project, filters are more common.

The thing is that helpers are loaded to the template context, be it
variables, data or functions, filters in the other hand are functions
too, they have a very specific function and way of working, in the end
they more of a syntaxis thing for the template, they are functions
that will always accept at least 1 value and do something and return a
value, thus they have some overlap with helper functions.

Maybe we could have a lib.templates?, thus we would end up with
lib.templates.helpers and lib.templates.jinja_filters.

Regards,
Carlos Ruvalcaba