Criterio de evaluación (I)

Transcripción

1 Tiles en Struts

2 Introducción (I) Componentes HTML y JSP comunes, como la cabecera (Header),el cuerpo (Body), el pie de pagina (Footer), el menu, y la busqueda (Search). Para explorar las soluciones de plantillas (templates) y de Layout(esquemas), usaremos el framework Tiles. El "framework Tiles component view" es conocido como tiles.

3 Introducción (II) Este framework usa un archivo de configuración. Este framework no solo te permite reutilizar tiles, sino que también que permite organizar layouts. Para explorar las soluciones mas poderosas y flexibles, investigaremos la integración entre Tiles y Struts. Struts es un framework open source para desarrollar aplicaciones web usando el famoso modelo MVC. Struts viene con un conjunto amplio de etiquetas reutilizables, el cual es perfeccionado por la librería de etiquetas de Tiles.

4 Criterio de evaluación (I) Número de páginas. La solución debe esforzarse por reducir el numero de páginas HTML y JSP. El numero de páginas incrementa la complejidad de desarrollo, de administración y mantenimiento de la aplicación de una manera drástica. Repetición de código. Casi siempre repetir es malo. Cuanto mas código repetido más difícil es la tarea de desarrollar y mantener la aplicación. Un simple cambio puede desencadenar una serie de cambios en cascada en muchas páginas diferentes con consecuencias imprevisibles. Una manera práctica de lograr reusabilidad es eliminando código repetido.

5 Criterio de evaluación (II) Control del Layout. Si repetir código es malo, repetir la lógica de layout y código es peor. Separar la lógica y el comportamiento de los componentes de la vista a través de muchas JSP puede ser la receta para un desastre. Lograr reutilizar la plantilla y la lógica de los layout es una forma mejor, que solo reutilizar componentes de vista.

6 Criterio de evaluación (III) Acoplamiento El grado de interacción entre entidades. Los ingenieros de software han pensado una y otra vez sobre como minimizar el acoplamiento entre clases no relacionadas, paquetes y demás. Nosotros podemos aplicar los mismos principios a los componentes de vista.

7 Criterio de evaluación (IV) Complejidad La complejidad aumenta la dificultad de desarrollo y mantenimiento, haciendo la solución mas compleja menos satisfactoria. La complejidad crece rápido y lo que parecía una solución sencilla se torna rápidamente en un gran enredo teniendo que añadir mas piezas.

8 Solución I Jsp a: <html> <body> Header a's body... Footer </body> </html> Jsp b: <html> <body> Header b's body... Footer </body> </html> La solución 1 no es deseable porque cambios en un componente de vista requiere cambios de cada una de las paginas. Cada una de las paginas es responsable de colocar (layout) sus componentes de vista. Esta solución simple carece de previsión. Con mucho HTML y JSP repetido, reducimos el número de páginas pero a costa de un pesado coste de mantenimiento.

9 Solución II (I) Jsp a: <html> <body> <%-- include header --%> <jsp:include page="/header.jsp" /> a's body... <%-- include footer --%> <jsp:include page="/footer.jsp" /> </body> </html> Jsp b: <html> <body> <%-- include header --%> <jsp:include page="/header.jsp" /> b's body... <%-- include footer --%> <jsp:include page="/footer.jsp" /> </body> </html> La cabecera y el pie de página, son divididos usando el mecanismo JSP include.

10 Solución II (II) Considere este header.jsp: Header Considere este footer.jsp: Footer La solución 2 soluciona algunas de las limitaciones mayores de la solución 1. Solo se necesita cambiar los componentes de vista comunes una vez, por tanto, esta solución elimina la duplicidad de código y simplifica el mantenimiento. Esta solución incrementa un poco el numero de páginas, pero reduce drásticamente el numero el firme acoplamiento entre componentes de vistas y otras páginas. Esta solución es simple y es usa en muchos aplicaciones reales, sin embargo tiene un inconveniente, si cambiamos el layout de la aplicación, tendremos que hacerlo en cada página. Supone un caro y prohibitivo cambio. Esta solución alcanza la reutilización de componentes, pero no de las plantillas y de la lógica de layout.

11 Solución III Insert Tiles Jsp a: taglib uri="/web- INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> a's body... <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html> Jsp b: taglib uri="/web- INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> b's body... <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html> La solución 3 usa el mecanismo insert de Tiles, usando esto incluimos el componente de vista en el sitio correspondiente. En todo los aspectos esta solución es idéntica a la solución 2, con sus ventajas y sus desventajas.

12 Solución IV (I) Separando el cuerpo Jsp a: taglib uri="/web- INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> <%-- include body --%> <tiles:insert page=" <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html> Jsp b: taglib uri="/web- INF/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert page="/header.jsp" flush="true"/> <%-- include body --%> <tiles:insert page="bbody.jsp" flush="true"/> <%-- include footer --%> <tiles:insert page="/footer.jsp" flush="true"/> </body> </html>

13 Solución IV (II) Separando el cuerpo JSP abody.jsp: a's body... JSP bbody.jsp: b's body... Esto limita el cambio del cuerpo a su página y además permite reutilizarlo en otras partes. Eliminando la repetición y la duplicidad. Como las otras soluciones, cada pagina crea todavía su propio layout. Por tanto, aquí tampoco tiene una política sobre los layout o esquemas.

14 Solución V (I) Plantillas Usando la característica de crear plantillas podemos definir los Layouts como plantillas. Desde estos layouts, podemos insertar marcadores de lugar en vez del actual componente de vista usando la etiqueta de Tiles insert. Así, para todos los componentes esta página define un layout reutilizable. Jsp layout.jsp <%@ taglib uri="/web-inf/tiles.tld" prefix="tiles" %> <html> <body> <%-- include header --%> <tiles:insert attribute="header"/> <%-- include body --%> <tiles:insert attribute="body"/> <%-- include footer --%> <tiles:insert attribute="footer"/> </body> </html>

15 Solución V (II) Plantillas Jsp a: <%@ taglib uri="/web- INF/tiles.tld" prefix="tiles" %> <tiles:insert page="/layout.jsp" flush="true"> <tiles:put name="header" value="/header.jsp"/> <tiles:put name="body" value="/abody.jsp"/> <tiles:put name="footer" value="/footer.jsp"/> </tiles:insert> Jsp b: <%@ taglib uri="/web- INF/tiles.tld" prefix="tiles" %> <tiles:insert page="/layout.jsp" flush="true"> <tiles:put name="header" value="/header.jsp"/> <tiles:put name="body" value="/bbody.jsp"/> <tiles:put name="footer" value="/footer.jsp"/> </tiles:insert> La mayor ventaja de esta solución es que encapsula el comportamiento del layout, reduce drasticamente el acoplamiento del entre los componentes. Sin embargo, incrementa la complejidad introduciendo otra página para el layout. Entender y implementar el mecanismo de las plantillas también puede ser difícil al principio.

16 Solución VI (I) Struts y Tiles La página de layout anterior layout.jsp contiene código HTML y JSP para organizar los componentes. La páginas a.jsp y b.jsp no contiene código HTML ninguno; estas solo contienen etiquetas Tiles para insertar los componentes necesarios. No seria agradable especificar todos las páginas de contenido en un solo archivo XML de configuración? LLamaremos a este archivo tiledefinitions.xml

17 Solución VI (II) Struts y Tiles <?xml version="1.0" encoding="iso "?> <component-definitions> <definition name="adef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value="/abody.jsp"/> </definition> <definition name="bdef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value="/bbody.jsp"/> </definition> <definition name="cdef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value="/cbody.jsp"/> </definition> </component-definitions>

18 Solución VI (III) Struts y Tiles La solución 6 elimina todas las páginas de contenido a.jsp, b.jasp, poniendo sus definiciones en un archivo XML. Pero si no existe un recurso llamado a.jsp, como podemos solicitarlo? Y mas importante como podemos acceder al archivo XML tiledefinitions.xml. La integracion entre Strust y Tiles lo permite. Además, la configuración uniforme de parámetros de Struts, nos permitirá especificar el archivo de configuración como otro parámetro en el web.xml. Especificando el parámetro definition-config posibilita a Struts encontrar y conocer acerca de la definición Tiles.

19 Solución VI (IV) Struts y Tiles  <servlet> <servlet-name>action</servlet-name>  <servlet-class> org.apache.struts.tiles.actioncomponentservlet </servlet-class> <init-param> <param-name>definitions-config</param-name> <param-value> /WEB-INF/tileDefinitions.xml </param-value> </init-param>...  <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>... </servlet>

20 Solución VI (V) Struts y Tiles Ahora definimos una acción Struts, la cual devuelve una definición especifica del archivo de configuración con el valor éxito import org.apache.struts.action.*; import javax.servlet.http.*; public class DoFirst extends Action { public ActionForward execute( ActionMapping amapping, ActionForm aform, HttpServletRequest arequest, HttpServletResponse aresponse) { return amapping.findforward("success"); } }

21 Solución VI (VI) Struts y Tiles No podemos invocar una definición directamente desde el navegador, pero puedes invocar una desde Struts, como si esta fuese un recurso actual. Definimos las acciones struts en el archivo struts-config.xml

22 Solución VI (VII) Struts y Tiles <action path="/a" type="dofirst"> <forward name="success" path="adef"/> </action> <action path="/b" type="dofirst"> <forward name="success" path="bdef"/> </action> <action path="/c" type="dofirst"> <forward name="success" path="cdef"/> </action>

23 Solución VI (VIII) Struts y Tiles La solución 6 tiene la ventaja de establecer todas las definiciones en un archivo de configuración XML, reduce el numero de páginas. Pero al introducir Struts aumenta notablemente el grado de complejidad.

24 Solución VII (I) Herencia en Tiles En el archivo de configuración que todas las definiciones de las páginas son parecidas. Estas definen tres componentes, cabecera cuerpo y pie de página, de las cuales dos de ellas (la cabecera y el pie de página) son siempre iguales. Una poderosa característica de Tiles es la herencia entre definiciones. Por tanto, podemos crear una definición base y dejar que las demás hereden de esta. La definición base solo debe suministrar la características. La definición hija solo debe definir sus componentes únicos.

25 Solución VII (II) Herencia en Tiles <?xml version="1.0" encoding="iso "?> <component-definitions> <definition name="basedef" path="/layout.jsp"> <put name="header" value="/header.jsp"/> <put name="footer" value="/footer.jsp"/> <put name="body" value=""/> </definition> <definition name="adef" extends="basedef"> <put name="body" value="/abody.jsp"/> </definition> <definition name="bdef" extends="basedef"> <put name="body" value="/bbody.jsp"/> </definition> <definition name="cdef" extends="basedef"> <put name="body" value="/cbody.jsp"/> </definition> </component-definitions>

26 Qué solución es la mejor? La mejor solución depende de las necesidades del proyecto y sus reqerimientos y de tus habilidades y conocimientos en el desarrollo y mantenimiento de aplicaciones web. La solución básica es demasiado simple. No es recomendable porque va en contra de los principios de las buenas practicas de la ingeniería del software. Si ya estamos usando Struts entonces podremos aprovecharnos de la influencia del la integración de Tiles y Struts, para crear una poderosa solución.