Currently, the documentation section regarding contexts seems to be left incomplete:
https://scriggo.com/templates/specification#contexts
We should evaluate:
- Extending this documentation at the specification level, clearly explaining what contexts are, how they change, how they intervene in rendering, etc.
- Providing higher-level documentation to explain how to handle various cases. See the example case below.
Example Case
Consider this case:
In an HTML page, you want to render JavaScript code within a <script>...</script> block that, for various reasons, has an HTML context instead of JavaScript.
Rendering the JavaScript code directly results in it being escaped as HTML, so it does not work.
It becomes necessary to use a "using" statement, which assigns a block of JavaScript code to the variable itea, and then render the variable itea by first converting it to a string type (using explicit conversion string(...)), and subsequently calling some "unsafe" function provided in the template to change the variable type from JavaScript (now a string) to HTML, ensuring that no escaping operation is performed.
I am not sure if there are other solutions to handle a similar case, but this solution requires a certain level of study and knowledge of Scriggo to be conceived and implemented in the template.
It would therefore be interesting to document these scenarios.
Currently, the documentation section regarding contexts seems to be left incomplete:
https://scriggo.com/templates/specification#contexts
We should evaluate:
Example Case
Consider this case:
In an HTML page, you want to render JavaScript code within a
<script>...</script>block that, for various reasons, has an HTML context instead of JavaScript.Rendering the JavaScript code directly results in it being escaped as HTML, so it does not work.
It becomes necessary to use a "using" statement, which assigns a block of JavaScript code to the variable
itea, and then render the variableiteaby first converting it to a string type (using explicit conversionstring(...)), and subsequently calling some "unsafe" function provided in the template to change the variable type from JavaScript (now a string) to HTML, ensuring that no escaping operation is performed.I am not sure if there are other solutions to handle a similar case, but this solution requires a certain level of study and knowledge of Scriggo to be conceived and implemented in the template.
It would therefore be interesting to document these scenarios.