Ambient context, a.k.a. helpers

[jgonggrijp]

Lambdas are provided to a template together with other input data. This approach is flexible and generally works well. However, it is easy to imagine that one might want to use a particular lambda in every template in a large application, for example one that interfaces with an i18n framework. It would be convenient if such a lambda could be registered in a central place to make it automatically available in every template. In Handlebars parlance, such a lambda would be referred to as a helper.

This central place does not need to restricted to lambdas. I can also imagine something like an itemize filter residing there (see #153), as well as frequenly used constants. As such, this central place is made of roughly the same substance as any context frame. Indeed, one could think of it as a context frame that is automatically inserted below the root context for every template that is rendered. Hence: ambient context.

I suggest placing the ambient context below the root context, so that template users can still locally override helpers if there is a need to do so.

How to register a helper in the ambient context is implementation-defined. Implementations might ship with a small library of ready-to-use helpers, but I think actually adding those to the context should be opt-in.

[spullara]

In my implementation you can pass in a starting stack of context objects so this doesn't really affect mustache.java. I have used this strategy in a lot of places including for things like i18n. I'm not sure though how this would affect the specification though? It seems like any implementation could have an initialization path that affords this functionality.

[jgonggrijp]

Now that you mention it, I am not sure it needs to be in the spec, either.

Still potentially useful to have a central place to discuss the idea, though.

[agentgt]

I think the only reason why I might want to spec it is if we allow the last key of a dotted notation to do a search.

That is because even if you add global helpers you have to do:

{{#deepInTheStack}}
{{#lambdaOnStartingStack}}
{{/lambdaOnStartingStack}}
{{/deepInTheStack}}

I made it in JStachio legal to do:

{{#deepInTheStack.lambdaOnStartingStack}}

{{/deepInTheStack.lambdaOnStartingStack}}

The above is not legal because the last key needs to be hanging off deepInTheStack.

Most of that was by accident supporting some level of Map<String,String> getting passed a parameter but it turned out to be a liked feature.

I'm in agreement that it might not need to be spec'ed particularly if power filters get I guess "searching" behavior (ie go up the stack look for key for filter).

[jgonggrijp]

I think you are discussing two different ideas at the same time. In the case of JStachio, they are related, but in the general case, they could exist independently from each other:

1. Make it possible to have a particular lambda always available to you, even if you didn't pass it as input to the template. This is what I mean to refer to with "ambient context".
2. Allow {{#value.lambda}} to work, with lambda being able to access value, even if lambda is not a member of value. This idea still needs a catchy name.

Side note: filters would allow you to get the same effect with {{#value | lambda}}.

Getting (1) in the spec would not automatically get (2) in the spec, as I see it. That said, please feel free to create a dedicated discussion for (2)!

[bobthecow]

Mustache.php has done this since forever. I think of it as an implementation detail of the engine, not really something that would belong in the template language spec. Though it might make sense to have a collection of "probably makes sense to implement things this way" somewhere?

[jgonggrijp]

Yes maybe that would make sense. A kind of "soft recommendations" list. That might be worth a separate discussion.

@spullara agrees with you that the ambient context feature need not be in the spec. I think I agree, too. #156 (comment)