Support broader macro import support, a-la Jinja2

[fairbairn]

We currently build a lot of our platforms using Jinja2, which is the go to number 2 templating platform in Python, second only to Django. They are very, very similar, but Jinja2 has some capabilities that make it a bit more performant.

One area where Jinja2 is different is the way in which macros may be imported. They allow the standard {% import "macrofile" as macro_name %} approach, but they more often use a different syntax similar to {% from "macrofile" import macro_1, macro_1 as mymacro with context %} where with context determines if the original template context data is available within the macro itself (versus only access to local and passed in variables).

We almost always use with context.

In using pongo2 to process a site that has an existing library of Jinja2 templates, I quickly ran into two scenarios that I had to hack around to make it work -

• the syntax in pongo2 did not support (from "thismacrofile" import macro_fn as mymacro with context) and
• Jinja2 doesn't support an export clause on the macro definition, so I had to create a parallel mapping in pongo2 to hold all names of macros for the lookup, not just the "exported" ones.

That worked, and my fork at fairbairn/pongo2 has my interim hack in place, but it needs a lot of work and oversight to insure I used your Token(types) in the correct parsing conditions.

Since Django and Jinja2 are so similar, it makes sense that broader language support could be possible in pongo2, allowing both Django converts and Jinja2 converts to move a number of their existing template code over to your engine without a lot of editing and restructure.

My goal is to have pongo2 completely Jinja2 compatible, even if a "mode" switch of some kind is necessary to allow pongo2 to parse in the Jinja2 dialect.

I would propose that more attention is given to Jinja2 as pongo2 evolves, and in places where there is not a philosophical conflict in functionality, begin to fill in the Jinja2-specific filters and macro-syntax that make it unique.

More about Jinja2's templating capabilities can be found at http://jinja.pocoo.org/docs/dev/templates/

This is clearly an enhancement request, with the first item being to support the broader from "macro" import macro_name syntax out of the box.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[flosch]

Regarding to your macro renaming: The import tag does support renaming macros like this: {% import "myfile.html" my_macro as this_macro, another_macro as this_macro2, third_macro_as_is %}.

I'm afraid I'm not following jinja2's syntax here, but will do support more features as they become neccessary or handy. In the long run I try to establish my own set (and syntax if needed) of template features (like I already do with macros which aren't available in Django). In jinja2, for example, I find two tags for importing macros (from and import) unnecessary. This is why pongo2 only got one import tag which will hopefully be enough.

[flosch]

Re the context: I believe that pongo2's macros are implicitly with context (if I understood jinja2's with context correctly). Have you tried it?