Possible change to have dynamic fragments instead of only fixed aliases in include expression

[agrahl]

Possible change to have dynamic fragments instead of only fixed aliases in include expression

[erdos]

Hi @agrahl , thanks for opening the issue. About the fragments:

why it is not possible to use the "include" expression with a dynamic value

When a template is prepared, a user of Stencil may need to be able to list the names of all the fragments the template requires. Think of it like enumerating the "dependencies" of a template so we could tell in advance if all the dependencies are available before actually rendering the template. See: preparedTemplate.getVariables().getAllFragmentNames(). If the template names can be dynamic values, there would be no way of enumerating all the possible values.

And it would make the templates more readable, because else you need to have a long list of "if" expressions.

This is a fair point. Perhaps we could be more permissive with the {% include directives and also allow dynamic expressions, and getAllFragmentNames() would return only the string values. I will check back on this issue around middle of this week to see what it would require to implement this functionality.

I also played around with the html function, but here it is not enough. The supports of formatting options is very small.

Please feel free to open a separate Issue with feedback on what you were missing.

[agrahl]

Hi @erdos ,

thanks for the fast reply. Perhaps instead of an entry of PreparedFragment in the Fragments-Map, we could register a PreparedFragmentFunction which allows to select a fragment on basis of parameters (similar to the Function interface). It would then return a concrete PreparedFragment.getImpl() as return object that can be handled as usually.

{%=include myfragment(....)%}

=> dynamic select a fragment

{%=include "myfragment"%}

=> static select a fragment

Perhaps the change would be very small if we could use the Provided Function interface directly for this. The implemented Function would then internally directly return the value from the selected PreparedFragment.getImpl().

public interface PreparedFragmentFunction { ... Object call(Object... arguments) throws IllegalArgumentException; ... }

And a concrete implementation could look like this.

public Object call(Object... arguments) throws IllegalArgumentException { return this.myFragments.getOrDefault(arguments[0], defaultFragment).getImpl(); }

Of course here also more logic is possible, there is no limit here :-)

The function PreparedTemplate.getVariables().getAllFragmentNames() would return in that case also only the name of the used function in the list (the name of the outer function, so when as parameters also functions are used that does not matter).

These are only first ideas. As I said I have not so much understanding of the underlaying Closure implementation. So I have difficulties to have a feeling on the impact of the Closure implementation.

Regards

Alexander

[erdostw]

Change was released in v0.5.7, closing issue.

[agrahl]

Hello @erdostw,

thanks for the change. Do I understand it correctly, that we still need to load all fragments in the fragment map and give that to the API.render(...) method.

After this we can set the fragment to load via {%=include expression%} the expression must evaluate to a String that is the name of a fragment contained in the fragment map.

Is that correct, or can the expression also evaluate to a PreparedFragment object?

Regards

Alexander

[erdostw]

Hey @agrahl , for now, the dynamic fragment only works if the expression evaluates to a String which is the name of the fragment.

The reason behind this idecision that preparing templates/fragments has a visible cost of unpacking and analysing the template file. The templates/fragments also have to be cleaned up after last usage because they use space in the temp directory. Therefore, it is advised to precompute and cache fragments in advance before rendering.

[agrahl]

Hi @erdostw,

that with the parsing and preparing the fragments is clear. Also the clean up, if we shutdown the application or redeploy the templates. That is also why I asked, if we could have here something that also allows to return a PreparedFragment object. That would make it easier to just prepare the stuff that is needed in the template. You could imagine this like a data driven selection of segments in a template. Each segment is a PreparedFragment. Depending on the input data and the template that uses it for rendering, it will select different segments (PreparedFragments) to be included. Because it depends on the input data, I would avoid to make a data analysis before the rendering via the template is called. This would split up the implementation of a template and would make it more difficult to maintain.

You also made the change with the temporary directory (thanks for this too), it is now easy to find all resources that belong to an application or even a running deployment of templates. So I would not have fear, that we would run here into problems.

Regards

Alexander