Según se describe en la documentación, BeanNameViewResolver
resuelve View
s declarado como frijoles. Por lo general, lo necesita para algunas vistas de propósito especial.
Imagine, por ejemplo, que uno de sus controladores debe generar una hoja de cálculo de Excel. Así, subclase AbstractExcelView
e implementar su lógica personalizada para hacer una hoja de cálculo basado en los valores de modelo:
public class MyExcelView extends AbstractExcelView { ... }
y la declara como un grano:
<bean id = "myExcelView" class = "MyExcelView" />
Entonces declarar una BeanNameViewResolver
lo hace disponible a los controladores: cuando el controlador devuelva ModelAndView
con el nombre de vista myExcelView
, se procesará la hoja de cálculo.
BeanNameViewResolver
se utiliza generalmente en conjunción con algún otro punto de vista que se encarga de resolver vistas "normales" (por lo que si BeanNameViewResolver
no puede encontrar un punto de vista, la otra de resolución trata de encontrar):
<bean class = "...BeanNameViewResolver">
<property name = "order" value = "0" />
</bean>
<bean class = "...InternalResourceViewResolver">
<property name = "order" value = "1" />
...
</bean>
+1 por ser más rápido que yo y tener algunos detalles que mi blob no tiene :) –
+1 para una buena explicación. Un par de preguntas: 1) ¿beannameviewresolver necesita ser seguro para subprocesos? 2) ¿es internoresourceviewresolver thread-safe? – shrini1000
muy buena explicación – Krishna