Tecnologías de presentación

Hoja de tomillo

Thymeleaf es un moderno motor de plantillas Java del lado del servidor que enfatiza las plantillas HTML naturales que se pueden obtener una vista previa en el navegador con un doble clic, lo cual es muy útil cuando usted mismo trabaja en plantillas de interfaz de usuario (por ejemplo, diseñador) sin la necesidad de un servidor en funcionamiento. Thymeleaf ofrece un amplio conjunto de funciones y se desarrolla y mantiene activamente. Puede encontrar información introductoria más completa en la página de inicio del proyecto Thymeleaf.

Integración de Thymeleaf con Spring WebFlux está gestionado por el proyecto Thymeleaf. La configuración proporciona varias declaraciones de beans como SpringResourceTemplateResolver, SpringWebFluxTemplateEngine y ThymeleafReactiveViewResolver. Para obtener más información, consulte "Thymeleaf+Spring" y anuncio integración con WebFlux .

FreeMarker

Apache FreeMarker es un motor de plantillas para generar cualquier tipo de salida de texto desde HTML a correo electrónico y más. Spring Framework tiene integración incorporada para usar Spring WebFlux con plantillas de FreeMarker.

Ver configuración

El siguiente ejemplo muestra cómo puedes configurar FreeMarker como tecnología de presentación:

@Configuration
@EnableWebFlux
public class WebConfig implements WebFluxConfigurer {
@Override
public void configureViewResolvers(ViewResolverRegistry registry) {
registry.freeMarker();
}
// Configurar FreeMarker...
@Bean
public FreeMarkerConfigurer freeMarkerConfigurer() {
FreeMarkerConfigurer configurer = new FreeMarkerConfigurer();
configurer.setTemplateLoaderPath("classpath:/templates/freemarker");
return configurer;
}
}

@Configuration
@EnableWebFlux
class WebConfig : WebFluxConfigurer {
override fun configureViewResolvers(registry: ViewResolverRegistry) {
registry.freeMarker()
}
// Configurar FreeMarker...
@Bean
fun freeMarkerConfigurer() = FreeMarkerConfigurer().apply {
setTemplateLoaderPath("classpath:/templates/freemarker")
}
}

Sus plantillas deben almacenarse en el directorio especificado por FreeMarkerConfigurer, como se muestra en el ejemplo anterior. . Dada la configuración anterior, si el controlador devuelve el nombre de la vista welcome, el solucionador busca la plantilla classpath:/templates/freemarker/welcome.ftl.

Configuración de FreeMarker

Es posible pasar la "Configuración" y la "Variable compartida" del controlador FreeMarker directamente al objeto Configuration del controlador FreeMarker (que es administrado por Spring) estableciendo el propiedades de bean apropiadas en FreeMarkerConfigurer. La propiedad freemarkerSettings requiere un objeto java.util.Properties y la propiedad freemarkerVariables requiere un objeto java.util.Map objeto. El siguiente ejemplo muestra cómo utilizar FreeMarkerConfigurer:

@Configuration
@EnableWebFlux
public class WebConfig implements WebFluxConfigurer {
// ...
@Bean
public FreeMarkerConfigurer freeMarkerConfigurer() {
Map<String, Object> variables = new HashMap<>();
variables.put("xml_escape", new XmlEscape());
FreeMarkerConfigurer configurer = new FreeMarkerConfigurer();
configurer.setTemplateLoaderPath("classpath:/templates");
configurer.setFreemarkerVariables(variables);
return configurer;
}
}
    

@Configuration
@EnableWebFlux
class WebConfig : WebFluxConfigurer {
// ...
@Bean
fun freeMarkerConfigurer() = FreeMarkerConfigurer().apply {
setTemplateLoaderPath("classpath:/templates")
setFreemarkerVariables(mapOf("xml_escape" to XmlEscape()))
}
}

Detalles Para conocer las configuraciones y variables que se aplican al objeto Configuration, consulte la documentación de FreeMarker.

Manejo de formularios

Spring proporciona una biblioteca de etiquetas para usar en JSP que contiene , entre otras cosas, el elemento <spring:bind/>. Este elemento permite principalmente que los formularios muestren valores de objetos de formulario subyacentes y muestren los resultados de validaciones fallidas de un Validator en el nivel web o empresarial. Spring también admite la misma funcionalidad en FreeMarker, con macros convenientes adicionales para generar los propios elementos de entrada del formulario.

Macros de enlace

El soporte para el conjunto estándar de macros está en el spring-webflux.jar para FreeMarker, por lo que siempre están disponibles para una aplicación configurada adecuadamente.

Algunas macros definidas en las bibliotecas de plantillas Spring se consideran internas (privadas), pero no existe tal restricción en las definiciones de macros, lo que hace que todas las macros sean visibles para el código de llamada y las plantillas de usuario. Las siguientes secciones cubren sólo aquellas macros que deben llamarse directamente desde las plantillas. Si necesita ver el código de la macro directamente, el archivo se llama spring.ftl y se encuentra en el paquete org.springframework.web.reactive.result.view.freemarker .

Macros de formulario

Para obtener información detallada sobre la compatibilidad con macros de formulario para plantillas de FreeMarker en Spring, consulte las siguientes secciones de la documentación de Spring MVC.

• Macros de entrada

• Campos de entrada

• Campos de selección

• Escapado HTML

Vistas de secuencias de comandos

Spring Framework tiene integración incorporada para usar Spring WebFlux con cualquier biblioteca de plantillas que pueda ejecutarse sobre la especificación motor de secuencias de comandos JSR-223 en Java. La siguiente tabla muestra las bibliotecas de plantillas que probamos en varios motores de ejecución de scripts:

Requisitos

Debe proporcionar un motor de secuencias de comandos en su classpath, cuyos detalles dependen del motor de secuencias de comandos:

• Un motor de procesamiento de JavaScript llamado Nashorn se envía con Java 8+. Se recomienda encarecidamente que utilice la última versión de actualización disponible.

• JRuby requiere agregar como dependencia para brindar soporte para el lenguaje Ruby.

• Jython debe agregarse como una dependencia para brindar soporte para el lenguaje Python.

• Para brindar soporte para los scripts de Kotlin, la dependencia se debe agregar org.jetbrains.kotlin:kotlin-script-util y un archivo META-INF/services/javax.script.ScriptEngineFactory que contenga la línea org.jetbrains.kotlin.script .jsr223.KotlinJsr223JvmLocalScriptEngineFactory. Para obtener más información, consulte este ejemplo.

Necesita agregar una biblioteca de plantillas de script. Una forma de hacer esto en el caso de JavaScript es WebJars.

Plantillas de script

Puede declarar un bean ScriptTemplateConfigurer para especificar qué motor de script usar, qué archivos de script cargar, qué función llamar para representar plantillas, etc. El siguiente ejemplo utiliza plantillas de Moustache y un motor JavaScript llamado Nashorn:

@Configuration
@EnableWebFlux
public class WebConfig implements WebFluxConfigurer {
@Override
public void configureViewResolvers(ViewResolverRegistry registry) {
registry.scriptTemplate();
}
@Bean
public ScriptTemplateConfigurer configurer() {
ScriptTemplateConfigurer configurer = new ScriptTemplateConfigurer();
configurer.setEngineName("nashorn");
configurer.setScripts("mustache.js");
configurer.setRenderObject("Mustache");
configurer.setRenderFunction("render");
return configurer;
}
}

@Configuration
@EnableWebFlux
class WebConfig : WebFluxConfigurer {
override fun configureViewResolvers(registry: ViewResolverRegistry) {
registry.scriptTemplate()
}
@Bean
fun configurer() = ScriptTemplateConfigurer().apply {
engineName = "nashorn"
setScripts("mustache.js")
renderObject = "Mustache"
renderFunction = "render"
}
}

La función render se llama con los siguientes parámetros:

• String template: Contenido de la plantilla

• Map model: Ver modelo

• RenderingContext renderContext: RenderingContext, que proporciona acceso al contexto de la aplicación, la configuración regional, el cargador de plantillas y la URL (desde la versión 5.0).

Mustache.render() es compatible de forma nativa con esta firma, por lo que puede llamarla directamente.

Si su tecnología de plantillas requiere cierta personalización, puede pasar un script que implementa una función de renderizado personalizada. Por ejemplo, Handlerbars requiere que las plantillas se compilen antes de usarlas y requiere polyfill para emular algunas capacidades del navegador que no están disponibles en el motor de secuencias de comandos del lado del servidor. El siguiente ejemplo muestra cómo configurar una función de representación personalizada:

@Configuration
@EnableWebFlux
public class WebConfig implements WebFluxConfigurer {
@Override
public void configureViewResolvers(ViewResolverRegistry registry) {
registry.scriptTemplate();
}
@Bean
public ScriptTemplateConfigurer configurer() {
ScriptTemplateConfigurer configurer = new ScriptTemplateConfigurer();
configurer.setEngineName("nashorn");
configurer.setScripts("polyfill.js", "handlebars.js", "render.js");
configurer.setRenderFunction("render");
configurer.setSharedEngine(false);
return configurer;
}
}

@Configuration
@EnableWebFlux
class WebConfig : WebFluxConfigurer {
override fun configureViewResolvers(registry: ViewResolverRegistry) {
registry.scriptTemplate()
}
@Bean
fun configurer() = ScriptTemplateConfigurer().apply {
engineName = "nashorn"
setScripts("polyfill.js", "handlebars.js", "render.js")
renderFunction = "render"
isSharedEngine = false
}
}

polyfill.js solo define el objeto de ventana que manillar necesita para funcionar correctamente, como se muestra en el siguiente fragmento:

var window = {};

Este es un La implementación básica de render.jscompila la plantilla antes de usarla. Una implementación lista para producción también debe almacenar cualquier plantilla en caché reutilizable o plantilla precompilada. Esto se puede hacer en el lado del script, así como con cualquier configuración que necesite (por ejemplo, administrar la configuración del motor de plantillas). El siguiente ejemplo muestra cómo compilar la plantilla:

 
function render(template, model) {
var compiledTemplate = Handlebars.compile(template);
return compiledTemplate(model);
}

Consulte las pruebas unitarias de Spring Framework, Java y recursosto ver más ejemplos de configuración.

JSON y XML

Por razones de coherencia del contenido, es útil poder alternar entre mostrar un modelo con una plantilla en HTML u otros formatos (como JSON o XML), en función del tipo de contenido solicitado por el cliente. Para admitir esta función, Spring WebFlux proporciona un HttpMessageWriterView, que se puede utilizar para conectar cualquiera de los códecs disponibles desde Spring-web, como Jackson2JsonEncoder, Jackson2SmileEncoder o Jaxb2XmlEncoder.

A diferencia de otros tecnologías de presentación, HttpMessageWriterView no requiere ViewResolver, pero está configurado como la vista predeterminada. Puede configurar una o más de estas vistas predeterminadas para ajustarlas a diferentes instancias HttpMessageWriter o instancias Encoder. En tiempo de ejecución, se utiliza el que coincide con el tipo de contenido solicitado.

En la mayoría de los casos, un modelo contiene múltiples atributos. Para determinar cuál serializar, puede configurar HttpMessageWriterView con el nombre del atributo del modelo que desea usar para la representación. Si el modelo contiene solo un atributo, entonces se usará ese.