Spring MVC define las interfaces ViewResolver y View que le permiten representar modelos en
el navegador sin comprometerlo con una tecnología de presentación específica. ViewResolver proporciona
una asignación entre los nombres de las vistas y las vistas reales. View se ocupa de preparar los datos
antes de pasarlos a una tecnología de presentación específica.
La siguiente tabla proporciona información más detallada sobre la jerarquía ViewResolver:
| VerResolver | Descripción |
|---|---|
|
|
Las subclases
|
|
|
Una implementación simple de la interfaz |
|
|
Una subclase conveniente de |
|
|
Una subclase conveniente de |
|
|
Implementación de la interfaz |
|
|
Una implementación de la interfaz |
Procesamiento
Puede encadenar resolutores de vista declarando más de un bean de resolución y, opcionalmente, configurando la
propiedad order para especificar el orden. Recuerde que cuanto mayor sea la propiedad de orden, más
adelante en la cadena se ubicará el solucionador de vistas.
El ViewResolver especifica que puede devolver nulo para determinar que no se puede encontrar
la vista. Sin embargo, en el caso de JSP y InternalResourceViewResolver, la única manera de saber si el
JSP existe es enviarlo a través de RequestDispatcher. Por lo tanto, siempre debes colocar el InternalResourceViewResolver
en tu configuración en último lugar en el orden general de los solucionadores de vistas.
Configurar la resolución de la vista es tan simple como agregar beans ViewResolver a su configuración de
Spring. MVC Config proporciona una API de configuración especial para solucionadores de vistas y para agregar
controladores de vistas sin algoritmos, que son útiles para representar plantillas HTML sin control de algoritmos.
Reenvío
El prefijo especial redirect: en el nombre de la vista le permite realizar la redirección. UrlBasedViewResolver
(y sus subclases) reconoce esto como un comando para realizar la redirección necesaria. El resto del nombre de la
vista es la URL de redireccionamiento.
El resultado final es el mismo que si el controlador devolviera RedirectView, pero ahora el controlador
mismo puede trabajar con nombres de vistas lógicas. Un nombre de vista lógica (como redirect:/myapp/some/resource)
redirige en relación con el contexto actual del servlet, mientras que un nombre como redirect:https://myhost.com/some/arbitrary/path, redirecciona a una URL absoluta.
Tenga en cuenta que si un método de controlador está anotado con @ResponseStatus, el valor de la
anotación tiene prioridad sobre el estado de respuesta establecido por RedirectView.
Redirección
También puede utilizar el prefijo especial forward: para los nombres de las vistas, que en última
instancia se resuelven mediante UrlBasedViewResolver y las subclases. Esto crea un InternalResourceView
que ejecuta RequestDispatcher.forward(). Por lo tanto, este prefijo no es útil cuando se usa InternalResourceViewResolver
y InternalResourceView (para JSP), pero puede ser útil si está utilizando una tecnología de
presentación diferente pero aún necesita fuerza que el recurso sea redirigido para su procesamiento mediante
servlet/contenedor JSP. Tenga en cuenta que también es posible encadenar varios solucionadores de vistas.
Coordinación de contenidos
ContentNegotiatingViewResolver no resuelve las vistas por sí mismo, sino que
delega este trabajo a otros solucionadores de vistas y obtiene una vista similar a la solicitada por el cliente. La
vista se puede especificar desde el encabezado Aceptar o desde un parámetro de solicitud (por ejemplo,
"/path?format=pdf").
ContentNegotiatingViewResolver selecciona la View adecuada para procesar la solicitud
comparando los tipos de datos de la solicitud con el tipo de datos (también conocido como Content-Type
) soportado por View asociado con cada uno de sus ViewResolvers. La primera
View de la lista que tiene un Content-Type compatible devuelve la vista al cliente. Si la
cadena ViewResolver no proporciona una vista compatible, se utiliza la lista de vistas especificadas en
la propiedad DefaultViews. Esta última opción es adecuada para Views únicas que pueden
representar la vista correspondiente del recurso actual independientemente del nombre de la vista lógica. El
encabezado Aceptar puede contener comodines (por ejemplo, text/*), en este caso
View, cuyo Content-Type es igual a text/xml, es compatible.