Feature Request: provide different data context for included template

[kiddliu]

Problem I'm Trying To Solve

I'd like to pass a variable as the data context of the included template, so a huge template can be split into more modularized sub-templates.

Current Solution

I can only have a huge template with complicated JSON as the only data context.

Requested Solution

It would be very convenient if I could have the following:

#include <string>

#include "data.h"
#include "util.h"

## for namespace in namespaces
    {{ include “namespace-template”:namespace }}
## endfor

in which "namespace-template" refers to the sub-template which handles the namespace only, and :namespace is the provided data context, so don't have to nest loops/conditions in a single template.

[Goutte]

I've found Twig to handle this in a very elegant and idiomatic manner:

Included templates have access to the variables of the active context.
If you are using the filesystem loader, the templates are looked for in the paths defined by it.
You can add additional variables by passing them after the with keyword:

{# template.html will have access to the variables from the current context and the additional ones provided #}
{% include 'template.html' with {'foo': 'bar'} %}

{% set vars = {'foo': 'bar'} %}
{% include 'template.html' with vars %}

You can disable access to the context by appending the only keyword:

{# only the foo variable will be accessible #}
{% include 'template.html' with {'foo': 'bar'} only %}

{# no variables will be accessible #}
{% include 'template.html' only %}

I don't know how doable it is, and it's perhaps best to stay close to Jinja. Just 2 cents, because the with/only pattern is really neat.

[MaxandreOgeret]

Hey @kiddliu & @pantor! How is that completed ? There's no attached PR and nothing in the doc. Please clarify, I believe this should be re-opened.
Indeed, how twig handles that is lovely

[kiddliu]

Hey @MaxandreOgeret, the reason why I closed this ticket is that my job no longer required a solution based on the template engine and from what I learned from the source code, it may require a lot of effort to bring in this context into inja. And eventually I was sticking with my ~300-line template and the performance of inja is bearable in my solution.

I agree with you that this is a nice-to-have feature for inja, so I'm reopening it...