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:
- La secuencia Solicitud/Respuesta HTTP.
La fuente can�nica para esto es RFC 2616 - Hypertext Transfer Protocol (HTTP/1.1). - Java Servlets.
Un buen lugar para empezar es Sun Servlet product page y Sun Java Tutorials. - JavaServer Pages (JSP).
De igual forma, un buen lugar para emepzar es la Sun JSP product page y Sun Java Tutorials. - JavaBeans.
Muchas clases Struts est�n escritas como JavaBeans. Si no has trabajado antes con JavaBeans, puedes ver la p�gina Sun JavaBean product page y Sun Java Tutorials.
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).