Catlogo de Patrones de Diseo J2EE. I.

Capa de Presentacin
View Helper
Contexto
El sistema crea el contenido de la presentacin, lo que requiere el procesamiento de datos de negocio dinmicos.

Problema
Los cambios en la capa de presentacin ocurren muy frecuentemente y son difciles de desarrollar y mantener cuando la lgica de acceso a los datos de negocio y la lgica del formateo de la presentacin se mezclan. Esto hace el sistema menos flexible, menos reutilizable, y generalmente menos adaptable a los cambios. Mezclar la lgica de negocio y de sistema con el procesamiento de la vista reduce la modularidad y tambin proporciona una pobre separacin de los roles entre los equipos de produccin Web y de desarrollo de software.

Causas

Los requerimientos de asimilacin de datos de negocio no son triviales. o Embeber la lgica de negocio en la vista promueve un tipo de reutilizacin del tipo copiar-y-pegar. Esto causa problemas de mantenimiento y errores porque una pieza de lgica se reutiliza en la misma vista o en otra diferente simplemente duplicndola en la nueva localizacin. o Es deseable promover una separacin limpia de labores teniendo diferentes individuos cumpliendo los roles de miembros de un equipo de desarrollo de software y de produccin Web. o Una vista comnmente se utiliza para responder a una peticin de negocios particular.

Solucin
Una vista contiene cdigo de formateo, delegando sus responsabilidades de procesamiento en sus clases de ayuda, implementadas como JavaBeans o etiquetas personalizadas. Las clases de ayuda o helpers tambin almacenan el modelo de datos intermedio de la vista y sirven como adaptadores de datos de negocio.

Hay varias estrategias para implementar el componente de la vista. La estrategia JSP View siguiere utilizar una JSP como el componente vista. Esta es la estrategia preferida, y es la que se utiliza ms comunmente. La otra estrategia principal es la estrategia Servlet View, que utiliza un servlet como la vista. Encapsular la lgica de negocio en un helper en lugar de hacerlo en la vista hace que nuestra aplicacin sea ms modular y facilita la reutilizacin de componentes. Varios clientes, como controladores y vistas, podran utilizar el mismo helper para recuperar y adaptar estados del modelo similares para su presentacin en varias vistas. La nica forma de reutilizar la lgica embebida en una vista es copiando y pegando en cualquier lugar. Adems, la duplicacin mediante copiar-y-pegar hace que un sistema sea difcil de mantener, ya que necesitamos corregir en muchos sitios el mismo error potencial. Una seal de que podramos necesitar aplicar este patrn al cdigo existente es cuando el cdigo scriptlet domina en la vista JSP. Ya que el objetivo general cuando se aplica este patron, es el particionamiento de la lgica de negocio fuera de la vista. Mientras alguna lgica est mejor cuando se encapsula dentro de objetos helper, otra lgica est mejor situndola en un componente centralizado que se sita delante de las vistas y los helpers -esta podra la lgica que sea comn entre varias peticiones, como los chequeos de autentificacin o servicios de logs, por ejemplo. Si no se emplea un controlador separado en la arquitectura, o si no se utiliza para manejar todas las peticiones, entonces el componente vista se convierte en el punto de contacto inicial para manejar algunas peticiones. Para ciertas peticiones, particularmente aquellas que implican un procesamiento mnimo, este escenario funcionar bien. Tpicamente, esta situacin ocurre cuando pginas que estn basadas en informacin esttica, como la primera de un conjunto de pginas que se servirn a un usuario para obtener alguna informacin. . El patrn View Helper se enfoca en recomendar formas de particionar las responsabilidades de nuestras aplicaciones. Estructura Abajo podemos observar el diagrama de clases que representa el patrn View Helper.

Participantes y Responsabilidades La siguiente figura muestra el diagrama de secuencia que represetna el patrn View Helper. Normalmente un controlador media entre el cliente y la vista. Aunque en algunos

casos, no se utiliza un controlador y la vista se convierte en el punto de contacto inicial para manejar peticiones.

Como se ha podido observar en el diagrama de clases, podran no haber helpers asociados con una vista. En este caso simple, la pgina podra ser completamente esttica o incluir una muy pequea cantidad de scriptles. Este escenario se describe en el siguiente diagrama de secuencia:

View

Una vista representa y muestra informacin al cliente. La informacin que se utiliza en un display dinmico se recupera de un modelo. Los helpers soportan vistas encapsulando y adaptando un modelo para utilizarlo en un display.
Helper

Un helper es el responsable de ayudar a la vista o al controlador a completar su procesamiento. As los helpers tienen numerosas responsabilidades, incluyendo la obtencin de los datos requeridos por la vista y su almacenamiento en el modelo intermedio, en cuyo caso algunas veces nos podemos referir al helper como un Bean de Valor. Adems, los helpers podran adaptar este modelo de datos para que los utilizara la vista. Los helpers pueden servir peticiones de datos desde la vista simplemente proporcionando acceso a los datos o fomateando los datos como contenido Web. Una vista podra trabajar con cualquier nmero de helpers, que normalmente estn implementados como JavaBeans (JSP 1.0+) y etiquetas personalizadas (JSP 1.1+). Adems, un helper podra representar un objeto Command o un Tranformador XSL, que se utiliza en combinacin con una hoja de estilo para adaptar y convertir el modelo en el formato apropiado.
ValueBean

Un Bean de Valor es un otro nombre para un helper que es responsable de contener el estado del modelo intermedio para que lo utilice una vista. Un caso tpico, es el que tiene un servicio de negocio que devuelve un bean de valor en respuesta a esta peticin. Este caso, el Bean de valor cumple el rol de un objeto Transfer.
BusinessService

El servicio de negocio es un rol que cumple el servicio al que est accediendo el cliente. Tpicamente, se accede al servicio de negocio mediante un Delegado de Negocio. El rol del delegado de negocio es proporcionar control y proteccin para el servicio de negocio (podremos ver el patrn Business Delegate ms adelante). Estrategias
JSP View

La estrategia de Vista JSP sugiere la utilizacin de una JSP como el componente vista. Aunque semnticamente equivalente a la estrategia de Vista Servlet, es una solucin ms elegante y ms utilizada. Las vistas son el dominio de los diseadores Web, que prefieren un lenguaje de marcas al cdigo Java. El siguiente ejemplo muestra un ejemplo de cdigo para esta estrategia. El fragmento es de un fichero fuente llamado welcome.jsp, al que nos reenvia un controlador servlet despus de situar el JavaBean WelcomeHelper en el mbito de la peticion:

<jsp:useBean id="welcomeHelper" scope="request" class="corepatterns.util.WelcomeHelper" /> <HTML> <BODY bgcolor="FFFFFF"> <% if (welcomeHelper.nameExists()) { %> <center><H3> Welcome <destacar> <jsp:getProperty name="welcomeHelper" property="name" /> </destacar><br><br> </H3></center> <% } %> <H4><center>Glad you are visiting our site!</center></H4> </BODY> </HTML>

La estrategia alternativa de Vista Servlet normalmente se implementa embebiendo marcas HTML directamente dentro del cdigo Java. Mezclar cdigo Java y etiquetas de marcas crea una pobre separacin de los roles de usuario dentro de un proyecto e incrementa las dependencias de los mismos recursos entre varios miembros de diferentes equipos. Cuando un individuo trabaja en una plantilla que contiene cdigo o etiquetas no familiares, incrementa el riesgo de que un cambio accidental introduzca problemas en el sistema. Tambin hay una reduccin de la eficiencia del entorno de trabajo (demasiada gente compartiendo los mismos recursos fsicos) y un incremento en el manejo de control de fuentes. Estos problemas ocurren ms frecuentemente en grandes entornos empresariales que tienen requerimientos de sistemas ms complicados y que utilizan equipos de desarrolladores. Tiene menos probabilidades de ocurrir en pequeos sistemas que tienen sencillos requerimientos y utilizan unos pocos desarrolladores porque el mismo individuo cumple los roles mencionados arriba. Sin embargo, debemos tener en mente que los proyectos suelen empezar pequeos -- con requerimiento sencillos y unos cuantos desarrolladores -- pero finalmente evolucionan y se convierten en suficientemente sofisticados como para beneficiarse de estas sugerencias.
Servlet View

La estrategia de Vista Servlet utiliza un servlet como la vista. Es semnticametne equivalente al estrategia preferida de Vista JSP. Sin embargo, la estrategia de Vista Servlet, como vemos en el ejemplo siguiente, es ms engorrosa para los equipos de desarrollo de software y de produccin Web porque embebe etiquetas de marcas dentro del cdigo Java. Cuando las etiquetas se mezclan con el cdigo Jaba, la plantilla de la vista es ms difcil de actualizar y modificar.

public class Controller extends HttpServlet { public void init(ServletConfig config) throws ServletException { super.init(config); } public void destroy() { } /** Processes requests for both HTTP * <code>GET</code> and <code>POST</code> methods. * @param request servlet request * @param response servlet response */ protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { String title = "Servlet View Strategy"; try { response.setContentType("text/html"); java.io.PrintWriter out = response.getWriter(); out.println("<html><title>"+title+"</title>"); out.println("<body>"); out.println("<h2><center>Employees List</h2>"); EmployeeDelegate delegate = new EmployeeDelegate(); /** ApplicationResources provides a simple API * for retrieving constants and other * preconfigured values**/ Iterator employees = delegate.getEmployees( ApplicationResources.getInstance(). getAllDepartments()); out.println("<table border=2>"); out.println("<tr><th>First Name</th>" + "<th>Last Name</th>" + "<th>Designation</th><th>Id</th></tr>"); while (employees.hasNext()) out.println("<tr>"); EmployeeTO emp = (EmployeeTO)employees.next(); out.println("<td>"+emp.getFirstName()+ "</td>"); out.println("<td>"+emp.getLastName()+ "</td>"); out.println("<td>"+emp.getDesignation()+ "</td>"); out.println("<td>"+emp.getId()+"</td>"); out.println("</tr>"); } out.println("</table>"); out.println("<br><br>"); out.println("</body>"); out.println("</html>"); out.close(); } catch (Exception e) { LogManager.logMessage("Handle this exception", e.getMessage() );

} } /** Handles the HTTP <code>GET</code> method. * @param request servlet request * @param response servlet response */ protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { processRequest(request, response); } /** Handles the HTTP <code>POST</code> method. * @param request servlet request * @param response servlet response */ protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { processRequest(request, response); } /** Returns a short description of the servlet. */ public String getServletInfo() { return "Example of Servlet View. " + "JSP View is preferable."; } /** dispatcher method **/ protected void dispatch(HttpServletRequest request, HttpServletResponse response, String page) throws javax.servlet.ServletException, java.io.IOException { RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(page); dispatcher.forward(request, response); } }

JavaBean Helper

El helper se implementa como un JavaBean. La utilizacin de helpers resulta en una separacin limpia de la vista y el procesamiento de negocio en una aplicacin, ya que la lgica de negocio est construida fuera de la vista y dentro del componente helper. En este caso, la lgica de negocio se encapsula en un JavaBean, que ayuda en la recuperacin de contenido y adapta y almacena el modelo para usarlo en la vista. La utilizacin de la estrategia JavaBean Helper requiere menos trabajo que la estrategia Custom Tag Helper, ya que los JavaBeans se construyen e integran ms facilmente en un entorno JSP. Adems, incluso los desarrolaldores novatos entienden los JavaBeans. En el siguiente cdigo podemos ver un ejemplo de esta estrategia:

<jsp:useBean id="welcomeHelper" scope="request" class="corepatterns.util.WelcomeHelper" /> <HTML> <BODY bgcolor="FFFFFF"> <% if (welcomeHelper.nameExists()) { %> <center><H3> Welcome <destacar> <jsp:getProperty name="welcomeHelper" property="name" /> </destacar><br><br> </H3></center> <% } %> <H4><center>Glad you are visiting our site!</center></H4> </BODY> </HTML>

Custom Tag Helper

El helper se implementa como una etiqueta personalizada (slo JSP 1.1+). La utilizacin de helpers resulta en una separacin limpia de la vista y el procesamiento de negocio en una aplicacin, ya que la lgica de negocio est construida fuera de la vista y dentro del componente helper. En este caso, la lgica de negocio se encapsula en un componente de etiqueta personalizada, que podra ayudar en la recuperacin de contenido y adaptar el modelo para su utilizacin en la vista. Usar esta estrategia requier mucho ms trabajo que hacerlo con la estrategia JavaBean Helper, ya que el desarrollo de etiquetas personalizadas es moderadamente complicado en relacin al desarrollo de JavaBeans. No solo es ms complejo el proceso de desarrollo, sino que hay mucha complejidad con respecto a la integracin y el manejo de las etiquetas completadas. Para utilizar esta estrategia, debemos configurar el entorno con numerosos artefactos generados, incluyendo la propia etiqueta, un descriptor de librera de etiquetas, y los ficheros de configuracin. Abajo podemos ver un fragmento de una vista JSP que utiliza esta estrategia:
<%@ taglib uri="/web-INF/corepatternstaglibrary.tld" prefix="corepatterns" %> <html> <head><title>Employee List</title></head> <body> <div align="center"> <h3> List of employees in <corepatterns:department attribute="id"/> department - Using Custom Tag Helper Strategy. </h3> <table border="1" >

<tr> <th> First Name </th> <th> Last Name </th> <th> Designation </th> <th> Employee Id </th> <th> Tax Deductibles </th> <th> Performance Remarks </th> <th> Yearly Salary</th> </tr> <corepatterns:employeelist id="employeelist_key"> <tr> <td><corepatterns:employee attribute="FirstName"/> </td> <td><corepatterns:employee attribute= "LastName"/></td> <td><corepatterns:employee attribute= "Designation"/> </td> <td><corepatterns:employee attribute= "Id"/></td> <td><corepatterns:employee attribute="NoOfDeductibles"/></td> <td><corepatterns:employee attribute="PerformanceRemarks"/></td> <td><corepatterns:employee attribute="YearlySalary"/></td> <td> </tr> </corepatterns:employeelist> </table> </div> </body> </html>

Business Delegate as Helper

Los componentes helper normalmente hacen llamadas distribuidas a la capa de negocio. Sugerimos la utilizacin de un delegado de negocio para poder ocultar los detalles de la implementacin subyacente, as como dicho helper simplemente invoca un servicio de negocio sin conocer los detalles sobre su implementacin fsica y su distribucin. Tanto el helper como el delegado de negocio deben implementarse como JavaBeans. As, se podra combinar la nocin del componente helper y del delegado de negocio e implementar el delegado de negocio como un tipo de helper especializado. Hay una mayor distincin entre un helper y un delegado de negocio: Un desarrollador que trabaja en la capa de presentacin escribe un componente helper, mientras que el delegado normalmente lo escribe un desarrollador que trabaja en los servicios de la capa de negocio. (Nota: El delegado tambin se podra proporcionar como una parte del marco de trabajo). As, est estrategia trato mucho ms sobre quin escribe realmente el delegado que sobre la propia implementacin. Si hay algn solapamiento en los roles de desarrollo, entonces deberiamos considerar la utilizacin de esta estrategia.

/**A servlet delegates to a command object helper, as shown in the following excerpt:**/ String resultPage = command.execute(request, response); /**The command object helper uses the business delegate, which is simply implemented as another JavaBean helper, as shown in the following excerpt:**/ AccountDelegate accountDelegate = new AccountDelegate();

Una nota sobre los Helpers: Los helpers JavaBean se utilizan para ayudar en la recuperacin de contenido y en el almacenamiento y adaptacin del modelo para la vista. Los helpers JavaBean tambin se utilizan frecuentemente como objetos Command. Al igual que los helpers JavaBean, los helpers de etiquetas personalizadas podran cumplir cualquiera de estos roles, excepto el de actuar como un objeto command. Al contrario que los helpers JavaBean, los helpers de etiquetas personalizadas estn bien diseados para el control de flujo y la interaccin con la vista. Los helpers de etiquetas personalizadas utilizados de esta forma encapsulan lgica que de otro modo podra embeberse directamente dentro de la pgina JSP como cdigo scriptlet. Otra rea donde es preferible utilizar helpers de etiquetas personalizadas es en el formato de datos para display. Una etiqueta personalizada puede iterar sobre una coleccin de resultados, formatear esos resultados en un tabla HTML, y embeber la tabla dentro de la vista JSP sin requerir ningn scriptlet Java. Consideremos un ejemplo en el que le pedimos a un cliente Web alguna informacin de la cuenta del sistema, como se ve en la siguiente figura.

Podemos ver cinco helpers en este diagrama. Los cuatro helpers JavaBean son el objeto AccountCommand, el objeto Account, el objeto AccountDAO, y AccountDetails. El nico helper de etiqueta personalizada es el objeto TableFormatter. El controlador maneja la peticin. Crea o busca el objeto command apropiado, que est implementado como un helper JavaBean. En este caso, es el objeto command que procesa las peticiones de informacin de la cuenta. El controlador invoca al objeto Command, que le pide la informacin sobre la cuenta a un objeto Account. El objeto Account invoca al servicio de negocio, pidendole estos detalles, que se devuelven en forma de un objeto Transfer implementado como un JavaBean. Entonces, como accede el objeto Account a los servicios de negocio? Examinemos dos casos, uno sencillo y otro un poco ms complicado. En el caso sencillo, imaginemos que un proyecto est en fase de aproximacin, enfasando Enterprise JavaBeans (EJB) dentro de la capa de negocio en el tiempo. Asumamos que estmos en el momento en que se est accediendo a la base de datos mediante llamadas JDBC desde la capa de presentacin. En ese caso, el objeto Account utiliza un objeto Data Access (en pginas posteriores veremos este patrn), ocultando los detalles de implementacin para acceder a la base de datos. El objeto Data Access sabe qu consultas SQL son las necesarias para recuperar la informacin. Estos detalles estn ocultos del resto de la aplicacin, reduciendo el acoplamiento y haciendo que todos los componentes sean ms modulares y reutilizables. Este es el caso descrito en el diagrama de secuencia anterior. Cuando la arquitectura se vuelve ms sofisticada, se introduce un EJB en la capa de negocio, entonces el objeto Data Access se reemplaza con un Business Delegate (ms adelante veremos este patrn), que normalmente est escrito por los desarrolladores de servicios de negocio. El delegado oculta los detalles de implementacin de la bsqueda EJB, de la invocacin y del manejo de excepciones. Tambin podra mejorar el rendimiento proporcionando servicio de cach. De nuevo, el objeto reduce el acoplamiento entre las capas, mejorando la reutilizacin y la modularidad de varios componentes. Sin importar la implementacin especfica de este objeto, su interface podra permanecer invariable durante esta transicin. La siguiente figura describe este escenario despus de la transicin al delegado de negocio.

Ahora el objeto command tiene que manejar el objeto AccountDetails, el cual almacena antes de devolver el control al controlador. El Controller lo reenvia a la vista apropiada, llamada AccountView.jsp. Entonces la vista obtiene una combinacin de datos en bruto y de datos formateados de los helpers AccountDetails y TableFormatter, respectivamente. TableFormatter est implementado como una etiqueta personalizada que pasa a travs de los datos en bruto y los formatea en una tabla HTML para mostrarla. Como vimos, esta conversin no requiere escribir nign scriptlet en la vista, lo que s sera necesario para realizar la misma funcionalidad con un helper JavaBean. Adems, el objeto Account o el helper AccountDetails podran proporcionar mtodos convenientes para adaptar los datos en bruto a otros formatos. Aunque dichos mtodos no introduciran etiquetas HTML en los datos, podran proporcionar diferentes combinaciones de datos. Un ejemplo es entregar el nombre completo del usuario en varios formatos, como "Lastname, Firstname" o "Firstname Lastname", etc.
Transformer Helper

El helper se implementa como un eXtensible Stylesheet Language Transformer. Esto es particularmente til con modelos que existen como marcas estructuradas, como el lenguaje eXtensible Markup Language (XML), bien nativamente dentro de sistemas legales o mediante alguna forma de conversin. Utilizar esta estrategia puede ayudarnos a forzar la separacin entre el modelo y la vista, ya que la mayora de las marcas de la vista se tienen que crear en una hoja de estilos separada. La siguiente figura describe una potencial implementacin de esta estrategia:

El controlador maneja la peticin e invoca al objeto Command, implementado como un helper JavaBean. El objeto Command inicia la recuperacin de los datos de la cuenta. El objeto Account invoca al servicio de negocio, que devuelve los datos en forma de un objeto Transfer, implementado como un JavaBean. Se completa la recuperacin de contenido y el control se pasa al AccountView, que utiliza su etiqueta personalizada transformer para manipular el estado del modelo. El transformer trata con un hoja de estilo, que describe cmo transformar el modelo, normalmente describiendo cmo formatearlo con etiquetas para mostrarlo en el cliente. La hoja de estilo normalmente se recupera como un fichero esttico, aunque se podra generar dinmicamente. Aqu tenemos un ejemplo de lo que debera ser la etiqueta personalizada:
<xsl:transform model="accounthelper" stylesheet="/transform/styles/basicaccount.xsl"/>

Consecuencias

Mejora el Particionamiento de la Aplicacin, la Reutilizacin y el Mantenimiento Utilizar helpers resulta en una clara separacin de la vista del procesamiento de negocio en una aplicacin. Los helpers, en forma de JavaBeans (JSP 1.0+) y etiquetas personalizadas (JSP 1.1+), proporcionan un lugar externo para que la vista encapsule la lgica de negocio. Por el contrario, el cdigo en scriptlets dentro de las pginas JSP, emborrona ampliamente la situacin, especialmente en gandes proyectos.

Adems, la lgica de negocio que se construye fuera de las JSPs y dentro de los JavaBeans y las etiquetas personalizadas se reutiliza, reduciendo la duplicacin y facilitando el mantenimiento.

Mejora la Separacin de Roles Separar la lgica del formateo de la lgica de negocio de la aplicacin reduce las dependencias podran tener los individuos que juegan los diferentes roles en los mismos recursos. Por ejemplo, un desarrollador de software podra poseer cdigo que est embebido dentro de marcas HTML, mientras que un miembro del equipo de produccin Web podra necesitar modificar la distribucin de la pgina y disear componentes que estn mezclados con la lgia de negocios. Ningn individuo que cumpla estos roles podra estar familiarizado con las implementaciones especficas del trabajo del otro individuo, y asi se evita el riesgo de introducir bugs mediante modificaciones accidentales del sistema.

Patrones Relacionados

Business Delegate Los componentes helper necesitan mtodos de acceso al API de servicios de negocio. Tambin es importante reducir el acoplamiento entre helpers en la capa de presentacin y entre servicios de negocio en la capa de negocio. Se recomienda que se utilice un delegate porque estas capas podran estar distribuidas fsicamente por la red. El delegado le oculta al clinte los detalles subyacentes de la bsqueda y acceso a los servicios de negocio, y tambin podra proporcionar un cach intermedio para reducir el trfico de la red. Dispatcher View y Service to Worker Cuando sea deseable el control centralizado para manejar problemas como la seguridad, el control del carga de trabajo, la recuperacin de contenidos y la navegacin, debemos considerar la utilizacin de los patrones Dispatcher View o Service to Worker. Front Controller Este patrn est emparejado con el patrn View Helper para crear los patrones Dispatcher View o Service to Worker.

Composite View
Contexto
Las pginas Web sofisticadas presentan contenido de varias fuentes de datos, utilizando varias subvistas que completan una sla pgina. Adems, varios individuos con diferentes habilidades contribuyen al desarrollo y mantenimiento de esas pginas Web.

Problema

En lugar de proporcionar un mecanismo para combinar modularmente, en el que porciones atmicas de una vista componen un pgina completa, las pginas se construyen embebiendo cdigo de formateo directamente dentro de cada vista. La modificacin de la distribucin de mltiples vistas es difcil y propensa a errores, debido a la duplicacin de cdigo.

Causas

Las porciones atmicas del contenido de la vista cambian con frecuencia. Varias vistas compuestas utilizan subvistas similares, como un tabla de inventario de clientes. Estas porciones atmicas se decoran con una plantilla de texto alrededor diferente o aparecen en diferentes localizaciones dentro de la pgina. Los cambios de distribucin son ms difciles de manejar y el cdigo ms difcil de mantener cuando las subvistas se embeben directamente y se duplican en varias vistas. Frecuentemente, embeber las porciones cambiantes de la plantilla de texto directamente dentro de las vistas tambin afecta potencialmente a la disponibilidad y administracin del sistema. El servidor podra necesitar reinicializarse antes de que los cliente vieran las modificaciones o actualizaciones de estas plantillas de componentes.

Solucin
Utilizar vistas compuestas que se componen de varias subvistas atmicas. Cada componente de la plantilla se podra incluir dinmicamente dentro del total y la distribucin de la pgina se maneja independientemente del contenido. Esta solucin promueve la creacin de una vista compuesta basada en la inclusin y sustitucin de fragmentos de plantilla modulares tanto estticos como dinmicos. Tambin promueve la reutilizacin de porciones atmicas de la vista asegurando un diseo modular. Es apropiado utilizar este patrn para generar pginas que muestran componentes que podran combinarse en una gran variedad de formas. Este escenario ocurre, por ejemplo, con sites de portal que incluyen numerosas subvistas independientes, como noticias, informacin del tiempo, y valores de stocks en una sla pgina. La distribucin de la pgina se maneja y modifica de forma independiente al contenido de las subvistas. Otro beneficio de este patrn es que los diseadores Web pueden hacer un prototipo de la distribucin de la site, conectando contenido esttico en todas las regiones de la plantilla. Segn va progresando el desarrollo de la site, ese contenido esttico se puede sustituir por el contenido dinmico. La siguiente figura muestra una captura de pantalla de la pgina inicial de Sun, java.sun.com. Se identifican cuatro regiones: Navegacin, Bsqueda, Contenido y Cabeceras. Aunque el contenido de cada una de estas subvistas podra estar originado desde diferentes fuentes de datos, se unen para crear un sla pgina compuesta.

Esta patrn tambin tiene inconvenientes. Provoca una sobrecarga en el entorno de ejecucin, un precio que hay que pagar por el incremento de flexibilidad que proporciona. La utilizacin de un mecanismo de distribucin ms sofisticado tambin trae consigo algunos problemas de manejabilidad y desarrollo, ya que hay ms artefactos que mantener y un cierto nivel indirecto de implementacin que entender. Estructura La siguiente figura representa el diagrama de clases del patrn Composite View.

Participantes y Responsabilidades

La siguiente figura representa el diagrama de secuencia del patrn Composite View.

Composite View

Una vista compuesta es una vista a la que se le han agregado varias subvistas.
View Manager

El Controlador de Vista maneja la inclusin de porciones de fragmentos de plantilla en la vista compuesta. El Controlador de Vista podra ser parte de un motor de ejecucin estndar de pginas JSP, en la forma de la etiqueta <jsp:include> de JSP, o podra encapsularse dentro de un helper JavaBean (JSP 1.0+) o una etiqueta personalizada (JSP 1.1+) para proporcionar una funcionalidad ms robusta. Un beneficio adicional de utilizar un mecanismo distinto a la etiqueta include estndar es que stos facilitan la inclusin condicional. Por ejemplo, ciertos fragmentos de plantilla se podran incluir slo si el usuario cumple un rol particular o si se cumplen ciertas condiciones del sistema. Adems, utilizar un componente helper como View Manager nos permite un control ms sofisticado de toda la estructura de la pgina, lo que es til para crear distribuciones de pginas reutilizables.
Included View

Una Vista Incluida es una subvista que es una pieza atmica de un vista completa mayor. Esta vista incluida potencialmente tambin podra ser una vista compuesta, incluyeno ella misma varias subvistas. Estrategias

JSP page View

Ver la estrategia "JSP page View" en el patrn View Helper.

Servlet View

Ver la estrategia "Servlet View" en el patrn View Helper.

JavaBean View Management

El control de la vista se implementa utilizando componentes JavaBeans, como se ve en el siguiente ejemplo. La vista delega en el JavaBean, que implementa la lgica personalizada para controlar la distribucin y composicin de la vista. Las decisiones sobre la distribucin de la pgna se deben basar en roles de usuario o polticas de seguridad, hacindolo mucho ms poderoso que la etiqueta include de una pgina JSP. Aunque es semnticamente equivalente a la Estrategia de Control de Vista por Etiqueta Personalizada, no es tan elengante porque introduce cdigo scriptlet en la vista. Utilizar esta estrategia requiere menos trabajo que utilizar la estrategia preferida de Control de Vista por Etiqueta Personalziada, porque es ms fcil construir componentes JavaBeans e integrarlos en un entorno de pginas JSP. Adems, incluso los desarrolladores ms novatos pueden entender los componentes JavaBeans. Esta estrategia tambin es fcil desde el punto de vista de la manejabilidad, porque los componentes JavaBeans son los nicos artefactos que hay que manejar y configurar.
<%@page import="corepatterns.compositeview.beanhelper.ContentHelper" %> <% ContentHelper personalizer = new ContentHelper(request); %> <table valign="top" cellpadding="30%" width="100%"> <% if (personalizer.hasWorldNewsInterest() ) { %> <tr> <td><jsp:getProperty name="feeder" property="worldNews"/></td> </tr> <% } if ( personalizer.hasCountryNewsInterest() ) { %> <tr> <td><jsp:getProperty name="feeder" property="countryNews"/></td> </tr> <% } if ( personalizer.hasCustomNewsInterest() ) { %>

<tr> <td><jsp:getProperty name="feeder" property="customNews"/></td> </tr> <% } if ( personalizer.hasAstronomyInterest() ) { %> <tr> <td><jsp:getProperty name="feeder" property="astronomyNews"/></td> </tr> <% } %> </table>

Standard Tag View Management

El control de la vista se implementa utilizando etiquetas JSP estndar, como <jsp:include>. Utilizar etiquetas estndar para manejar la distribucin y composicin de las vistas es una estrategia fcil de implementar, pero no proporciona el poder y la flexibilidad de la Estrategia de Control de Vista por Etiqueta Personalizada, ya que la distribucin de las pginas individuales permanece embebida dentro de esas pginas. As, aunque esta estrategia permite variar dinmicamente el contenido subyacente, cualquier cambio general en la distribucin requerira modificaciones individuales en muchas pginas JSP. Podemos verlo en el siguiente ejemplo:
<html> <body> <jsp:include page="/jsp/CompositeView/javabean/banner.html" flush="true"/> <table width="100%"> <tr align="left" valign="middle"> <td width="20%"> <jsp:include page="/jsp/CompositeView/javabean/ProfilePane.jsp" flush="true"/> </td> <td width="70%" align="center"> <jsp:include page="/jsp/CompositeView/javabean/mainpanel.jsp" flush="true"/> </td> </tr> </table> <jsp:include page="/jsp/CompositeView/javabean/footer.html" flush="true"/>

</body> </html>

Cuando se crea una vista compuesta utilizando etiquetas estndar, se puede incluir tanto contenido esttico, ficheros HTML, como contenido dinmico, pginas JSP. Adems, el contenido se puede incluir en el momento de la traduccin o durante la ejecucin. Si el contenido se incluye durante la traduccin, la vista permanecer sin modificada hasta que se recompile la pgina JSP, momento en el que sern visibles las modificaciones incluidas en el contenido. En otras palabras, la pgina se distribuye y genera una sola vez, cada vez que la pgina JSP se recompila. El siguiente ejemplo, muestra una excepcin de una pgina JSP que genera una vista compuesta de esta manera, utilizando la directiva <%@ include %> estndar de JSP que incluye el contenido en tiempo de traduccin..
<table border=1 valign="top" cellpadding="2%" width="100%"> <tr> <td><%@ file="news/worldnews.html" %> </td> </tr> <tr> <td><%@ file="news/countrynews.html" %> </td> </tr> <tr> <td><%@ file="news/customnews.html" %> </td> </tr> <tr> <td><%@ file="news/astronomy.html" %> </td> </tr> </table>

La inclusin de contenido en tiempo de ejecucin significa que los cambios en las subvistas son visibles en la pgina compuesta cada vez que el cliente accede a ella. Esto es mucho ms dinmico y se puede conseguir utilizando la etiqueta <jsp:include> estndar de JSP, como se muestra en el siguiente ejemplo. Por supuesto que hay una sobrecarga del entorno de ejecucin asociada con este tipo de generacin de vistas, pero este es el incoveniente de mejorar la flexibilidad de las modificaciones de contenidos al-vuelo.
<table border=1 valign="top" cellpadding="2%" width="100%"> <tr> <td><jsp:include page="news/worldnews.jsp" flush="true"/> </td> </tr> <tr> <td><jsp:include page="news/countrynews.jsp" flush="true"/> </td> </tr> <tr> <td><jsp:include page="news/customnews.jsp" flush="true"/> </td>

</tr> <tr> <td><jsp:include page="news/astronomy.jsp" flush="true"/> </td> </tr> </table>

Custom Tag View Management

El control de la vista se implementa mediante etiquetas personalizadas (JSP 1.1+), que es la estrategia preferida. La lgica implementada dentro de la etiqueta controla la distribucin de la vista y la composicin. Estas etiquetas son mucho ms poderosas y flexibles que la etiqueta include estndar de JSP, pero tambin requiere un mayor nivel de esfuerzo. Las acciones personalizadas se pueden basar en la distribucin y composicin de la pgina o en otras cosas como los roles del usuario y las polticas de seguridad. Utilizar esta estrategia requiere mucho ms trabajo que las otras estrategias de control de vista ya que el desarrollo de etiquetas personalizadas es ms complicado que simplemente utilizar componentes JavaBeans o etiquetas estndar. No slo es ms complicado el proceso de desarrollo, tambin hay mucha ms complejidad en cuanto a la integracin y el manejo de las etiquetas generadas. La utilizacin de esta estrategia requiere la generacin de numerosos artefactos, incluyendo la propia etiqueta, un descriptor de librera de etiquetas, ficheros de configuracin, y configurar el entorno con estos artefactos. El siguiente fragmento de pgina JSP muestra una posible implementacin de esta estrategia.
<region:render template='/jsp/CompositeView/templates/portal.jsp'> <region:put section='banner' content='/jsp/CompositeView/templates/banner.jsp' /> <region:put section='controlpanel' content= '/jsp/CompositeView/templates/ProfilePane.jsp' /> <region:put section='mainpanel' content= '/jsp/CompositeView/templates/mainpanel.jsp' /> <region:put section='footer' content= '/jsp/CompositeView/templates/footer.jsp' /> </region:render>

Transformer View Management

El control de la vista se implementa utilizando un Transformador XSL. Esta estrategia se complementara con la Estrategia de Control de Vista por Etiqueta Personalizada, utilizando etiquetas personalizadas para implementar y delegar en los componentes

apropiados. Utilizar esta estrategia nos puede ayudar a reforzar las separacin entre el modelo y la vista, ya que muchas de las marcas de la vista se deben crear dentro de una hoja de estilos separada. Al mismo tiempo, implica tecnologas que requieren nuevas y sofisticadas habilidades para implementarlo correctamente, un problema que hace que esta estrategia sea impracticable en muchos entornos donde estas tecnologas no estn an establecidas. El siguiente fragmento muestra el uso de una etiqueta personalizada dentro de una pgina JSP para convertir un modelo utilizando un hoja de estilo y un transformador:
<xsl:transform model="portfolioHelper" stylesheet="/transform/styles/generalPortfolio.xsl"/>

Early-Binding Resource

Este es otro nombre para la inclusin de contenido durante la traduccin, como se describe en la estrategia Control de Vista Mediate Etiqueta Estndar. Es apropiado para mantener y actualizar una plantilla relativamente esttica y est recomendado si una vista incluye cabeceras y pies de pgina que no cambian muy a menudo.
Late-Binding Resource

Este es otro nombre para la inclusin de contenido durante la traduccin, como se describe en la estrategia Control de Vista Mediate Etiqueta Estndar. Es apropiada para pginas compuestras que podran cambiar con cierta frecuencia. Una advertencia: Si la subvista incluida en tiempo de ejecucin es un recurso dinmico, como una pgina JSP, entonces sta subvista tambin podra ser una vista compuesta, incluyendo ms contenido en tiempo de ejecucin. La flexibilidad ofrecida por dichas estructuras anidadas debera pesar mucho ms que la sobrecarga del entorno que va crear.

Consecuencias

Mejora la Modularidad y la Reutilizacin Este patrn promueve un diseo modular. Es posible reutilizar porciones atmicas de una plantilla, como una tabla de consulta de stocks, en varias vistas y redecorar estas porciones reutilizadas con informacin diferente. Este patrn permite que la tabla se mueva dentro de su propio mdulo e incluirla simplemente donde sea necesario. Este tipo de distribucin y composicin dinmicos reduce la duplicacin, fuerza la reutilizacin y mejora la manejabilidad. Mejora la Flexibilidad Una implementacin sofisticada podra incluir condicionalmente fragmentos de plantillas de vista basndose en decisiones en tiempo de ejecuin, como los roles de usuario o las polticas de seguridad. Mejora el Mantenimiento y la Manejabilidad Es mucho ms eficiente manejar cambios en porciones de una plantilla cuando la

plantilla no est codificada directamente en las marcas de la vista. Cuando se mantienen separadas de la vista, es posible modificar prociones modulares del contenido de la plantilla independientemente de su distribucin. Adems, esos cambios estn disponibles inmediatamente para los clientes, dependendiendo de la estrategia de implementacin. Las modificaciones en la distribucin de una pgona tambin se maneja ms fcilmente, ya que los cambios estn centralizados. Reduce la Manejabilidad Agregar piezas atmicas para mostrarlas juntas y crear una sola vista presenta algunos potenciales problemas de presentacin, ya que las subvistas son fragmentos de pginas. Esta es una limitacin que se puede convertir en un problema de manejabilidad. Por ejemplo, si una pgina JSP est generando una pgina HTML utilizando una pgina principal que incluye tres subvistas, y cada una de las subvistas incluye las etiquetas de apertura y cierre de HTML (es decir, <HTML> y </HTML>), entonces la pgina compuesta no ser vlida. Por lo tanto, es importante cuando utilicemos este patrn tener cuidado de que las subvistas no deben ser vistas completas. Se deben contabilizar estrictamente las etiquetas utilizadas para crear vistas compuestas vlidas, y as corregir este problema de manejabilidad. Impacto en el Rendimiento Generar una presentacin que incluye numerosas subvistas podra empeorar el rendimiento. La inclusin en tiempo de ejecucin de subvistas resultar en un retardo cada vez que se sirva la pgina a un cliente. En un entorno con Acuerdos de Nivel de Servicio que obligan a tiempos de respuesta especficos, dichas bajadas de rendimiento, anque tpicamente sean mnimas, podran no ser aceptables. Una alternativa es mover la inclusin de las subvistas al tiempo de la traduccin, aunque esto limita a que las subvistas slo cambien cuando se re-traduce la pgina.

Cdigo de Ejemplo
El patrn de Vista Compuesta se puede implementar utilizando cualquier nmero de estrategias, pero una de las ms populares es la Estrategia de Control de Vista por Etiqueta Personalizada. De hecho, actualmente hay disponibles varias libreras de etiquetas personalizadas para implementar vistas compuestas que separan las distribucin de la vista de su contenido y proporciona plantillas de subvistas modulares y conectables. Este ejemplo utilizar una librera de plantillas escrita por David Geary. La librera template describe tres componentes bsicos: secciones, regiones y plantillas:

Una seccion es un componente reutilizable que representa HTML o una pgina JSP. Una regin describe contenido definiendo secciones. Una plantilla controla la distribucin de la regiones y secciones en una pgina.

Aqu podemos ver una regin y sus secciones

<region:render template='portal.jsp'> <region:put section='banner' content = 'banner.jsp' />

<region:put section = 'controlpanel' content = 'ProfilePane.jsp' /> <region:put section='mainpanel' content = 'mainpanel.jsp' /> <region:put section='footer' content='footer.jsp' /> </region:render>

Una regin define su contenido correspondiendo nombres de secciones lgicas con una porcin de contenido, como banner.jsp. La distribucin de la regin y sus secciones est definida por una plantilla, a la que se asocia cada regin. En este caso, la plantilla se llama portal.jsp, como se define en el siguiente ejemplo:
<region:render section='banner'/> <table width="100%"> <tr align="left" valign="middle"> <td width="20%"> <!-- menu region --> <region:render section='controlpanel' /> </td> <td width="70%" align="center"> <!-- contents --> <region:render section='mainpanel' /> </td> </tr> </table>

Un site con varias vistas y una sola distribucin cosistente tiene un pgina JSP que contiene cdigo que ser similar a la definicin del ejemplo anterior, y muchas pginas JSP que sern similares al primer fragmento de cdigo de esta seccin, que definen regiones y secciones alternativas. Las secciones son fragmentos de pginas JSP que se utilizan como subvistas para construir una vista completa segn se define en la plantilla. Abajo podemos ver la seccin banner.jsp:
<table width="100%" bgcolor="#C0C0C0"> <tr align="left" valign="middle"> <td width="100%"> <TABLE ALIGN="left" BORDER=1 WIDTH="100%"> <TR ALIGN="left" VALIGN="middle"> <TD>Logo</TD> <TD><center>Sun Java Center</TD> </TR> </TABLE> </td>

</tr> </table>

Las vistas compuestas son una forma modular, flexible y extensible de construir vistas de pginas JSP para nuestras aplicaciones J2EE.

Patrones Relacionados

View Helper El patrn de vista compuesta se podra utilizar como la vista del patrn View Helper. Composite [GoF] El patrn de Vista Compuesta est basado en el patrn Composite, que describe las herencias parte-totalidad cuando un objeto compuesto se compone de varias piezas, todas ellas tratadas como equivalente lgicos.

Service to Worker
Contexto
El sistema controla el flujo de ejecucin y accede a los datos de negocio, desde los que crea el contenido de la presentacin. Nota: El patrn Service to Worker, igual que el patrn Dispatcher View, describe una combinacin comn de otros patrones del catlogo. Estos dos macro-patrones describen las combinacin de un controlador y un dispatcher con vistas y helpers. Aunque describen esta estructura comn, cada uno enfatiza un uso diferentes de los patrones.

Problema
El problema es una combinacin de los problemas resueltos por los patrones Front Controller y View Helper de la capa de presentacin. No hay un componente centralizado para manejar el control de acceso, la recuperacin de contenido, o el manejo de la vista, y hay cdigo de control duplicado esparcido por varias vistas. Adems, la lgica de negocio y la de formateo de la presentacin estn mezcladas en esas vistas, haciendo que el sistema sea menos flexible, menos reutilizables y generalmente menos resistente a los cambios. Mezclar lgica de negocio con el procesamiento de la vista tambin reduce la modularidad y proporciona una pobre separacin de roles entre los equipos de produccin Web y de desarrollo de software.

Causas

Los chequeos de autentificacin y autorizacin se completan en cada peticin. El cdigo scriptlet dentro de las vistas se debera minimizar. La lgica de negocio se debera encapsular en componentes distintos a la vista. El control de flujo es relativamente complejo y se basa en valores del contenido dinmico. La lgica de control de la vista es relativamente sofisticada, con varias vistas que potencialmente se mapean a la misma peticin.

Solucin
Combinar un controlador y un dispacher con vistas y helper (ver Front Controller y View Helper) para manejar peticiones de clientes y preparar una presentacin dinmica como respuesta. Los controladores delegan la recuperacin de contenido en los helpers, que manejan el relleno del modelo intermedio para la vista. Un dispatcher es el responsable del control de la vista y la navegacin y puede encapsularse dentro de un controlador o de un componente separado. Service to Worker describe la combinacin de los patrones Front Controller y View Helper con un componente dispatcher. Aunque este patrn y Dispatcher View describen una estructura similar, ambos sugieren diferentes divisiones de la labor entre los componentes. En Service to Worker, el controlador y el dispatcher tienen ms responsabilidades. Aunque los patrones Service to Worker y Dispatcher View representan una combinacin de otros patrones del catlogo, el primero garantiza con su nombre una comunicacin eficiente entre los desarrolladores. Mientras que el segundo sugiere una recuperacin de contenido relegada al momento de procesamiento de la vista. En el patrn Dispatcher View, el dispatcher normalmente juega un rol moderado en el control de la vista. En el patrn Service to Worker, el dispatcher juega un rol algo ms elevado en el control de la vista. Un rol limitado para el dispatcher ocurre cuando no se utiliza recursos exteriores para poder elegir la vista. La informacin encapsulada en la peticin es suficiente para determinar la vista a la que despachar la peticin. Por ejemplo:
http://some.server.com/servlet/Controller?next=login.jsp

La nica responsabilidad del componente dispatcher en este caso es reenviar a la vista login.jsp.

Un ejemplo del dispatcher jugando un rol moderado es el caso donde el cliente enva una peticin directamente al controlador con un parmetro de consulta que describe una accin a realizar:
http://some.server.com/servlet/Controller?action=login

Aqu la responsabilidad del dispatcher es traducir el nombre lgico login en el nombre del recurso de una vista apropiada, como login.jsp, y reenviar a esa vista. Para conseguir esta traduccin, el dispatcher podra acceder a recursos como un fichero de configuracin XML que especifica las vistas apropiadas a mostrar. Por otro lado, en el patrn Service to Worker, el dispatcher podra invocar servicios de negocio para determinar la vista apropiada que se debe mostrar. La estructrua compartida de Service to Worker y Dispatcher View consiste en un controlador trabajanado con un dispatcher, vistas y helpers. Estructura En la siguiente figura podemos ver el diagrama de clases que representa al patrn Service to Worker.

Participantes y Responsabilidades La siguiente figura muestra el diagrama de secuencia que representa al patrn Service to Worker.

Como hemos comentado, Service to Worker y Dispatcher View representan una estructura similar. La principal diferencia es que Service to Worker describe arquitecturas con un comportamiento ms up front (ms cercano) al controlador y al dispatcher, mientras que Dispatcher View describe arquitecturas donde se ha movido ms comportamiento al momento del procesamiento de la vista. As, los patrones sugieren una continuidad, donde el comportamiento se ha encapsulado ms cerca de la vista o se ha movido haca atrs en el flujo de proceso.
Controller

El controlador normalmente es el punto de contacto inicial para manejar una peticin. Funciona con un dispatcher para completar el control de la vista y la navegacin. El controlador maneja la autentificacin, la autorizacin, la recuperacin de contenido, la validacin y otros aspectos del manejo de la peticin. Delega en los helpers para completar partes de este trabajo.
Dispatcher

Un dispatcher es el responsable del control de la vista y la navegacin, controlando la eleccin de la siguiente vista a mostrar y proporciona el mecanismo para dirigir el control a este recurso. Un dispatcher se puede encapsular dentro de un controlador (ver Front Controller) o puede ser un componente independiente que trabaja en coordinacin con el controlador. El dispatcher puede proporcionar reenvo esttico a la vista o podra proporcionar un mecanismo de reenvo dinmico ms sofisticado.

El dispatcher utiliza el objeto RequestDispatcher (soportado en la especificacin Servlet), pero tambin encapsula alguna informacin de procesamiento adicional. Cuantas ms responsabilidades encapsule este componente, ms se acercar al ideal del patrn Service to Worker. Y al controlario, cuando el diapatcher juega un papel ms limitado, ms se acercar al ideal del patrn Dispatcher View.
View

Una Vista representa una presentacin de informacin al cliente. La informacin utilizada en esta presentacin se recupera de un modelo. Los helpers soportan vistas encapsulando y adaptando un modelo para utilizarlo en una presentacin.
Helper

Un helper es el responsable de ayudar a la vista o al controlador a completar su procesamiento. As, los helpers tienen numerosas responsabilidades, incluyendo la obtencin de los datos requeridos por la vista y almacenndolos en el modelo intermedio, en cuyo caso el helper es conocido como un value bean. Adems, los helpers podran adaptar este modelo de datos para que los utilice la vista. Los helpers pueden servir peticiones de datos desde la vista simplemente proporcionando acceso a los datos en bruto o formatendolos como contenido Web. Una vista podra trabajar con cualquier nmero de helpers, que normalmente estn implementados por componentes JavaBeans (JSP 1.0+) o componentes de etiquetas personalidas (JSP 1.1+). Adems, un helper podra representar un objeto Command o delegate.
ValueBean

Un value bean es otro nombre para un helper que es responsable de contener el estado del modelo intermedio para que lo utilice una vista.
BusinessService

Servicio de Negocio es un rol que cumple el servicio al que el cliente quiere acceder. Normalmente, se accede al servicio de negocio mediante un Business delegate. El rol del business delegate es proporcionar control y proteccin para el servicio de negocio (puedes ver el patrn "Business Delegate" ms adelante). Estrategias
Servlet Front

Ver la estrategia "Servlet Front" en el patrn Front Controller.

JSP Front

Ver la estrategia "JSP Front" en el patrn Front Controller.

JSP page View

Ver la estrategia "JSP page View" en el patrn View Helper.

Servlet View

Ver la estrategia "Servlet View" en el patrn View Helper.

JavaBean Helper

Ver la estrategia "JavaBean Helper" en el patrn View Helper.

Custom Tag Helper

Ver la estrategia "Custom Tag Helper" en el patrn View Helper.

Dispatcher in Controller

Ver la estrategia "Dispatcher in Controller" en el patrn Front Controller. Como hemos visto, los patrones Service to Worker y Dispatcher View sugieren una continuidad, donde el comportamiento se ha encapsulado ms cerca de la vista o se ha movido haca atrs en el flujo de proceso. La siguiente figura describe un escenario en el que se ha cargado al controlador con mucho trabajo, pero la funcionalidad del dispatcher es mnima.

Transformer Helper

Ver la estrategia "Transformer Helper" en el patrn View Helper.

Consecuencias

Centraliza el Control y Mejora la Modularidad y la Reutilizacin Este patrn sugiere proporcionar un lugar central para manejar los servicios del sistema y la lgica de negocio entre varias peticiones. El contolador maneja el procesamiento de la lgica de negocio y el manejo de peticiones. Hay que tener en cuenta, que como control centralizado, es posible introducir un slo unto de fallo. El patrn tambin promueve el particionamiento de la aplicacin y aconseja la reutilizacin. El cdigo comn se mueve dentro de un controlador y es reutilizado por las peticiones y movido dentro de componentes helpers, en los que delegan los controladores y las vistas. La mejora de modularidad y de reutilizacin significa menos duplicacin de cdigo, que normalmente significa en entorno ms libre de bugs.

Mejora el Particionamiento de la Aplicacin La utilizacin de helpers resulta en una separacin clara entre la vista y el procesamiento de negocio en una aplicacin. Los helpers, en la forma de JavaBeans (JSP 1.0+) o etiquetas personalizadas (JSP 1.1+), proporcionan un lugar donde construir la lgica de negocio fuera de la pgina JSP. Si la lgica de negocio se deja dentro de la pgina JSP, los grandes proyectos resultan embrollados. Mejora la Separacin de Roles Al separar la lgica de formateo de la lgica de negocio de la aplicacin tambin se reducen las dependencias de los mismos recursos entre individuos que cumplen diferentes roles. Sin esta separacin, por ejemplo, un desarrollador de sofware poseera cdigo que est embebido dentro de marcas HTML, mientras que un miembro del equipo de produccin Web necesitara modificar la distribucin de una pgina y disear componentes que estn mezclados con lgica de negocio. Como ningn individuo que cumple estos roles est familiarizado con las implementaciones especficas del trabajo del otro individuo, se puede llegar a un punto de confusin en que las modificaciones accidentales introduzcan errores el sistema.

Cdigo de Ejemplo
Los siguientes fragmentos de cdigos muestran una implementacin del patrn Service to Worker, utilizando un servlet controlador, un helper command, un componente dispatcher y una vista. La implementacin incluye las estrategias Servlet Front, Command and Controller, JSP View y JavaBean Helper. Tambin se utiliza una vista compuesta muy bsica, como se puede ver en la siguiente imagen:

El siguiente ejemplo muestra el controlador servlet, que delega en un objeto Command para completar el procesamiento del control. El objeto Command se recupera mediante una llamada a la factora, que devuelve un Command de tipo genrico, como veremos ms adelante. El ejemplo utiliza un LogManager para guardar mensajes.
public class Controller extends HttpServlet { /** Processes requests for both HTTP * <code>GET</code> and <code>POST</code> methods. * @param request servlet request * @param response servlet response */ protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { String next; try { // Log pattern info LogManager.recordStrategy(request, "Service To Worker", " ServletFront Strategy;" + " JSPView Strategy; JavaBean helper Strategy"); LogManager.logMessage(request, getSignature(), "Process incoming request. "); // Use a helper object to gather parameter

// specific information. RequestHelper helper = new RequestHelper(request, response); LogManager.logMessage(request, getSignature(), "Getting command object helper"); // Get command object helper Command command = helper.getCommand(); // delegate processing to the command object, // passing request and response objects along next = command.execute(helper); /** * * * * * * * If the above command returns a value, we will dispatch from the controller. In this example, though, the command will use a separate dispatcher component to choose a view and dispatch to that view. The command object delegates to this dispatcher component in its execute method, above, and control should not return to this point **/

} catch (Exception e) { LogManager.logMessage( "EmployeeController(CommandStrategy)", e.getMessage() ); /** ApplicationResources provides a simple API * for retrieving constants and other * preconfigured values**/ next = ApplicationResources.getInstance(). getErrorPage(e); } dispatch(request, response, next); } /** Handles the HTTP <code>GET</code> method. * @param request servlet request * @param response servlet response */ protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { processRequest(request, response); } /** Handles the HTTP <code>POST</code> method. * @param request servlet request * @param response servlet response */ protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { processRequest(request, response); }

/** Returns a short description of the servlet. */ public String getServletInfo() { return getSignature(); } /** dispatcher method */ protected void dispatch(HttpServletRequest request, HttpServletResponse response, String page) throws javax.servlet.ServletException, java.io.IOException { RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(page); dispatcher.forward(request, response); } public void init(ServletConfig config) throws ServletException { super.init(config); } public void destroy() { } private String getSignature() { return "ServiceToWorker-Controller"; } }

En el siguiente fragmento tenemos el interface Command:

public interface Command { public String execute(RequestHelper helper) throws javax.servlet.ServletException, java.io.IOException; }

Todo objeto command implementa este interface genrico, que es un ejemplo del patrn Command de GoF. El objeto command es un ejemplar de la clase ViewAccountDetails, que podemos ver abajo. El ejemplar de command delega en un AccountingAdapter para hacer una llamada a la capa de negocio mediante Business Delegate.
public class ViewAccountDetailsCommand implements Command { public ViewAccountDetailsCommand() { } // view account details operation public String execute(RequestHelper helper) throws javax.servlet.ServletException, java.io.IOException { /** This will tell the user that a system error

* has occured and will typically not be seen. It * should be stored in a resource file **/ String systemerror = "/jspdefaultprocessingerror.jsp"; LogManager.logMessage(helper.getRequest(), "ViewAccountDetailsCommand", "Get Account Details from an adapter object"); /** Use an adapter to retrieve data from business * service, and store it in a request attribute. * Note: Object creation could be avoided via * factory, but for example purposes object * instantiation is shown **/ AccountingAdapter adapter = new AccountingAdapter(); adapter.setAccountInfo(helper); LogManager.logMessage(helper.getRequest(), "ViewAccountDetailsCommand", "processing complete"); /** Note: Object creation could be avoided via * factory, but for example purposes object * instantiation is shown**/ Dispatcher dispatcher = new Dispatcher(); dispatcher.dispatch(helper); /** This return string will not be sent in a * normal execution of this scenario, because * control is forwarded to another resource * before reaching this point. Some commands do * return a String, though, so the return value * is included for correctness. **/ return systemerror; } }

La clase adaptador, mostrada en el siguiente ejemplo, utiliza una componente dispatcher independiente para determinar la siguiente vista a la que se debera reenviar el control y para reenviar realmente el control a esa vista.
public class AccountingAdapter { public void setAccountInfo( RequestHelper requestHelper) { LogManager.logMessage( requestHelper.getRequest(), "Retrieving data from business tier"); // retrieve data from business tier via // delegate. Omit try/catch block for brevity. AccountDelegate delegate = new AccountDelegate(); AccountTO account = delegate.getAccount(

requestHelper.getCustomerId(), requestHelper.getAccountKey()); LogManager.logMessage( requestHelper.getRequest(), "Store account Transfer Object in request attribute"); // transport data using request object requestHelper.getRequest().setAttribute( "account", account); } }

La invocacin del servicio de negocio mediante el delegado tiene que ver con un objeto Account Transfer, que el adaptador almacena en un atributo de la peticin para utilizarlo en la vista. El siguiente ejemplo muestra accountdetails.jsp, la pgina JSP que despachar la peticin. El objeto Transfer Object se importa mediante la etiqueta estndar <jsp:useBean> y se accede a sus propiedades utilizando la etiqueta estndar <jsp:getProperty>. La vista tambin utiliza una estrategia Composite muy simple, haciendo la inclusin de la subvista trace.jsp durante la traduccin, est subvista es la responsable de guardar informacin de la presentacin slo para propsitos de ejemplo.
<html> <head><title>AccountDetails</title></head> <body> <jsp:useBean id="account" scope="request" class="corepatterns.util.AccountTO" /> <h2><center> Account Detail for <jsp:getProperty name="account" property="owner" /> </h2> <br><br> <table border=3> <tr> <td> Account Number : </td> <td> <jsp:getProperty name "account" property="number" /> </td> </tr> <tr> <td> Account Type: </td> <td> <jsp:getProperty name="account" property="type" /> </td> </tr> <tr>

<td> Account Balance: </td> <td> <jsp:getProperty name="account" property="balance" /> </td> </tr> <tr> <td> OverDraft Limit: </td> <td> <jsp:getProperty name="account" property="overdraftLimit" /> </td> </tr> </table> <br> <br> </center> <%@ include file="/jsp/trace.jsp" %> </body> </html>

Patrones Relacionados

Front Controller y View Helper El patrn Service to Worker es el resultado de combinar el patrn View Helper con un dispatcher, en coordinacin con el patrn Front Controller. Dispatcher View El patrn Dispatcher View es otro nombre para la combinacin del patrn Front Controller con un dispatcher, y el patrn View Helper. Los patrones Service to Worker y Dispatcher View son idnticos con respecto a los componentes implicados, pero son diferentes en la divisin de labores entre esos componentes. El patrn Dispatcher View siguiere relegar la recuperacin de contenido al momento en que se procesa la vista. Adems, el dispatcher juega un rol ms limitado en el control de la vista, ya que la eleccin de le vista normalmente ya est incluida en la peticin.

Dispatcher View
Contexto

El sistema controla el flujo de ejecucin y accede al proceso de presentacin, que es el responsable de generar el el contenido dinmico. Nota: El patrn Dispatcher View, igual que el patrn Service to Worker, describe una combinacin comn de otros patrones del catlogo. Estos dos macro-patrones describen la combinacin de un controlador y un dispatcher con vistas y helpers. Aunque describen esta estructura comn, cada uno enfatiza un uso diferente de los patrones.

Problema
El problema es una combinacin de los problemas resueltos por los patrones Front Controller y View Helper de la capa de presentacin. No hay un componente centralizado para manejar el control de acceso, la recuperacin de contenido, o el manejo de la vista, y hay cdigo de control duplicado esparcido por varias vistas. Adems, la lgica de negocio y la de formateo de la presentacin estn mezcladas en esas vistas, haciendo que el sistema sea menos flexible, menos reutilizable y generalmente menos resistente a los cambios. Mezclar lgica de negocio con el procesamiento de la vista tambin reduce la modularidad y proporciona una pobre separacin de roles entre los equipos de produccin Web y de desarrollo de software.

Causas

Los chequeos de autentificacin y autorizacin se completan en cada peticin. El cdigo scriptlet dentro de las vistas se debera minimizar. La lgica de negocio se debera encapsular en componentes distintos a la vista. El control de flujo es relativamente complejo y se basa en valores del contenido dinmico. La lgica de control de la vista es relativamente sofisticada, con varias vistas que potencialmente se mapean a la misma peticin.

Solucin
Combinar un controlador y un dispatcher con vistas y helpers (ver Front Controller y View Helper) para manejar peticiones de clientes y preparar una presentacin dinmica como respuesta. Los controladores delegan la recuperacin de contenido en los helpers, que manejan el relleno del modelo intermedio para la vista. Un dispatcher es el responsable del control de la vista y la navegacin y puede encapsularse dentro de un controlador o de un componente separado. Dispatcher View describe la combinacin de los patrones Front Controller y View Helper con un componente dispatcher. Aunque este patrn y Service to Worker describen una estructura similar, ambos sugieren diferentes divisiones de la labor entre los componentes. El controlador y el dispatcher tienen responsabilidades limitadas, comparadas con el patrn Service to Worker, porque la lgica de procesamiento y de

control de vista son bsicas. Adems, si no se considera necesario el control de los recursos subyacentes, se puede eliminar el controlador y el dispatcher se podra mover dentro de una vista. Aunque los patrones Service to Worker y Dispatcher View representan una combinacin de otros patrones del catlogo, el primero garantiza con su nombre una comunicacin eficiente entre los desarrolladores. Mientras que el segundo sugiere una recuperacin de contenido relegada al momento de procesamiento de la vista. En el patrn Dispatcher View, el dispatcher normalmente juega un rol moderado en el control de la vista. En el patrn Service to Worker, el dispatcher juega un rol algo ms elevado en el control de la vista. Un rol limitado para el dispatcher ocurre cuando no se utilizan recursos exteriores para poder elegir la vista. La informacin encapsulada en la peticin es suficiente para determinar la vista a la que despachar la peticin. Por ejemplo:
http://some.server.com/servlet/Controller?next=login.jsp

La nica responsabilidad del componente dispatcher en este caso es reenviar a la vista login.jsp. Un ejemplo del dispatcher jugando un rol moderado es el caso donde el cliente enva una peticin directamente al controlador con un parmetro de consulta que describe una accin a realizar:
http://some.server.com/servlet/Controller?action=login

Aqu la responsabilidad del dispatcher es traducir el nombre lgico login en el nombre del recurso de una vista apropiada, como login.jsp, y reenviar a esa vista. Para conseguir esta traduccin, el dispatcher podra acceder a recursos como un fichero de configuracin XML que especifica las vistas apropiadas a mostrar. Por otro lado, en el patrn Service to Worker, el dispatcher podra invocar servicios de negocio para determinar la vista apropiada que se debe mostrar. La estructrua compartida de Service to Worker y Dispatcher View consiste en un controlador trabajanado con un dispatcher, vistas y helpers. Estructura En la siguiente figura podemos ver el diagrama de clases que representa al patrn Dispatcher View.

Participantes y Responsabilidades La siguiente figura muestra el diagrama de secuencia que representa al patrn Dispatcher View.

Aunque las responsabilidades del controlador estn limitadas a los servicios del sistema, como la autentificacin y autorizacin, todava es beneficioso centralizar estos aspectos del sistema. Observa tambin que, al contrario que el patrn Service to Worker, el dispatcher no hace llamadas a servicios de negocio para poder completar el procesamiento de la vista. La funcionalidad del dispatcer se podra encapsular en su propio componente. Al mismo tiempo, cuando las responsabilidades del dispatcher son limitadas, como se describen en este patrn, la funcionalidad del dispatcher se puede poner en otro componente, como en el controlador o la vista.

De hecho, la funcionalidad del dispatcher podra incluso ser completada por el contenedor, en el caso donde no sea necesaria una lgica extra a nivel de la aplicacin. Un ejemplo es una vista llamada main.jsp a la que se le da el alias de first. El contenedor procesar la siguiente peticin, traduciendo el nombre del alias al nombre del recurso fsico, y reenviando directamente a ese recurso:
http://some.server.com/first --> /mywebapp/main.jsp

En este caso, nos hemos quedado con el patrn View Helper, donde la peticin la maneja directamente la vista. Como la vista es el punto de contacto inicial para manejar peticiones, normalmente se utilizan etiquetas personalizadas para realizar el procesamiento de negocio o para delegar este procesamiento a otros componentes. As, el patrn Dispatcher View describe una continuidad de escenarios relacionados, movindose de un escenario que es estructuralmente similar a Service to Worker a otro que es similar a View Helper.
Controller

El controlador normalmente es el punto de contacto inicial para manejar una peticin. El controlador maneja la autentificacin y la autorizacin, y delega en un dispatcher para hacer el control de la vista.
Dispatcher

Un dispatcher es el responsable del control de la vista y la navegacin, controlando la eleccin de la siguiente vista a mostrar y proporciona el mecanismo para dirigir el control a este recurso. Un dispatcher se puede encapsular dentro de un controlador (ver Front Controller) o puede ser un componente independiente que trabaja en coordinacin con el controlador. El dispatcher puede proporcionar reenvo esttico a la vista o podra proporcionar un mecanismo de reenvo dinmico ms sofisticado.
View

Una Vista representa una presentacin de informacin al cliente. La informacin utilizada en esta presentacin se recupera de un modelo. Los helpers soportan vistas encapsulando y adaptando un modelo para utilizarlo en una presentacin.
Helper

Un helper es el responsable de ayudar a la vista o al controlador a completar su procesamiento. As, los helpers tienen numerosas responsabilidades, incluyendo la obtencin de los datos requeridos por la vista y almacenndolos en el modelo intermedio, en cuyo caso el helper es conocido como un value bean. Adems, los helpers podran adaptar este modelo de datos para que los utilice la vista. Los helpers pueden servir

peticiones de datos desde la vista simplemente proporcionando acceso a los datos en bruto o formatendolos como contenido Web. Una vista podra trabajar con cualquier nmero de helpers, que normalmente estn implementados por componentes JavaBeans (JSP 1.0+) o componentes de etiquetas personalidas (JSP 1.1+). Adems, un helper podra representar un objeto Command o delegate.
ValueBean

Un value bean es otro nombre para un helper que es responsable de contener el estado del modelo intermedio para que lo utilice una vista.
BusinessService

Servicio de Negocio es un rol que cumple el servicio al que el cliente quiere acceder. Normalmente, se accede al servicio de negocio mediante un Business delegate. El rol del business delegate es proporcionar control y proteccin para el servicio de negocio (puedes ver el patrn "Business Delegate" ms adelante). Estrategias
Servlet Front

Ver la estrategia "Servlet Front" en el patrn Front Controller.

JSP Front

Ver la estrategia "JSP Front" en el patrn Front Controller.

JSP page View

Ver la estrategia "JSP page View" en el patrn View Helper.

Servlet View

Ver la estrategia "Servlet View" en el patrn View Helper.

JavaBean Helper

Ver la estrategia "JavaBean Helper" en el patrn View Helper.

Custom Tag Helper

Ver la estrategia "Custom Tag Helper" en el patrn View Helper.

Dispatcher in Controller

Ver la estrategia "Dispatcher en Controller" en el patrn Front Controller. Como hemos visto, los patrones Service to Worker y Dispatcher View sugieren una continuidad, donde el comportamiento se ha encapsulado ms cerca de la vista o se ha movido haca atrs en el flujo de proceso. La siguiente figura muestra las interacciones para esta estrategia:

El controlador no crea explicitmente un objeto dispatcher. En vez de eso, el controlar tiene cuidado de reenviar a la vista. Alternativamente, se podra implementar un dispatcher en el que el controldor puede delegar la funcin de reenvo.
Dispatcher in View

Si el controlador se eliminara debido a su rol limitado, el dispatcher se podra mover a una vista. Este diseo puede ser til en casos donde es tpico que una vista mapee a una peticin especfica, pero donde se podra utilizar de forma poco frecuente un vista secundaria. Por ejemplo, basndose en la informacin de la peticin o los resultados de algn procesamiento de la vista, un helper de etiqueta personalizada en la vista podra dirigir el control a una vista secundaria. Un caso tpico es cuando una peticin de cliente es reenviada a una vista especfica, y ser servida por esa vista en cualquier otro caso. Consideremos el caso donde el usuario no se ha autentificado, pero pide acceso a unas pginas JSP protegidas de la site. Como la site tiene slo unas pocas pginas JSP protegidas, y el contenido dinmico es limitado, la autentificacin se puede realizar dentro de esas pginas JSP, en lugar de utilizar un controlador centralizado para toda la site. Esas pginas que necesitan autentificacion incluyen un helper de etiqueta personalizada al principio de la pgina. Este helper realiza el chequeo de autentificacin y muestra la pgina

al usuario o lo reenva a la pgina de autentificacin. La siguiente figura representa este escenario:

Transformer Helper

Ver la estrategia "Transformer Helper" en el patrn View Helper.

Consecuencias

Centraliza el Control y Mejora la Modularidad y la Reutilizacin Este patrn sugiere proporcionar un lugar central para manejar los servicios del sistema y la lgica de negocio entre varias peticiones. El contolador maneja el procesamiento de la lgica de negocio y el manejo de peticiones. Hay que tener en cuenta, que como control centralizado, es posible introducir un slo unto de fallo. Mejora el Particionamiento de la Aplicacin La utilizacin de helpers resulta en una separacin clara entre la vista y el procesamiento de negocio en una aplicacin. Los helpers, en la forma de JavaBeans (JSP 1.0+) o etiquetas personalizadas (JSP 1.1+), proporcionan un lugar donde construir la lgica de negocio fuera de la pgina JSP. Si la lgica de negocio se deja dentro de la pgina JSP, los grandes proyectos resultan embrollados. Mejora la Separacin de Roles Al separar la lgica de formateo de la lgica de negocio de la aplicacin tambin se reducen las dependencias de los mismos recursos entre individuos que cumplen diferentes roles. Sin esta separacin, por ejemplo, un desarrollador de sofware poseera cdigo que est embebido dentro de marcas HTML, mientras que un miembro del equipo de produccin Web necesitara modificar la distribucin de una pgina y disear componentes que estn mezclados con lgica de negocio. Como

ningn individuo que cumple estos roles est familiarizado con las implementaciones especficas del trabajo del otro individuo, se puede llegar a un punto de confusin en que las modificaciones accidentales introduzcan errores el sistema.

Cdigo de Ejemplo
El siguiente cdigo de ejemplo muestra una implementacin del patrn Dispatcher View, utilizando un servlet controlador y una vista con helpers JavaBean y de etiquetas personalizadas. La implementacin incluye las estrategias Servlet Front, Dispatcher in Controller, JSP View, JavaBean Helper y Custom Tag Helper. Tambin utiliza una vista compuesta muy bsica, mostrada en la siguiente imagen:

El siguiente ejemplo muestra el servlet controlador que simplemente completa el chequeo de autentificacin y pasa el control a la vista apropiada. Observa que el controlador no delega directamente a ningn componente helper para poder hacer llamadas a la capa de negocio mediante Delegate. Ests responsabilidades se han relegado a la vista, que se llama accountdetails.jsp. El cdigo de ejemplo utiliza un LogManager para guardar los mensajes.
public class Controller extends HttpServlet { /** Processes requests for both HTTP * <code>GET</code> and <code>POST</code> methods. * @param request servlet request * @param response servlet response */

protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { String nextview; try { LogManager.recordStrategy(request, "Dispatcher View", " Servlet Front Strategy; " + "JSP View Strategy; Custom tag helper Strategy"); LogManager.logMessage(request, getSignature(), "Process incoming request. "); // Use a helper object to gather parameter // specific information. RequestHelper helper = new RequestHelper(request, response); LogManager.logMessage(request, getSignature(), " Authenticate user"); Authenticator auth = new BasicAuthenticator(); auth.authenticate(helper); //This is an oversimplification for the sake of // simplicity. Typically, there will be a // mapping from logical name to resource name at // this point LogManager.logMessage(request, getSignature(), "Getting nextview"); nextview = request.getParameter("nextview"); LogManager.logMessage(request, getSignature(), "Dispatching to view: " + nextview); } catch (Exception e) { LogManager.logMessage( "Handle exception appropriately", e.getMessage() ); /** ApplicationResources provides a simple API * for retrieving constants and other * preconfigured values**/ nextview = ApplicationResources.getInstance(). getErrorPage(e); } dispatch(request, response, nextview); } /** Handles the HTTP <code>GET</code> method. * @param request servlet request * @param response servlet response */ protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { processRequest(request, response); } /** Handles the HTTP <code>POST</code> method.

* @param request servlet request * @param response servlet response */ protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, java.io.IOException { processRequest(request, response); } /** Returns a short description of the servlet. */ public String getServletInfo(){ return getSignature(); } public void init(ServletConfig config) throws ServletException { super.init(config); } public void destroy() { } /** * dispatcher method */ protected void dispatch(HttpServletRequest request, HttpServletResponse response, String page) throws javax.servlet.ServletException, java.io.IOException { RequestDispatcher dispatcher = getServletContext(). getRequestDispatcher(page); dispatcher.forward(request, response); } private String getSignature() { return "DispatcherView-Controller"; } }

Observa que la vista utiliza helpers de etiquetas personalizadas para controlar la recuperacin de contenido. ya que esta actividad no se realiz en el controlador. Cuando se utilizan las etiquetas personalizadas de esta forma, normalmente se convierten en estrechas fachadas para componentes solitarios en los que delegar para completar este procesamiento. De esta forma, la lgica de procesamiento general est pobremente acoplada a la implementacin de la etiqueta. Si no se utilizan etiquetas personalizadas con Dispatcher View, la pgina JSP se terminar llenando de cdgio scriptlet, una situacin que debemos evitar.

<%@ taglib uri="/web-INF/corepatternstaglibrary.tld" prefix="corepatterns" %> <html>

<head><title>AccountDetails</title></head> <body> <corepatterns:AccountQuery queryParams="custid,acctkey" scope="request" /> <h2><center> Account Detail for <corepatterns:Account attribute="owner" /></h2> <br><br> <tr> <td>Account Number :</td> <td><corepatterns:Account attribute="number" /></td> </tr> <tr> <td>Account Type:</td> <td><corepatterns:Account attribute="type" /></td> </tr> <tr> <td>Account Balance:</td> <td><corepatterns:Account attribute="balance" /></td> </tr> <tr> <td>OverDraft Limit:</td> <td><corepatterns:Account attribute="overdraftLimit" /></td> </tr> <table border=3> </table> </corepatterns:AccountQuery> <br> <br> </center> <%@ include file="/jsp/trace.jsp" %> </body> </html>

Patrones Relacionados

Front Controller y View Helper El patrn Dispatcher View es el resultado de combinar el patrn View Helper con un dispatcher, en coordinacin con el patrn Front Controller. Service to Worker El patrn Service to Worker es otro nombre para la combinacin del patrn Front Controller con un dispatcher, y el patrn View Helper. Los patrones Service to Worker y Dispatcher View son idnticos con respecto a los componentes implicados, pero son diferentes en la divisin de labores entre esos componentes. El patrn Dispatcher View siguiere relegar la recuperacin de contenido al momento en que se procesa la vista. Adems, el dispatcher juega un rol ms limitado en el

control de la vista, ya que la eleccin de le vista normalmente ya est incluida en la peticin.