Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-15064

Support i18n and nested template loading in ScriptTemplateView render function

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 5.0 M5
    • Component/s: Web
    • Labels:
    • Last commented by a User:
      true

      Description

      The render function called by ScriptTemplateView has currently 3 parameters provided:

      • String template: the content of the template resource
      • Map<String, Object>: the model to use to render the view
      • String url: the url of the 2 view

      To achieve i18n support for messages and nested template loading, we need to provide these additional informations:

      • a ResourceBundleMessageSource instance (or the ApplicationContext that allows to retrieve it)
      • the view Locale
      • a Function<String, String> that allows the render function to call ScriptTemplateView#getTemplate(String)

      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.

        Issue Links

          Activity

          sdeleuze Sébastien Deleuze created issue -
          sdeleuze Sébastien Deleuze made changes -
          Field Original Value New Value
          Status Open [ 1 ] In Progress [ 3 ]
          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          This is not enough to provide full support for nested templates or i18n message sources. To achieve such support, 2 more parameters are needed:
           - {{ApplicationContext applicationContext}}
           - {{Locale locale}}

          Notice that some script technology like Nashorn accept the implementer to declare only a subset of the arguments we are calling, while some others like Jython require all parameters to be provided.

          Since {{ScriptTemplateView}} is not widely used yet, I suggest changing the third parameter from {{String url}} to {{ScriptContext context}} to improve extensibility and avoid a very long render method signature. {{ScriptContext}} would contain 3 properties (url, applicationContext, locale) and will enable future addition without breaking {{render()}} function signature.





          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          This is not enough to provide full support for nested templates or i18n message sources. To achieve such support, more parameters are needed:
           - {{ApplicationContext applicationContext}}
           - {{Locale locale}}
           - {{String prefix}}
           - {{String suffix}}
           - {{ScriptEngine engine}}

          Notice that some script technology like Nashorn accept the implementer to declare only a subset of the arguments we are calling, while some others like Jython require all parameters to be provided.

          Since {{ScriptTemplateView}} is not widely used yet, I suggest changing the third parameter from {{String url}} to {{ScriptTemplateContext context}} to improve extensibility and avoid a very long render method signature. {{ScriptContext}} would contain 6 properties (url, applicationContext, locale, prefix, suffix, engine) and will enable future addition without breaking {{render()}} function signature.




          sdeleuze Sébastien Deleuze made changes -
          Summary Allow passing ApplicationContext and Locale to ScriptTemplateView render function Allow passing ApplicationContext, Locale and more to ScriptTemplateView render function
          sdeleuze Sébastien Deleuze made changes -
          Summary Allow passing ApplicationContext, Locale and more to ScriptTemplateView render function Allow passing ApplicationContext and ScriptEngine to ScriptTemplateView render function
          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          This is not enough to provide full support for nested templates or i18n message sources. To achieve such support, more parameters are needed:
           - {{ApplicationContext applicationContext}}
           - {{Locale locale}}
           - {{String prefix}}
           - {{String suffix}}
           - {{ScriptEngine engine}}

          Notice that some script technology like Nashorn accept the implementer to declare only a subset of the arguments we are calling, while some others like Jython require all parameters to be provided.

          Since {{ScriptTemplateView}} is not widely used yet, I suggest changing the third parameter from {{String url}} to {{ScriptTemplateContext context}} to improve extensibility and avoid a very long render method signature. {{ScriptContext}} would contain 6 properties (url, applicationContext, locale, prefix, suffix, engine) and will enable future addition without breaking {{render()}} function signature.




          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          This is not enough to provide full support for nested templates or i18n message sources. To achieve such support, more parameters are needed:
           - {{ApplicationContext applicationContext}}
           - {{ScriptEngine engine}}

          Notice that some script technology like Nashorn accept the implementer to declare only a subset of the arguments we are calling, while some others like Jython require all parameters to be provided.

          Since {{ScriptTemplateView}} is not widely used yet, I suggest changing the third parameter from {{String url}} to {{ScriptTemplateContext context}} to improve extensibility and avoid a very long render method signature. {{ScriptContext}} would contain 3 properties (url, applicationContext, engine) and will enable future addition without breaking {{render()}} function signature.




          sdeleuze Sébastien Deleuze made changes -
          Summary Allow passing ApplicationContext and ScriptEngine to ScriptTemplateView render function Allow passing Locale, ScriptEngine and template loader to ScriptTemplateView render function
          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          This is not enough to provide full support for nested templates or i18n message sources. To achieve such support, more parameters are needed:
           - {{ApplicationContext applicationContext}}
           - {{ScriptEngine engine}}

          Notice that some script technology like Nashorn accept the implementer to declare only a subset of the arguments we are calling, while some others like Jython require all parameters to be provided.

          Since {{ScriptTemplateView}} is not widely used yet, I suggest changing the third parameter from {{String url}} to {{ScriptTemplateContext context}} to improve extensibility and avoid a very long render method signature. {{ScriptContext}} would contain 3 properties (url, applicationContext, engine) and will enable future addition without breaking {{render()}} function signature.




          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          By leveraging {{AbstractView}} attributes, we should allow the render function to have access to the following attributes in order to support nested templates or i18n:
           - {{ScriptEngine engine}}
           - {{Locale locale}}
           - {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          It should be possible to leverage {{setExposeContextBeansAsAttributes()}} or {{setExposedContextBeanNames()}} to access to context beans (to be verified in an integration test).




          sdeleuze Sébastien Deleuze made changes -
          Labels kotlin
          sdeleuze Sébastien Deleuze made changes -
          Link This issue depends on SPR-15059 [ SPR-15059 ]
          sdeleuze Sébastien Deleuze made changes -
          Summary Allow passing Locale, ScriptEngine and template loader to ScriptTemplateView render function Allow passing Locale and template loader to ScriptTemplateView render function
          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          By leveraging {{AbstractView}} attributes, we should allow the render function to have access to the following attributes in order to support nested templates or i18n:
           - {{ScriptEngine engine}}
           - {{Locale locale}}
           - {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          It should be possible to leverage {{setExposeContextBeansAsAttributes()}} or {{setExposedContextBeanNames()}} to access to context beans (to be verified in an integration test).




          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          By leveraging {{AbstractView}} attributes, we should allow the render function to have access to the following attributes in order to support nested templates or i18n:
           - {{Locale locale}}
           - {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          It should be possible to leverage {{setExposeContextBeansAsAttributes()}} or {{setExposedContextBeanNames()}} to access to context beans (to be verified in an integration test).




          sdeleuze Sébastien Deleuze made changes -
          Summary Allow passing Locale and template loader to ScriptTemplateView render function Support i18n and nested template loading in ScriptTemplateView render function
          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          By leveraging {{AbstractView}} attributes, we should allow the render function to have access to the following attributes in order to support nested templates or i18n:
           - {{Locale locale}}
           - {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          It should be possible to leverage {{setExposeContextBeansAsAttributes()}} or {{setExposedContextBeanNames()}} to access to context beans (to be verified in an integration test).




          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
           - a {{ResourceBundleMessageSource}} instance (or the {{ApplicationContext}} that allows to retrieve it)
           - the view {{Locale}}
           - a {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          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
          It could maybe leverage {{AbstractView}} attributes, we should allow the render function to have access to the following attributes in order to support nested templates or i18n:





          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
           - a {{ResourceBundleMessageSource}} instance (or the {{ApplicationContext}} that allows to retrieve it)
           - the view {{Locale}}
           - a {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          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
          It could maybe leverage {{AbstractView}} attributes, we should allow the render function to have access to the following attributes in order to support nested templates or i18n:





          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
           - a {{ResourceBundleMessageSource}} instance (or the {{ApplicationContext}} that allows to retrieve it)
           - the view {{Locale}}
           - a {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          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 {{ScriptTemplateContext}} 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.
           




          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
           - a {{ResourceBundleMessageSource}} instance (or the {{ApplicationContext}} that allows to retrieve it)
           - the view {{Locale}}
           - a {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          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 {{ScriptTemplateContext}} 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.
           




          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
           - a {{ResourceBundleMessageSource}} instance (or the {{ApplicationContext}} that allows to retrieve it)
           - the view {{Locale}}
           - a {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          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.
           




          sdeleuze Sébastien Deleuze made changes -
          Description The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
           - a {{ResourceBundleMessageSource}} instance (or the {{ApplicationContext}} that allows to retrieve it)
           - the view {{Locale}}
           - a {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          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.
           




          The render function called by {{ScriptTemplateView}} has currently 3 parameters provided:
           - {{String template}}: the content of the template resource
           - {{Map<String, Object>}}: the model to use to render the view
           - {{String url}}: the url of the 2 view

          To achieve i18n support for messages and nested template loading, we need to provide these additional informations:
           - a {{ResourceBundleMessageSource}} instance (or the {{ApplicationContext}} that allows to retrieve it)
           - the view {{Locale}}
           - a {{Function<String, String>}} that allows the render function to call {{ScriptTemplateView#getTemplate(String)}}

          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.
           




          sdeleuze Sébastien Deleuze made changes -
          Link This issue relates to SPR-13453 [ SPR-13453 ]
          sdeleuze Sébastien Deleuze made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Complete [ 8 ]
          snicoll Stéphane Nicoll made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              sdeleuze Sébastien Deleuze
              Reporter:
              sdeleuze Sébastien Deleuze
              Last updater:
              Stéphane Nicoll
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                42 weeks, 4 days ago