![[ Puerto Cero Uno ]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiXs7hWiiK0_ETMqSqjEYdPtKVGAtAw_S16cM3u-3t1kwYIw-FM1aSQeOkrlr9lmqom-9Kw9kz0ZoPNXfpYGC_CIbLwn20L7Ps3leRsUpjPp63xioaYTeMLJsI-2JnRc8mWwH76Jbhn-jx/s752/puertocerounobanner.jpg)
Introducción
La especificación JSR-168
Para mayor información en el API portlet, se recomienda revisar la documentación de Oracle "Introduction to JSR 168", y la propia especificación JSR-168 Specification.
Además de ofrecer soporte al desarrollo Web convencional basado en servlets, Spring ofrece la posibilidad de integrar el desarrollo de Portlets (JSR-168). En la medida de lo posible (como veremos), el framework Spring MVC Portlet es una imagen de Spring MVC (link to), y utiliza la misma capa de Abstracción e Integración Spring. Por ello es conveniente realizar un repaso a Spring Web MVC framework y View technologies antes de continuar con la documentación.
Tengamos en cuenta que aunque ambos frameworks provengan de las mísmas abstracciones, existen varias funcionalidades, como el workflow que ofrece JSR-168, que conviene tener en cuenta.
La principal diferencia entre el workflow que siguen los servlets es que una petición en un portlet tiene dos fases diferenciadas: la fase action y la fase de render. La fase action se ejecuta una sola vez y en ella es en la que cualquier cambio del modelo u otras acciones encadenadas suceden. La fase de render genera lo que debe ser mostrado al usuario (vista) cada a cada vez que se realiza un refresh. El punto crucial aqui es que, desde el punto de vista de una simple request, la fase "action" se ejecuta sólo una vez, mientras que la fase "render" puede ejecutarse varias veces. Esta caracteristica implica tener en cuenta la separación de cada una de las fases: por un lado la comunicación con el modelo, por otro la generación de la vista.
La dos fases de la request portlet es el punto fuerte de la especificación JSR-168. Supongamos el siguiente ejemplo, los resultados de una búsqueda pueden actualizarse de forma dinámica, sin que por ello el usuario tenga que lanzar de nuevo la petición. Como funcionalidad extra Spring Portlet, al contrario que otros frameworks que adaptan a una funcionalidad semejante lo más parecida al funcionamiento de los servlet, nos permite implementar ambas fasesde la especificación - para así ofrecer toda la potencia del uso de portlets. Spring MVC Portlet Framework, ofrece dos métodos que manejan la request: el primero para la fase "action", el segundo para la fase "render". Un ejemplo, para la versión servlet tenemos AbstractController con el método handleRequestInternal(..), la versión portlet de AbstractController contiene los métodos handleActionRequestInternal(..)y handleRenderRequestInternal(..).
El diseño se realiza a partir de DispatcherPortlet que asigna la request a los handlers, a partir de handler mappings configurables y resolución de la vista (forwards, redirect) de forma similar a como lo hace DispatcherServlet en el framework web. La mísma forma de proceder para request que manejan uploads de tipo file
La resolución de Locale y theme no estan soportadas por el framework - ya que estos aspectos conciernen a la generación de la vista por parte del contenedor portal/portlet y no se aplican al contexto Spring. Esto no afecta al tratamiento por parte de Spring de la Locale, (sino más bien a su modificación, sincronización con el contenedor portlet). Todos los mecanismos de Spring que tratan dicha Locale (internacionalización de mensajes), funcionaran correctamente ya que DispatcherPortlet expone la locale de la mísma manera que lo hace DispatcherServlet.
El controlador por defecto es una sencilla interfaz, que ofrece 2 métodos:
- void handleActionRequest(request,response)
- ModelAndView handleRenderRequest(request,response)
El framework añade ademas la mayoría de las implementaciones de controller existentes, como AbstractController, SimpleFormController... El acceso a datos a través de objetos implementan el patrón command, manejo del modelo y resolución de la vista, de forma transparente, como si trabajasemos directamente con el api Servlet.
La generación de la vista es semejante a la realizada con servlets, esto se consigue a través de un bridge llamado ViewRendererServlet. Al usar este servlet, la petición del portlet se convierte en una petición servlet y la vista se genera mediante servlets. Lo que lo hace compatible con generadores de vistas, como JSP, Velocity o Freemaker.
Beans cuyo ciclo de vida tiene se asocia a la duración de Request o Session. Esto no es una característica específica del framework Spring Portlet sino del contenedor Spring de WebApplicationContext. Más detalle sobre este tipo de bean en “Request, session, and global session scopes”
