Introducción a Struts
Prerequisitos
Esta guía de usuario está escrita para desarrolladores Web activos, y asume que tenemos conocimientos sobre como funcionan las aplicaciones Web Java. Antes de empezar, deberíamos entender los básico de estas tecnologías:
Si hemos creamos aplicaciones Web sobre otras plataformas, probablemente podremos seguir, y luego visitar las referencias arriba indicadas cuando lo necesitemos. Estas son tecnologías corazón que se utilizan en casi todos los proyectos desarrollados en Java
Prefacio: Un paso hacia el pasado (o una breve historia de Struts)
Cuando se inventaron los Servlets Java, muchos programadores se dieron cuenta de que eran una Buena Cosa. Eran más rápidos y más potentes que el CGI estándard, portables, y extensibles infinitamente.
Pero escribir infinitas sentencias println() para enviar HTML al navegador era tirano y problemático. La respuesta fueron las JavaServer Pages, que nos dejaron escribir servlets dentro de ellas. Ahora los desarrolladores podían mezclar fácilmente HTML con código Java, y tener todas las ventajas de los servlets. ¡El cielo era el límite!
Las aplicaciones web Java se convirtieron rápidamente en "centradas-en-JSP". Esto, por sí sólo no era en una mala cosa, pero hacían poco por resolver problemas de control de flujo y otros problemas endémicos de las aplicaciones Web.
Claramente se necesitaba otro modelo...
Muchos desarrolladores inteligentes se dieron cuenta que las JavaServer Pages Y y los servlets se podrían usar juntos para desplegar aplicaciones web. Los servlets podrían ayudar con el control de flujo, y las JPSs podrían enfocarse en el negocio odioso de escribir HTML. Usar JSP y servlets juntos se ha dado ha conocer como el Modelo 2 (cuando usar sólo JSPs era el Modelo 1).
Por supuesto, no hay nada nuevo bajo el Sol (Sun)... y muchos han apuntado rápidamente que el Modelo 2 de JSPs sigue el clásico patrón de diseño Modelo-Vista-Controlador de SmallTalk. Ahora es muy común usar los terminos Modelo 2 y MVC indistintamente.
El proyecto Struts lo lanzó en Mayo del 2000, Craig R. McClanahan para proporcionar un marco de trabajo MVC estándard a la comunidad Java. En Julio del 2001, se liberó Struts 1.0, e IOHO, el modelo 2 de desarrollo Java nunca será lo mismo.
El Patrón de Diseño ('MVC') Modelo-Vista-Controlador
En el patrón de diseño MVC, el flujo de la aplicación está dirigido por un Controlador central. El Controlador delega solicitudes - en nuestro caso, solicitudes HTTP -- a un manejador apropiado. Los manejadores están unidos a un Modelo, y cada manejador actúa como un adaptador entre la solicitud y el Modelo. El Modelo representa, o encapsula, un estado o lógica de negocio de la aplicación. Luego el control normalmente es devuelto a través del Controlador hacia la Vista apropiada. El reenvío puede determinarse consultando los conjuntos de mapeos, normalmente cargados desde una base de datos o un fichero de configuración. Esto proporciona un acoplamiento cercano entre la Vista y el Modelo, que puede hacer las aplicaciones significativamente más fáciles de crear y de mantener.
Introducción al Marco de Trabajo de Struts
Creyendo en el patrón de diseño Modelo-Vista-Controlador, las aplicaciones Struts tiene tres componentes principales: un servlet controlador, que está proporcionado por el propio Struts, páginas JSP (la "vista"), y la lógica de negocio de la aplicación (o el "modelo"). Veamos como esto funciona todo junto.
El servlet controlador Struts une y enruta solicitudes HTTP a otros objetos del marco de trabajo, incluyendo JavaServer Pages y subclases org.apache.struts.action.Action porporcionadas por el desarrollador Struts. Una vez inizializado, el controlador analiza un fichero de configuración de recursos, La configuración de recursos define (entre otras cosas) los org.apache.struts.action.ActionMapping para una aplicación. El controlador usa estos mapeos para convertir las solicitudes HTTP en acciones de aplicación.
Un ActionMapping normalmente especificará:
- una path solicitado (o "URI"),
- El tipo objeto (subclase de Action) para actuar sobre la solicitud,
- y otras propiedades según se necesite.
El objeto Action puede manejar la solicitud y responder al cliente (normalmente un navegador Web), o indicar a que control debería ser reenviado. Por ejemplo, si un logín tiene éxito, una acción logín podría desear reenviar la petición hacia el mainMenu.
Los objetos Action tienen acceso al servlet controlador de la aplicación, y por eso tienen acceso a los métodos del servlet. Cuando se reenvia un control, un objeto Action puede reenviar indirectametne uno o más objetos compartidos, incluyendo JavaBeans, situándolos en una de las colecciones estándard compartidas por los servlets Java.
Un objeto acción puede crear un bean de tarjeta de compra, o un ítem de la tarjeta, situando el bean en la colección de sesión, y luego reenviando el control a otro mapeo. Este mapeo podría usar una página JavaServer Page para mostrar los contenidos de la tarjeta del usuario. Como cada cliente tiene su propia sesión, cada uno también tendrá su propia tarjeta de compra. En una aplicación Struts, la mayoría de la lógica del negocio se puede representar usando JavaBeans. Una Action puede llamar a las propiedades de un JavaBean sin conocer realmente como funciona. Esto encapsula la lógica del negocio, para que la Action pueda enfocarse en el manejo de errores y dónde reenviar el control.
Los JavaBeans también se pueden usar para manejar formularios de entrada. Un problema clave en el diseño de aplicaciones Web es retener y validar lo que el usuario ha introducido entre solicitudes. Con Struts, podemos definir un conjunto de clases bean formulario, subclasificando org.apache.struts.action.ActionForm, y almacenar fácilmente los datos de un formulario de entrada en estos beans formularios. El bean se graba en una de las colecciones estándard o de contexto compartidas, por eso puede ser usado por otros objetos, especialmente un objeto Action.
El bean de formulario puede usarlo una JSP para recoger datos del usuario ... por un objeto Action para validar los datos introducidos por el usuario ... y luego de nuevo por la JSP para rellenar los campos del fomulario. En el caso de validación de errores, Struts tiene un mecanismo compartido para lanzar y mostrar mensajes de error.
Un bean de formulario Struts se declara en la configuración de recursos definida en un fichero fuente Java, y enlazado a un ActionMapping usando un nombre de propiedad comnún. Cuando una solicitud llama a un Action que usa un bean de formulario, el servlet controlador recupera o crea el bean formulario, y lo pasa el objeto Action. Este objeto entonces puede chequear los contenidos del bean de formulario antes de que su formulario de entrada se muestre, y también la cola de mensajes a manejar por el formulario. Cuando esta listo, el objeto Action puede devolver el control con un reenvio a su formulario de entrada, usando un JSP. El controlador puede responder a la solicitud HTTP y dirigir al cliente a la JavaServer Page.
El marco de trabajo Struts incluye etiquetas personalizadas que pueden rellenar automáticamente los campos de un formulario o un bean de formulario. Lo único que la mayoría de las páginas JSP necesitan saber sobre el resto del marco de trabajo son los nombres de los campos apropiados y dónde enviar el formulario. Los componentes como los mensajes "encolados" por el Action pueden salir usando una simple etiqueta personalizada. También se pueden definir otras etiquetas especificas de la aplicación para ocultar detalles de implementación de las páginas JSPs.
Las etiquetas personalizadas en el marco de trabajo Struts están diseñadas para usar las características de internacionaización incluidas en la plataforma Java. Todas las etiquetas de campos y los mensajes pueden recuperarse desde un recurso de mensajes, y Java puede proporcionar automáticamente el recurso correcto para el idioma y país de un cliente. Para proporcionar mensajes para otro idioma, simplemente añadimos otro fichero de recurso.
Junto al internacionalismo, otros beneficios de esta aproximación son las etiquetas consistentes entre formularios, y la posibilidad de revisar todas las etiquetas y mensajes desde una localización central.
Para la aplicación más simple, un objeto Action podría algunas veces manejar la lógica de negocio asociada con una solicitud. Sin embargo, en lamayoría de los casos, un objeto Action, debería llamar a otro objeto, normalmente un JavaBean, para realizar la lógica de negocio real. Esto permite al objeto Action enfocarse en el manejo de errores y el control de flujo, en vez de en la lógica del negocio. Para permitir su reutilizacion en otras plataformas, los JavaBeans de lógica de negocio no deberían referirse a ningún objeto de aplicación Web. El objeto Action debería traducir los detalles necesarios de la solicitud HTTP y pasarlos a los beans de la lógica del negocio como variables normales de Java.
Por ejemplo, en una aplicación de base de datos:
- Un bean de lógica de negocio conectaría y consultaría la base de datos,
- El bean de lógica de negocio devolvería el resultado al objeto Action,
- El objeto Action almacenarçia el resultado en un bean formulario en la solicitud,
- La JavaServer Page mostraría el resultado en un formulario HTML.
Ni el objeto Action ni la página JSP necesitan saber (o no les importa) de dónde viene le resultado. Sólo necesitan saber cómo empaquetarlo y mostrarlo.
El resto de esta guía de usuario explica varios componentes Struts en gran detalle. La versión Struts también incluye varias Guías de Desarrollo que cubren varios aspectos de los marcos de trabajo, junto con aplicaciones de ejemplo, el API estándard JavaDoc, y, por supuesto, el código fuente completo!
Struts se distribuye bajo la licencia de la Apache Software Foundation. El código tiene copyright pero es gratuito para usarlo en cualquier aplciación. Puedes ver las especificaciones en ASF license.
El Modelo: Estado del Sistema y JavaBeans de la Lógica de Negocio
La parte del Modelo de un sistema basado en MVC puede dividirse en conceptos--el estado interno del sistema, y las acciones que pueden tomarse para cambiar el estado. En términos gramáticos, podríamos pensar en la información de estado como nombres (cosas) y las acciones como verbos (cambios del estado de esas cosas).
Generalmente, nuestra aplicación representará un estado interno del sistema como un conjunto de uno o más JavaBeans, con propiedades que representan los detalles del estado. Dependiendo de la complejidad de nuestra aplciación, estos beans pueden ser autocontenidos (y saber como guardar su información de estado persistentemente de alguna forma), o podrían ser fachadas que saben cómo recuperar información de fuentes externas (como una base de datos) cuando es solicitado. Los Entity Enterprise JavaBeans (Entity EJBs) también se usan comunmente para representar estados internos.
Las aplicaciones de gran escala normalmente representarán un conjunto de posibles acciones lógicas de negocio con métodos que pueden ser llamados sobre los beans que mantienen su información de estado. Por ejemplo, podríamos tener un bean de una tarjeta de compra, almacenado en el ámbito de sesión por cada usuario actual con las propiedades que representan el conjunto actual de ítems que el usuario ha decidio comprar. Este bean también podría tener un método checkOut() que autorice la tarjeta de crédito del usuario, y envíe el pedio al almacen para que sea remitido. Otros sistemas representarán las acciones disponibles de forma separada, quizas como Session Enterprise JavaBeans (Session EJBs).
Por otro lado, en algunas aplicaciones de menor escala, las acciones disponibles podrían estar embebidas dentro de clases Action que son parte del rol del Controlador. Esto es apropiado cuando la lógica es muy simple, o donde no está contemplada la reutilización de la lógica de negocio en otros entornos. El marco de trabajo Struts soporta cualquiera de estas aproximaciones, pero nosotros recomendamos encarecidamente separar la lógica de negocio ("cómo se hace") del rol que juegan las clases Action ("que hace").
La Vista: Páginas JSP y Componentes de Presentación
La parte de la Vista de una aplicación basada en Struts generalmente está construida usando tecnología JavaServer Pages (JSP). Las págnas JSP pueden contener texto HTML estático (o XML) llamado "plantilla de texto", además de la habilidad de insertar contenido dinámico basado en la interpretación (en el momento de solicitud de la página) de etiquetas de acción especiales. El entorno JSP incluye un conjunto de etiquetas estándard, como <jsp:useBean>. Además, hay una facilidad estándard para definir nuestras propias etiquetas, que están organizadas en "librerías de etiquetas personalizadas".
Struts incluye una extensa librería de etiquetas personalizadas que facilitan la creación de interfaces de usuario que están completamente internacionalizados, y que interactúan amigablemente con beans ActionForm que son parte del Modelo del sistema. El uso de estas etiquetas se explica más adelante en detalle.
Además de las páginas JSP y la acción y las etiquetas personalizadas que contienen, normalmente los objetos de negocio necesitan poder dibujarse a sí mismos en HTML (o XML), basándose en su estado actual en el momento de la solicitud. La salida renderizada desde dichos objetos puede incluirse fácilmente en una página JSP resultante usando la etiqueta de acción estándard <jsp:include>.
El Controlador: ActionServlet y ActionMapping
La parte Controlador de la aplicación está enfocada en las solicitudes recibidas desde el cliente (normalmente un usuario ejecutando un navegador Web), decidiendo qué función de la lógica de negocio se va a realizar, y luego delegando la responsabilidad para producir la siguiente fase del interface de usuario en un componente Vista apropiado. En Struts, el componente principal del Controlador es un servlet de la clase ActionServlet. Este servlet está configurado definiendo un conjunto de ActionMappings. Un ActionMapping define un path que se compara contra la URI solicitada de la solicitud entrante, y normalmente especifica el nombre totalmente cualificado de clase de una clase Action. Todas las Actions son subclases de org.apache.struts.action.Action. Las acciones encapsulan la lógica del negocio, interpretan la salida, y por último despachan el control al componente Vista apropiado para la respuesta creada.
Struts también soporta la habilidad de usar clases ActionMapping que tienen propiedades adicionales más allá de las estándard requeridas para operar el marco de trabajo. Esto nos permite almacenar información adicional específica de nuestra aplciación, pero aún utiliza las características restantes del marco de trabajo. Además, Struts nos permite definir nombres lógicos para los controles a los que se debería reenviar para que un método actión pueda preguntar por la página "Main Menu" (por ejemplo), sin saber el nombre real de la página JSP correspondiente. Estas características nos ayudan a separar la lógica de control (qué hacer) de la lógica de la vista (cómo se renderiza).
Tutoriales
