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:
Biblioteca de scripts | Motor de ejecución de scripts |
---|---|
ScriptEngine
y Invocable
.
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 archivoMETA-INF/services/javax.script.ScriptEngineFactory
que contenga la líneaorg.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 plantillaMap model
: Ver modeloRenderingContext 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
}
}
sharedEngine
en false
es necesario cuando se utilizan motores de secuencias de comandos no seguros para subprocesos con bibliotecas de
plantillas que no están diseñadas para la concurrencia, como Manillar o React corriendo en Nashorn. En este
caso, se requiere la actualización 60 de Java SE 8 debido a este error, pero
generalmente se recomienda utilizar la última versión del parche Java SE de todos modos.
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.js
compila 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.