[SPR-15064] Support i18n and nested template loading in ScriptTemplateView render function Created: 28/Dec/16 Updated: 23/Feb/17 Resolved: 25/Jan/17
|Fix Version/s:||5.0 M5|
|Reporter:||Sébastien Deleuze||Assignee:||Sébastien Deleuze|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Days since last comment:||51 weeks ago|
|Last commented by a User:||true|
The render function called by ScriptTemplateView has currently 3 parameters provided:
To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
I see mainly 2 ways to support that:
1) We could be possible leverage setExposeContextBeansAsAttributes() or setExposedContextBeanNames() to access to context beans and expose them via model attributes.
2) We could transform the 3rd parameter passed to the script function (currently String url) to RenderingContext that would contains String url, Locale locale, ResourceBundleMessageSource messageSource and Function<String, String> templateLoader properties. This would be a breaking change for people using `url` but ScriptTemplateView is a rather feature, and url is not widely used, so I consider this as an option in order to be consistent and provide such flexible mechanism for further needs + it provides these properties in a type-safe way which would be valuable for Kotlin JSR-223 support.
|Comment by Yevhenii Melnyk [ 16/Jan/17 ]|
Not sure if the following stuff is appropriate here but I didn't want to open a new issue without discussion. So, the situation is following:
Is there a way to use two scripting engines at the same time or this feature is not supported currently?
|Comment by Sébastien Deleuze [ 17/Jan/17 ]|
|Comment by Yevhenii Melnyk [ 17/Jan/17 ]|
I'll leave the stackoverflow post regarding multiple configurers here in case somebody has a same question I've got. The implementation is really easy. Thank you Sébastien Deleuze.
|Comment by Sébastien Deleuze [ 23/Jan/17 ]|
See also this related pull request for providing i18n support, I will try to provide a solution that fulfill that need too.
|Comment by Sébastien Deleuze [ 24/Jan/17 ]|
This change would be breaking (on the script side, not on java side) for people using the third url parameter that we introduced as part of
As you can see here the migration path is trivial.
I preferred this option over using setExposeContextBeansAsAttributes() or setExposedContextBeanNames() because:
I also choose to provide the ApplicationContext rather than directly the ResourceBundleMessageSource bean because that avoids to make assumption about how to retrieve it (by type, by name) and allows a wide range of use cases in addition to i18n. See it in action in this Kotlin Script example.
|Comment by Sébastien Deleuze [ 25/Jan/17 ]|
Notice that this improvement allow this kind of Kotlin type-safe templates with i18n and nested template support: