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:

• 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).
Construir los Componentes del Modelo

Introducción

Muchos documentos de requerimientos usados para construir aplicaciones Web se enfocan en la Vista. Sin embargo,
deberíamos asegurarnos que también está claramente definido el procesamiento requerido por cada solicitud enviada desde la
perspectiva del Modelo. En general, el desarrollador de componentes del Modelo se enfocará en la creación de clases
JavaBeans que soporten todos los requerimientos de funcionalidad. La natural precisión de los beans requeridos por una
aplicación particular variará mucho dependiendo de esos requerimientos, pero generalmente pueden clasificarse en varias
categorías descritas abajo. Sin embargo, primero es útil una breve revisión del concepto de "ámbito" en relación con los beans
y JSP.

Los JavaBeans y el Ámbito

Dentro de una aplicación basada en web, los Javabeans pueden almacenarse en (y ser accedidos desde) varias colecciones
de "atributos" diferentes. Cada colección tiene diferentes reglas para el tiempo de vida de esa colección, y la visibilidad de los
Beans almacenados en ella. Juntos, las reglas que definen el tiempo de vida y la visiblidad se llama el ámbito de esos beans.
La especificación JavaServer Pages (JSP) define las elecciones de ámbito usando los siguientes términos (con el concepto del
API Servlet equivalente entre paréntesis):

• page - Beans que son visibles dentro de una sóla página JSP, para el tiempo de vida de la solicitud actual (Variables
locales del método service() )
• request - Beans que son visibles dentro de una sóla página JSP, así como EN cualquier página o servlet que esté
incluido en esta página, o reenviado por esta página. (Atributos Request).
• session - Beans que son visibles para todas las páginas JSP y los servlets que participan en una sesión de usuario
particular, a través de una o más solicitudes. (Atributos Session).
• application - Beans que son visibles para todas las páginas JSP y los servlets que forman parte de una aplicación Web.
(Atributos de contexto Servlet).

Es importante recordar que las páginas JSP y los servlets, al igual que las aplicaciones Web comparten los mismos conjuntos
de colecciones de beans. Por ejemplo, un Bean almacenado como un atributo request en un servlet como este:

MyCart mycart = new MyCart(...);

request.setAttribute("cart", mycart);

es inmediatamente visible a una página JSP a la que se reenvíe este servlet, usando una etiqueta de acción estándard como
esta:

<jsp:useBean id="cart" scope="request"

class="com.mycompany.MyApp.MyCart"/>

Beans ActionForm

Nota: los beans ActionForm están realmente más cercanos a la Vista que al Modelo.

El marco de trabajo Struts generalmente asume que hemos definido un bean ActionForm (es decir, una clase Java que
extiende la clase ActionForm) por cada formulario de entrada necesario en nuEstra aplicación. Los beans ActionForm algunas
veces son sólo llamados "beans formuLario". Si declaramos dichos beans en nuestro fichero de configuración ActionMapping
(ver "Construir los Componentes del Controlador"), el servlet controlador Struts realiza automáticamente los siguientes servicios
por nosotros, antes de llamar al método Action apropiado:

• Chequea en la sesión de usuario si hay un ejemplar de un bean de la clase apropiada, bajo la clave apropiada.
• Si no está disponible dicho bean en el ámbio de la sesión, se crea uno nuevo automáticamente y se añade a la sesión
de usuario.
• Por cada parámetro de la solicitud cuyo nombre corresponda con el nombre de una propiedad del bean, se llamará al
correspondiente método set(). Esto opera de una forma similar a la acción JSP estándard <jsp:setProperty> cuando
usamos el comodín asterisco para seleccionar todas las propiedades.
• El bean ActionForm actualizado será pasado al método perform() de la clase Action cuando es llamado, haciendo que
esos valores estén disponibles inmediatamente.

Cuando codifiquemos nuestros beans ActionForm, debemos tener en mente los siguientes principios:

• La propia clase ActionForm no requiere que se implemente ningún método específico. Se usa para identificar el rol que
esos beans particulares juegan en la arquitectura general. Normalmente, un bean ActionForm sólo tendrá metodos
setxxx() y getxxx(), sin lógica de negocio.
 • El objeto ActionForm también ofrece un mecanismo de validación estándard. Si sobreescribimos un método "stub", y
proporcionamos mensajes de error en el recurso de aplicación estándard, Struts validará automáticamente la entrada
del formualrio (usando nuestro método). Ver Validación del Formulario para más detalles. Por supuesto, también
podemos ignorar la validación de ActionForm y proporcionar nuestro propio objeto Action.
• Definir una propiedad (asociada con métodos getXxx() y setXxx()) para cada campo que esté presente en el formulario.
El nombre del campo y el nombre de la propiedad deben corresponder de acuerdo a las convenciones usuales de los
JavaBeans. Por ejemplo, un campo de entrada llamado username hará que se llame al método setUsername().
• Debemos pensar en nuestros beans ActionForm como firewall ente HTTP y el objeto Action. Usamos el método
validate para asegurarnos de que están presentes todas las propiedades requeridas, y que contienen valores
razonables. Un ActionForm que falla en la validación incluso ni será presentado para el manejo del Action.
• También podríamos situar un ejemplar bean en nuestro formulario, y usar referencias a propieades anidadas. Por
ejemplo, podríamos tener un bean "customer" en nuestro Action Form, y luego referirnos a la propiedad
"customer.name" en nuestra vista JSP. Esto correspondería con los métodos customer.getName() y
customer.setName(string Name) de nuestro bean customer.
• Cuidado: si anidamos ejemplares de beans existentes en nuestro formulario, debemos pensar en las propiedades que
exponemos. Cualquier propiedad pública en un ActionForm que acepta un simple valor String puede seleccionarse con
un string de consulta. Podría ser muy útil situar dichos beans dentro de una fina "envoltura" que exponga sólo las
propiedades requeridas. Esta envoltura también puede proporcionar un filtro para asegurarnos en tiempo de ejecución
de que las propiedades no se seleccionan con valores inapropiados.

Deberías haber observado que un "formulario", en el sentido discutido aquí, no corresponde necesariamente con una sóla
página JSP en el interface de usuario. Es común en muchas aplicaciones tener un "formulario" (desde la perspectiva del
usuario) que se extienda sobre múltiples páginas. Piensa por ejemplo, en un interface de usuario al estilo de los wizard que se
utilizan comunmente cuando instalamos nuevas aplicaciones. Struts nos aconseja definir un sólo ActionForm que contenga las
propiedades de todos los campos, sin importar que página de campo se está mostrando actualmente. De igual forma, las
distintas páginas del mismo formulario deberían ser reenvidas a la misma clase Action. Si seguimos estas sugerencias, los
diseñadores de páginas podrán reordenar los campos entre varias páginas, frecuentemente sin requerir que cambiemos la
lógica de procesamiento.

Beans de Estado del Sistema

El estado real de un sistema normalmente está representado por un conjunto de una o mas clases JavaBeans, cuyas
propiedades definen el estado actual. Un sistema de tarjeta de compra, por ejemplo, incluirá un bean que represente la tarjeta
que está siendo mantenida por cada comprador individual, e incluirá (entre otras cosas) un conjunto de ítems que el comprador
ha seleccionado. Separadamente, el sistema también incluirá diferentes beans para la información del perfil del usuario
(incluyendo su tarjeta de crédito y su dirección de envío), así como el catalogo de ítems disponibles y sus niveles de inventario
actuales.

Para sistemas de pequeña escala, o para información de estado que no necesita guardarse durante mucho tiempo, un conjunto
de beans de estado del sistema podría contener todos los conocimientos que el sistema tiene sobre esos detalles particulares.
O, como es el caso más frecuente, los beans de estado del sistema representarán información que está almacenada
permanentemente en alguna base de datos externa (como un objeto CustomerBean que responde a una fila de la tabla
CUSTOMERS), y son creados o eliminados de la memoria del servidor cuando se necesita. Los JavaBeans Enterprise de
Entidad también se usan para esto en aplicaciones de gran escala.

Beans de Lógica de Negocio

Deberíamos encapsular la lógica funcional de nuestra aplicación como llamadas a métodos en JavaBeans diseñados para este
propósito. Estos métodos pueden ser parte de las mismas clases usadas para los beans de estado del sistema, o podrían estar
en clases separadas dedicadas a realizar la lógica. En el último caso, normalmente necesitaremos pasarle los beans de estado
del sistema para que sean manipulados por estos métodos como argumentos.

Para una reutilización máxima del código, los beans de la lógica del negocio deberían ser diseñados e implementados para que
no sepan que están siendo ejecutados en un entorno de aplicación Web. Si nos encontramos que tenemos que importar una
clase javax.servlet.* en nuestro bean, estamos ligando ésta lógica de negocio al entorno de una aplicación Web. Debemos
considerar reordenar las cosas para que nuestras clases Action (parte del rol del Controlador, según se describe abajo)
traduzcan toda la información requerida desde la solicitud HTTP que está siendo procesada en llamadas a métodos setXxx() de
propiedades de nuestros beans de lógica de negocio, después de que se pueda hacer una llamada a un método execute().
Dicha clase de lógica de negocio podría reutilizarse en entornos distintos al de la aplicación Web para el que fue construida en
un principio.

Dependieno de la complejidad y del ámbito de nuestra aplicación, los beans de lógica de negocio podrían ser JavaBeans
ordinarios que interactúan con beans de estado del sistema que son pasados como argumentos, o JavaBeans ordinarios que
aceden a una base de datos usando llamadas JDBC. Para grandes aplicaciones, estos beans frecuentemente ofrecerán
JavaBeans Enterprise (EJBs) con o sin estado en su lugar.

Acceder a Bases de Datos Relacionales

Struts puede definir las fuentes de datos para una aplicación desde dentro de un fichero de configuración estándard. También
se proporciona un simple almacen de conexiones JDBC.

Después de definir la fuente de datos, aquí tenemos un ejemplo de cómo establecer una conexión desde dentro del método
perform de la clase Action:

public ActionForward
perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
{
try {
javax.sql.DataSource dataSource =
servlet.findDataSource(null);
java.sql.Connection myConnection =
dataSource.getConnection();

//do what you wish with myConnection

} catch (SQLException sqle) {
getServlet().log("Connection.process", sqle);
} finally {

//enclose this in a finally block to make

//sure the connection is closed
try {
myConnection.close();
} catch (SQLException e) {
getServlet().log("Connection.close", e);
}
}
}

Observa que el almacen de conexiones Struts genérico es un componente opcional. Muchas aplicaciones Struts usan otros
almacenes de conexiones para un mejor rendimiento, especialmente con sistemas de producción de alto volumen.

Construir los Componentes de la Vista

Introducción

Este capítulo se enfoca en la tarea de construir los componentes de la Vista de una aplicación, que principalmente está creada
usando tecnología JavaServer Pages (JSP). En particular Struts proporciona soporte para construir aplicaciones
internacionalizadas, así como para interactúar con formularios de entrada.

Mensajes Internacionalizados

Hace unos pocos años, los desarrolladores de aplicaciones podían tener que contar sólo con los residentes de su país, que
normalmente sólo usaban un idioma (a veces dos), y una forma de representar cantidades numéricas, como fechas, números y
valores monetarios. Sin embargo, la explosión del desarrollo de aplicaciones basadas en tecnologías Web, así como el
despliegue de dichas aplicaciones sobre Internet y otras redes accesibles, han hecho que los límites nacionales sean invisibles
en muchos casos. Esto se ha traducido en la necesidad de que las aplicaciones soporten la internacionalización
(frecuentemente llamada "i18n" porque 18 es el número de letras entre la "i" y la "n") y localization.

Struts se construye sobre la plataforma Java proporcionada para construir aplicaciones internacionalizadas y localizadas. Los
conceptos clava para familiarizarnos con ellos son:

• Locale - La clase fundamental Java que soporta internacionalización es java.util.Locale. Toda Locale representa una
elección particular de país e idioma (además de variantes opcionales del idioma), y también un conjunto de
asumpciones de formateo para cosas como los números y las fechas.
• ResourceBundle - La clase java.util.ResourceBundle proporciona la herramienta fundamental para el soporte de
mensajes en varios idiomas.
• PropertyResourceBundle - Una de las implementaciones estándard de ResourceBundle que nos permite definir
recursos usando la misma sintaxis "nombe=valor" usada para inicializar ficheros de propiedades. Esto es muy
conveniente para preparar paquetes de recursos con mensajes que son usados en una aplicación Web, porque estos
mensajes normalmente están orientados a texto.
• MessageFormat - La clase java.text.MessageFormat nos permite reemplazar porciones de un string de un mensaje (en
este cado, recuperado de un paquete de recursos) con argumentos especificados en tiempo de ejecución. Esto es útil
 en casos donde estámos creando una sentencia, pero las palabras podrían aparecer en diferente orden en diferentes
idiomas. El string contenedor {0} del mensaje es reemplazado por el primer argumento, {1} es reemplazado por el
segundo argumento, etc.
• MessageResources - La clase Struts org.apache.struts.util.MessageResources nos permite tratar un conjunto de
paquetes de recursos como una base de datos, y nos permite solicitar un string de mensajes particular para una
Localidad particular (normalmente asociado con el usuario actual) en lugar de la localidad por defecto en la que el
propio servidor se está ejecutando.

Por favor, observa que el soporte de i18n en un marco de trabajo como Struts está limitado a la presentación de texto e
imágenes internacionalizadas al usuario.. El soporte para localidades específicas métodos de entrada (usado con idiomas
como el Japonés, el Chino y el Koreano) se deja al dispositivo del cliente, que normalmente es un navegador Web.

Para una aplicación internacionalizada, seguimos los pasos descritos en el documento Internationalization del paquete de
documentación del JDK de nuestra plataforma para crear un fichero de propiedades que contenga los mensajes para cada
idioma. Más adelante, un ejemplo ilustrará esto.

Asumimos que nuestro código fuente se ha creado en el paquete com.mycompany.mypackage, por eso está almacenado en un
directorio (relativo a nuestro directorio fuente) llamado com/mycompany/mypackage. Para crear un paquete de recursos
llamado com.mycompany.mypackage.MyResources, creariamos los siguientes ficheros en el directorio
com/mycompany/mypackage:

• MyResources.properties - Contiene los mensajes del idioma por defecto de nuestro servidor. Si el idioma por defecto
es Inglés, podríamos tener una entrada como esta:prompt.hello=Hello
• MyResources_xx.properties - Contiene los mismos mensajes en el idioma cuyo código de idioma ISO es "xx". Para una
versión Española del mensaje mostrado arriba, tendríamos esta entrada: prompt.hello=Hola. Podemos tener ficheros
de recursos para tantos idiomas como necesitemos.

Cuando configuramos el servlet controlador en el descriptor de despliegue de la aplicación Web, una de las cosas que
necesitamos definir en un parámetro de inicialización es el nombre base del paquete de recursos para la aplicación. En el caso
descrito arriba, sería com.mycompany.mypackage.MyResources.

<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>application</param-name>
<param-value>com.mycompany.mypackage.MyResources</param-value>
</init-param>
<.../>
</servlet>

Los importante para este paquete de recursos es encontrarse en el classpath de nuestra aplicación. Otra aproximación es
almacenar el fichero MyResources.properties en la carpeta classes de nuestra aplicación. Entonces podremos especificar
simplemente "myResources" como el valor de la aplicación. Debemos tener cuidado de no borrarlo si construimos scripts de
borrado de clases como parte de una fuente de "limpieza".

Si lo hace, hay una tarea de Ant a ejecutar cuando compilemos nuestra aplicación que copia los contenidos de un directorio
src/conf al directorio classes:

<!-- Copy any configuration files -->

<copy todir="classes">
<fileset dir="src/conf"/>
</copy>

Interacciones de Forms y FormBean

Una vez u otra, la mayoría de los desarrolladores web han construido formularios usando las capacidades estándard del HTML,
como la etiqueta <input>. Los usuarios esperan que las aplicaciones interactivas tengan ciertos comportamientos, y uno de
estos está relacionado con el manejo de errores -- si el usuario comete un error, la aplicación debería permitirle corregir sólo lo
que necesita ser modificado -- sin tener que re-introducir cualquier parte del resto de la información de la página o formulario
actual.

Conseguir esto es tedioso y aburrido cuando codificamos usando HTML y páginas JSP. Por ejemplo, un elemento de entrada
para un campo username podría parecerse a esto (en JSP):

<input type="text" name="username"

 value="<%= loginBean.getUsername() %>"/>

lo que es dificil de teclear correctamente, confunde a los desarrolladores HTML que no tienen conocimientos sobre conceptos
de programación, y puede causar problemas con editores HTML. En su lugar Struts proporciona una facilidad comprensiva
para construir formularios, basada en la facilidad de las Librerías de Etiquetas Personalizadas de JSP 1.1. El caso de arriba
sería renderizado de esta forma usando Struts:

<html:text property="username"/>

sin la necesidad de refirnos explicitamente al formulario JavaBean del que se recupera el valor inicial. Esto lo maneja
automáticamente el marco de trabajo.

Algunas veces los formularios HTML se usan para cargar otros ficheros. La mayoría de los navegadores soportan esto a través
de un elemento <input type="file">, que genera un botón navegador de ficheros, pero es cosa del desarrollador manejar los
ficheros entrantes. Struts maneja estos formularios "multipart" de la misma forma que los formularios normales. En la siguiente
sección, usaremos Struts para crear un simple formulario de login, y también un simple formulario multiparte.

Construir Formularios con Struts

Un ejemplo completo de un formulario de login ilustrara cómo Struts trata con los formularios de una forma menos dolorosa que
usar sólo las facilidades HTML y JSP estandards. Consideremos la siguiente página (basada en la aplicación de ejemplo
incluida con Struts) llamada logon.jsp:

<%@ page language="java" %>

<%@ taglib uri="/WEB-INF/struts-html.tld"
prefix="html" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld"
prefix="bean" %>
<html:html>
<head>
<title>
<bean:message key="logon.title"/>
</title>
<body bgcolor="white">
<html:errors/>
<html:form action="/logon" focus="username">
<table border="0" width="100%">
<tr>
<th align="right">
<html:message key="prompt.username"/>
</th>
<td align="left">
<html:text property="username"
size="16"/>
</td>
</tr>
<tr>
<th align="right">
<html:message key="prompt.password"/>
</th>
<td align="left">
<html:password property="password"
size="16"/>
</td>
</tr>
<tr>
<td align="right">
<html:submit>
<bean:message key="button.submit"/>
</html:submit>
</td>
<td align="right">
<html:reset>
<bean:message key="button.reset"/>
</html:reset>
</td>
</tr>
</table>
</html:form>
</body>
</html:html>

Los siguientes ítems ilustran las características clave del manejo de formularios en Struts, basadas en este ejemplo:

• La directiva taglib le dice al compilador de la página JSP donde encontrar el tag library descriptor para la librería de
etiquetas Struts. En este caso, estamos usando bean como el prefijo que identifica las etiquetas de la librería struts-
bean, y "html" como el prefijo que identifica las etiquetas de la librería struts-html. Se puede usar cualquier prefijo que
deseemos.
• Esta página usa varias ocurrencias de la librería de mensajes para buscar los strings de mensajes internacionalizados
desde un objeto MessageResources que contiene todos los recursos de esta aplicación. Para que esta página
funcione, se deben definir las siguientes claves de mensajes en estos recursos:
o logon.title - Título de la página de login.
o prompt.username - Un string para pedir el "Username:"
o prompt.password - Un string para pedir la "Password:"
o button.submit - Etiqueta para el botón "Submit"
o button.reset - Etiqueta para el botón "Reset"

Cuando el usuario entra, la aplicación puede almacenar un objeto Locale en la sesión de este usuario. Este Locale se
usará para seleccionar mensajes en el idioma apropiado. Esto se hace sencillo de implementar dando al usario una
opción para elegir el idioma -- simplemente cambiamos el objeto Locale almacenado, y todos los mensajes se
modificaran automáticamente.

• Las banderas de error muestran cualquier mensaje de error que haya sido almacenado por un componente de lógica
de negocio, o ninguna si no se ha almacenado ningún error. Esta etiqueta se describirá más adelante.
• La etiqueta form renderiza un elemento <form> HTML, basándose en los atributos especificados. También asocia todos
los campos que hay dentro del formulario con un FormBean con ámbito de sesión que se almacena bajo la clave
logonForm. El desarrollador de Struts proporciona la implementación Java para este bean de formulario, extendiendo la
clase ActionForm de Struts. Este bean se usa para proporcionar valores iniciales para todos los campos de entrada
que tienen nombres que corresponden con nombres de propiedades del bean. Si no se encuentra un bean apropiado,
se creará uno nuevo automáticamente, usando el nombre de la clase Java especificado.
• El bean formulario también se puede especifiar en el fichero de configuración de Struts, en cuyo caso se pueden omitir
el Nombre y el Tipo. (Puedes ver más detalles en Fichero de Configuraciín para Action Mappings).
• La etiqueta text se renderiza como un elemento <input> de HTML del tipo "text". En este caso también se han
especificado el número de caracteres y la posición a ocupar en la ventana del navegador. Cuando se ejecuta esta
página, el valor actual de la propiedad username del bean correspondiente (es decir, el valor devuelto por
getUsername()).
• La etiqueta password se usa de forma similar. La diferencia está en que el navegador mostrará asteriscos, en lugar del
valor de entrada, mientras el usuario teclea su password...
• Las etiquetas submit y reset generan los botones correspondientes en la parte inferior del formulario. Las etiquetas de
texto para cada botón se crean usando la librería de mensajes, como las peticiones, para que estos valores sean
internacionalizados.

Manejar formularios multiparte también es sencillo. Obviamente cuando creamos un formulario multiparte estámos creando un
formulario que al menos tiene un entrada del tipo "file". El primer paso para crear el formulario multiparte es utlizar la librería de
etiquetas struts-html para crear la página de presentación:

<%@page language="java">
<%@taglib uri="/WEB-INF/struts-html.tld"
prefix="html">
<html:form action="uploadAction.do">
Please Input Text:
<html:text property="myText"><br/>
Please Input The File You Wish to Upload:<br/>
<html:file property="myFile"><br />
<html:submit />
</html:form>

El siguiente paso es crear nuestro bean ActionForm :

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.upload.FormFile;
public class UploadForm extends ActionForm {
 protected String myText;
protected FormFile myFile;
public void setMyText(String text) {
myText = text;
}
public String getMyText() {
return myText;
}
public void setMyFile(FormFile file) {
myFile = file;
}
public FormFile getMyFile() {
return myFile;
}
}

Podemos ver los Javadocs del FormFile para ver los métodos que expone para manipular y subir ficheros. También podemos
ver los Javadocs para ActionServlet y ActionMapping para ver los distintos parámetros que podemos especificar para cambiar
la forma en que se (suben) cargan los ficheros. Básicamente en nuestro método peform() de nuestra clase action deberíamos
llamar a ((UploadForm) form).getMyFile() para recuperar el FormFile y hacer lo que queramos con él.

Tipos de Campos de Entrada Soportados

Struts define etiquetas HTML para todos estos tipos de campos de entrada:

• checkboxes
• Campos hidden
• Campos de entrada password
• Botones de radio
• Botones de reset
• Lsitas select con opciones embebidas o ítems de opciones.
• option
• options
• Botones submit
• Campos de entrada de texto text
• textareas

En cada caso, una etiqueta de campo debe estár anidada dentro de una etiqueta form, por eso los campos saben qué bean
utilizar para inicializar los valores mostrados.

Otras Útiles Etiquetas de Presentación

Hay varias etiquetas útiles para crear presentaciones, consulta la documentación de cada librería de etiquetas especifica, junto
con la Guía de Desarrolladores de Etiquetas, para más información:

• [logic] iterate repite su cuerpo de etiqueta una vez por cada elemento de una colección especificada (que puede ser
una Enumeration, un Hashtable, un Vector, o un array de objetos).
• [logic] present dependiendo del atributo que se especifique, esta etiqueta chequea la solicitud actual, y evalua el
contenido de los campos anidados de esta etiqueta sólo si hay un valor presente. Sólo se puede usar uno de los
atributos en una ocurrencia de esta etiqueta, a menos que utilicemos el atributo property, en cuyo caso también es
necesario el nombre del atributo. Los atributos incluyen cookie, header, name, parameter, property, role, scope, y user.
• [logic] notPresent el contrario de la etiqueta present, notPresent proporciona la misma funcionalidad pero cuando el
atributo especificado no está presente.
• [html] link genera un elemento <a> HTML como una definición de un enlace o un hiperenlace a la URL especificada, y
automáticamente aplica codificación URL para mantener el estado de la sesión en la ausencia del soporte de cookies.
• [html] img genera un elemento <img> HTML con la habilidad de modificar dinámicamente las URLs especificadas por
los atributos "src" y "lowsrc" de la misma forma en que se puede hacer con <html:link>.
• [bean] parameter recupera el valor del parámetro solicitado, y define el resultado como un atributo de ámbito de página
del tipo String o String[].

Validación Automática de Formularios

Además de las interacciones entre el formulario y el bean descrita arriba, Struts ofrece una facilidad adicional para validar los
campos de entrada que ha recibido. Para utilizar esta característica, sobreesribimos el siguiente método en nuestra clase
ActionForm:
public ActionErrors
validate(ActionMapping mapping,
HttpServletRequest request);

El método validate() es llamado por el servlet controlador después de que se hayan rellando las propiedades del bean, pero
antes de se llame al método perform() correspondiente de la clase action. El método validate() tiene las siguientes opciones:

• Realiza las validaciones apropiadas y no encuentra problemas -- Devuelve null o ejemplares de ActionErrors de
longitud cero, y el servlet controlador procederá a llamar al método perform() de la clase Action apropiada.
• Realiza las validaciones apropiadas y encuentra problemas -- Devuelve un ejemplar de ActionErrors conteniendo
ActionError's, que son clases que contienen las claves del mensaje de error (dentro del paquete MessageResources de
la aplicación) que se deberían mostrar. El servlet controlador almacena este array como un atributo de la solicitud
disponible para usarse por la etiqueta <html:errors>, y devolverá el control al formulario de entrada (identificado por la
propiedad input de este ActionMapping).

Como se mencionó anteriormente, esta característica es totalmente opcional. La implementación por defecto de validate()
devuelve null, y el servlet controlador asumirá que no se requiere que se haga ninguna validación por parte de la clase Action.

Una aproximación común es realizar validaciones iniciales usando el método validate(), y luego manejar la validación de la
"lógica de negocio" desde el objeto Action.

Un paquete opcional para realizar validaciones ActionForm está disponible en la web site de David Winterfeldt's.

Otras Técnicas de Presentación

Aunque el aspecto y el comportamietno de nuestra aplicación puede construirse completamente basándonos en las
capacidades estándards de JSP y la librería de etiquetas de Struts, deberíamos considerar emplear otras técnicas que mejoren
la reutilización de componentes, reduzca los esfuerzos de mantenimiento, y/o reduzca los errores. En las siguientes secciones
se explican varias opciones.

Etiquetas Personalizadas Específicas de la Aplicación

Más allá del uso de las etiquetas personalizadas proporcioandas por la librería de Struts, es fácil crear etiquetas que sean
específicas de la aplicación que estamos construyendo, para asistirnos en la creación del interface de usuario. La aplicación de
ejemplo incluida con Struts ilustra este principio creando las siguientes etiquetas únicamente para la implementación de esta
aplicación:

• checkLogon - Chequea la existencia de un objeto session particular, y reenvía el control a la página de logon si no
esite. Esto se usa para capturar casos donde un usuario ha colocado un página del medio de la aplicación en su
bookmark e intenta saltarse el login. o si ha expirado la sesión de un usuario.
• linkSubscription - Genera un hiperenlace a una página de detalles para una Subscription, que pasa los valores de la
clave primaria requerida como atributos de la solicitud. Esto se usa cuando se listan las subcripciones asociadas con
un usuario, y proporciona enlaces para editarlas o borrarlas.
• linkUser - Genera un hiperenalce a una página de detalles de usuario, que pasa los valores de la clave primaria
requerida como un atributo de la solicitud.

El código fuente de estas etiquetas está en el directorio, src/example, en el paquete org.apache.struts.example, junto con otras
clases Java que son usadas por esta aplicación.

Composición de Páginas con Includes

Crear la presentación completa de una página en un fichero JSP (con etiquetas personalizadas y beans para acceder a los
datos dinámicos requeridos) es un aproximación de diseño muy común, y fue empleada en el ejemplo incluido con Struts. Sin
embargo, muchas aplicaciones requieren mostrar varias porciones de distinciones lógicas de nuestra aplicación en una sóla
página

Por ejemplo, una aplicación portal, podría tener alguna o todas estas capacidades funcionales disponibles en la página "home"
del portal:

• Acceso a un motor de búsqueda para este portal.

• Uno o más displays "alimentadores de noticias" con los tópicos de interés personalizados desde el perfil de registro del
usuario.
• Acceso a tópicos de discusión relacionados con este portal.
• Un indicador de "mail esperando" si nuestro portal proporciona cuentas gratuitas de correo.
El desarroolo de los distintos segmentos de esta site es sencillo si podemos dividir el trabajo y asignar los distintos segmentos
a diferentes desarrolladores. Luego, podemos usar la capacidad include de las páginas JSP para combinar los resultados en
una sóla página, o usar la etiqueta include proporcionada por Struts. Hay disponibles tres tipos de include, dependiendo de
cuando queremos que ocurra la combinación de la salida:

• Una directiva <%@ include file="xxxxx" %> puede incluir un fichero que contiene código Java o etiquetas JSP. El
código incluido en el fichero puede incluso referenciar variables declaradas antes en la página JSP exterior. El código
se pone en línea dentro de la otra página JSP antes de que sea compilada y por eso puede contener definitivamente
más que sólo código HTML.
• El include de action (<jsp:include page="xxxxx" flush="true" />) se procesa en el momento de la solicitud, y es
manejado de forma transparente por el servidor. Junto con otras cosas, esto significa que podemos realizar el include
condicionalmente anidandolo dentro de una etiqueta como equals usando sus atributos de parámetros
• La etiqueta bean:include toma un argumento "forward" que representa un nombre lógico mapeado al JSP a incluir, o el
argumento "id", que representa la variable string del contexto de la pagina a imprimir en la página JSP.

Otra aproximación a esto sería el uso de la librería de plantillas de etiquetas de Struts. Puedes ver más detalles en la Guia del
Desarrollador.

Tiles es una alternativa a la Librería de Plantilla de Etiquetas, ofreciendo varias mejoras y nuevas capacidades. Tiles está
disponible en el la web site de Cedric Dumoulin.

Componentes de Renderizado de Imágenes

Algunas aplicaciones requieren generar imágenes dinámicamente, como cartas de precios sobre una site de informe de stocks.
Normalmente se utilizan dos diferentes aproximaciones para obtener estos requerimientos:

• Renderizar un hiperenlace con una URL que ejecuta una solicitud Servlet. El servlet usa una librería gráfica para
renderizar la imagen, selecciona el tipo de contenido apropiadamente (como a image/gif), y envia de vuelta al
navegador los bytes de la imagen, que los mostrará como si hubiera recibido un fichero estático.
• Renderizar el código HTML necesario para descargar un Applet Java que cree el gráfico necesario. Podemos
configurar el gráfico selecionando los parámetros de inicialización del applet en el código de renderizado, o podemos
tener que hacer que el applet haga su propia conexión al servidor para recibir estos parámetros.

Dibujo de Texto

Algunas aplicaciones requieren que se genere texto o marcas, como XML, dinámicamente. Si está siendo renderizada una
página completa, y puede sacarse usando un PrintWriter, es muy fácil hacerlo desde un Action:

response.setContentType("text/plain"); // or text/xml
PrintWriter writer = response.getWriter();
// use writer to render text
return(null);
Construir los Componentes del Controlador

Introducción

Ahora que hemos entendido cómo construir los componentes del Modelo y de la Vista de nuestra aplicación, es hora de
enfocarnos en los componentes del Controller. Struts incluye un servlet que implementa la función principal de mapeo de una
solicitud URI a una clase Action. Por lo tanto, nuestras principales responsabilidades con el controlador son:

• Escribir una clase Action por cada solicitud lógica que podría ser recibida (extendida desde org.apache.action.Action).
• Configurar un ActionMapping (en XML) por cada solicitud lógica que podría ser enviada. El fichero de configuración
XML normalmente se llama struts-config.xml.
• Actualizar el fichero del descriptor de despliegue de la aplicación Web (en XML) para nuestra aplicación para que
incluya los componentes Struts necesarios.
• Añadir los componentes Struts apropiados a nuestra aplicación.

Clases Action

La clase Action define dos métodos que podrían ser ejecutados dependiendo de nuestro entorno servlet:

public ActionForward perform(ActionMapping mapping,

ActionForm form,
ServletRequest request,
ServletResponse response)
throws IOException, ServletException;

public ActionForward perform(ActionMapping mapping,

ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException;

La mayoría de los proyectos sólo usarán la versión "HttpServletRequest".

El objetivo de una clase Action es procesar una solicitud, mediante su método perform(), y devolver un objeto ActionForward
que identifica dónde se debería reenviar el control (por ejemplo a una JSP) para proporcionar la respuesta apropiada. En el
patrón de diseño MVC/Model 2, una clase Action típica implementará una lógica como ésta en su método perform():

• Validar el estado actual de la sesión del usuario (por ejemplo, chequear que el usuario ha hecho el login). Si la clase
Action encuentra que no existe logon, la solicitud es reenviada a la página JSP que muestra las peticiones del nombre
de usuario y la password para logging on. Esto podría ocurrir porque un usuario intente entrar "en el medio" de una
aplicación (digamos, desde un bookmark), o porque la sesión ha expirado, y el contenedor servlet creó una nueva.
• Si la validación no se ha completado, valida las propiedades del bean formulario según sea necesario. Si se encuentra
un problema, almacena las claves de los mensajes de error apropiados como un atributo de la petición, y reenvía el
control de vuelta al formulario de entrada para que se puedan corregir los errores.
• Realizar el procesamiento requerido para tratar con esta solicitud (como grabar un fila de la base de datos). Esto se
puede hacer mediante código lógico embebido dentro de la propia clase Action, pero generalmente debería realizarse
llamando a un método apropiado del bean de lógica de negocio.
• Actualizar los objetos del lado del servidor que serán usados para crear la siguiente página del interface de usuario
(normalmente beans del ámbio de solicitud o de sesion, dependiendo de cuánto tiempo necesitemos mantener estos
ítems disponibles).
• Devolver un objeto ActionForward apropiado que identifica la página JSP usada para generar esta respuesta, basada
en los beans actualizados recientemente. Típicamente adquiriremos una referencia a dicho objeto llamando a
findForward() o al objeto ActionMapping que recibimos (si estamos usando un nombre lógico normal para este mapeo),
o en el propio servlet controlador (si estamos usando un nombre lógico global para la aplicación).

Entre los problemas de diseño a recordar cuando codificamos clases Action incluimos los siguientes:

• El servlet controlador crea un sólo ejemplar de nuestra clase Action, y la usa para todas las solicitudes. Es decir,
necesitamos codificar nuestra clase Action para que opere correctamente en un entorno multi-thread, como si
estuvieramos codificando un método service() de un servlet.
• El principio más importante que nos ayuda en la codificación de threads seguros es usar sólo variables locales, no
variables de ejemplar, en nuestra clase Action. Las variables locales se crean en una pila que es asignada (por nuestra
JVM) a cada thread solicitado, por eso no necesitamos preocuparnos de compartirlas.
 • Los beans que representan el Modelo de nuestro sistema podría lanzar excepciones debido a problemas de acceso a
bases de datos o a otros recursos. Deberíamos atrapar dichas excpeciones en la lógica de nuestro método perform(), y
guardalas en el fichero de log de la aplicación (junto con el seguimiento de pila correspondiente) llamando a:
• servlet.log("Error message text", exception);
• Como regla general, asignar recursos y mantenerlos a través de las solicitudes del mismo usuario (en la misma sesión
de usuario) puede causar problemas de escalabilidad. Deberíamos pensar en liberar esos recursos (como las
conexions a una base de datos) antes de reenviar el control al componente de la Vista apropiado -- incluso si un
método del bean que hemos llamado lanza una excepción.

Además, queremos protegernos contra clases Action que son demasiado largas. La forma más fácil de hacer que esto suceda
es embeber la lógica funcional en la propia clase Action, en vez codificarla en beans de lógica de negocio independientes.
Además de hacer la propia clase Action dura de entender y de mantener, esta aproximación también hace díficil re-utilizar el
código de la lógica de negocio, porque está embebido dentro de un componente (la clase Action) que está concebido para ser
ejecutado en un entorno de aplicación Web.

Una Action puede dividirse en varios métodos locales, mientras que todas las propiedades necesarias sean pasadas en las
firmas de métodos. La JVM maneja dichas propiedades usando la pila, y por eso son seguras ante los threads.

La aplicación de ejemplo incluida con Struts no cumple este principio, porque la propia lógica de negocio está embebida dentro
de las clases Action. Esto debería considerarse un bug en el diseño de la aplicación de ejemplo, en vez de una característica
intrínseca de la arquitectura , o una aproximación a emular.

La Implementación de ActionMapping

Para poder operar satisfactoriamente, el servlet controlador Struts necesita conocer varias cosas sobre como se debería
mapear toda URI solicitada a una clase Action apropiada. El conocimiento requerido ha sido encapsulado en un interface Java,
llamado ActionMapping, estas son las propiedades más importantes:

• type - nombre totalmente cualificado de la clase Java que implementa la clase Action usada por este mapeo.
• name - El nombre del bean de formulario definido en el fichero de configuración que usará este action.
• path - El path de la URI solicitada que corresponden con la selección de este mapeo.
• unknown - Seleccionado a true si este action debería ser configurado como por defecto para esta aplicación, para
manejar todas las solicitudes no manejadas por otros action. Sólo un Action puede estar definido como por defecto
dentro de una sóla aplicación.
• validate - Seleccionado a true si se debería llamar al método validate() de la action asociada con este mapeo.
• forward - El path de la URI solicitada a la que se pasa el control cuando se ha invocado su mapeo. Esto es una
alternativa a declarar una propiedad type.

Fichero de Configuración de los Mapeos de Action

¿Cómo aprende el servlet controlador sobre los mapeos que queremos? Sería posible (pero tedioso) escribir una pequeña
clase Java que simplemente ejemplarizara nuevos ejemplares de ActionMapping, y llamara a todos los métodos set()
apropiados. Para hacer este proceso más sencillo, Struts incluye un módulo Digester que es capaz de leer la descripción
basada en XML de los mapeos deseados, creando los objetos apropiados de la misma forma. Puedes encontrar más
información sobre este Digester en la documentación del API

La responsabilidad del desarrollador es crear un fichero XML llamado struts-config.xml, y situarlo en el directorio WEB-INF de
su aplicación. Este formato de documento está restringido por su definición en "struts-config_1_0.dtd". El elemento XML más
exterior debe ser <struts-config>.

Dentro del elemento <struts-config>, hay dos elementos importantes que son usados para describir nuestras acciones:

• <form-beans>
Esta sección contiene nuestras definiciones de beans. Usamos un elemento <form-bean> por cada bean de formulario,
que tiene los siguientes atributos importantes:
o name: Un identificador único para este bean, que será usado para referenciarlo en los correspondientes
mapeos de acciones. Normalmente, es también el nombre del atributo de solicitud o sesión bajo el que se
almacena este bean de formulario.
o type: El nombre totalmente cualificado de la clase Java de nuestro bean de formulario.
• <action-mappings>
Esta sección contiene nuestras definiciones de acciones. Usamos un elemento <action> por cada una de nuestras
acciones que queramos definir. Cada elemento action requiere que se definan los siguientes atributos:
o path: El path a la clase action en relación al contexto de la aplicación.
o type: El nombre totalmente cualificado de la clase Java de nuestra clase Action.
o name: El nombre de nuestro elemento <form-bean> para usar con esta action.
El fichero struts-config.xml de la aplicación de ejemplo incluye las siguientes entradas de mapeo para la función "log on", que
se usará para ilustrar los requerimientos. Oserva que las entradas para otras acciones se han dejado fuera:

<struts-config>
<form-beans>
<form-bean
name="logonForm"
type="org.apache.struts.example.LogonForm" />
</form-beans>
<global-forwards
type="org.apache.struts.action.ActionForward" />
<forward name="logon" path="/logon.jsp"
redirect="false" />
</global-forwards>
<action-mappings>
<action
path="/logon"
type="org.apache.struts.example.LogonAction"
name="logonForm"
scope="request"
input="/logon.jsp"
unknown="false"
validate="true" />
</action-mappings>
</struts-config>

Primero se define el bean formulario, Un bean básico de la clase "org.apache.struts.example.LogonForm" es mapeado al

nombre lógico "logonForm". Este nombre se usa como un nombre de atributo de sesión o solicitud para el bean de formulario.

La sección "global-forwards" se usa para crear mapeos de nombres lógicos para páginas JSP usadas comunmente. Cada uno
de estos reenvíos está disponible a través de una llamada a nuestro ejemplar de mapeo de action, por ejemplo
actionMappingInstace.findForward("logicalName").

Como podemos ver, este mapeo corresponde con el path /logon (realmente, porque la aplicación de ejemplo usa mapeo de
extensión, la URI que especificamos en una página JSP terminaría en /logon.do). Cuando se recibe una solicitud que
corresponde con el path, se crea un ejemplar de LogonAction (sólo la primera vez). El Servlet controlador buscará un bean de
ámbito de sesión bajo la clave logonForm, creando y guardando un bean de la clase especificada si es necesario.

Opcionales pero muy útiles son los elementos localizados en "forward". En la aplicación de ejemplo, muchas acciones incluyen
un reenvio local "success" y/o "failure" como parte de un mapeo de Action.

<!-- Edit mail subscription -->

<action path="/editSubscription"
type="org.apache.struts.example.EditSubscriptionAction"
name="subscriptionForm"
scope="request"
validate="false">
<forward name="failure" path="/mainMenu.jsp"/>
<forward name="success" path="/subscription.jsp"/>
</action>

Usando estas dos propiedades extras, las clases Action de la aplicación de ejemplo son casi totalmente independientes de los
nombres reales de las páginas JSP que son usadas por los diseñadores, Las páginas, pueden renombrarse (por ejemplo)
durante un rediseño, con un mínimo impacto en las propias clases Action. Si los nombres de las páginas JSP "next" estuvieran
codificados dentro de las clases Action, todas estas clases tendrían que ser modificadas. Por supuesto, podemos definir
cualquier propiedad de reenvío local que tenga sentido para nuestra aplicación.

Una sección más de buen uso es la sección <data-sources>, que especifica las fuentes de datos que puede usar nuestra
aplicación. Aquí podemos ver cómo especificar una fuente de datos para nuestra aplicación dentro de struts-config.xml:

<struts-config>
<data-sources>
<data-source
autoCommit="false"
description="Example Data Source Description"
driverClass="org.postgresql.Driver"
maxCount="4"
minCount="2"
password="mypassword"
url="jdbc:postgresql://localhost/mydatabase"
user="myusername"/>
</data-sources>
</struts-config>

Descriptor de Despliegue de la Aplicación Web

El paso final en la configuración de la aplicación es configurar el descriptor de despliegue (almacenado en el fichero WEB-
INF/web.xml) para incluir todos los componentes Struts que son necesarios. Usando el descriptor de despliegue del la
aplicación de ejemplo como guía, veremos que se necesitan crear o modificar la siguientes entradas.

Configurar el Ejemplar de Action Servlet

Añadimos una entrada definiendo el propio servlet action, junto con los parámetros de inicialización apropiados. Dicha entrada
se podría parecer a esto:

<servlet>
<servlet-name>action</servlet-name>
<servlet-class>
org.apache.struts.action.ActionServlet
</servlet-class>
<init-param>
<param-name>application</param-name>
<param-value>
org.apache.struts.example.ApplicationResources
</param-value>
</init-param>
<init-param>
<param-name>config</param-name>
<param-value>
/WEB-INF/struts-config.xml
</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>mapping</param-name>
<param-value>
org.apache.struts.example.ApplicationMapping
</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>

Los parámetros de inicialización soportados por el servlet controlador se describen abajo. Los corchetes cuadrados describen
los valores por defecto que se asumen si no proporcionamos un valor para el parámetro de inicialización.

• application - El nombre de la clase Java para la clase base del paquete de recursos de la aplicación. [NONE].
• bufferSize - El tamaño del buffer de entrada usado para procesar uploads de ficheros. [4096].
• config - Path relativo al contexto del recurso XML que contiene nuestra información de configuración.[/WEB-INF/struts-
config.xml].
• content - Tipo de contenido por defecto y codificación de caracteres a seleccionar en cada respuesta; podría ser
sobreescrito por un servlet re-enviado o una página JSP. [text/html].
• debug - El nivel de detalle de depuración para este servlet, que controla cuanta información se pone en el log. [0].
• detail - El nivel de detalles de depuración para el Digester que utilizamos en initMapping(), que sale por System.out en
lugar de servlet log. [0].
• factory - El nombre de la clase Java del MessageResourcesFactory usado para crear el objeto MessageResources de
la aplicación. [org.apache.struts.util.PropertyMessageResourcesFactory].
• formBean - El nombre de la clase Java de la implementación de ActionFormBean a utilizar.
[org.apache.struts.action.ActionFormBean].
• forward - el nombre de la clase Java de la implemetnación de ActionForward a utilizar.
[org.apache.struts.action.ActionForward]. Podríamos usar aquí dos clases de conveniencia:
o org.apache.struts.action.ForwardingActionForward - Subclase de org.apache.struts.action.ActionForward que
por defecto pone la propiead redirect a false (lo mismo que el valor por defecto de ActionForward).
 o org.apache.struts.action.RedirectingActionForward - Subclase de org.apache.struts.action.ActionForward que
por defecto pone la propiedad redirect a true.
• locale - Si se selecciona a true, y hay una sesión de usuario, indentifica y almacena un objeto java.util.Locale apropiado
(bajo la clave estándard indentificada por Action.LOCALE_KEY) en la sesión de usuario si no hay ya un objeto Locale.
[true]
• mapping - El nombre de la clase Java de la implementación del ActionMapping a utilizar.
[org.apache.struts.action.ActionMapping]. Podríamos usar aquí dos clases de conveniencia:
o org.apache.struts.action.RequestActionMapping - Subclase de org.apache.struts.action.ActionMapping que por
defecto deja la propiedad scope a "request".
o org.apache.struts.action.SessionActionMapping - Subclase de org.apache.struts.action.ActionMapping que por
defecto deja la propiedad scope a "session". (Igual que el valor por defecto de ActionMapping).
• maxFileSize - El tamaño máximo (en bytes) para que un ficheo sea aceptado para upload. Puede expresarse como un
número seguido por una K" "M", o "G", que serán interpretadas como kilobytes, megabytes, o gigabytes,
respectivamente. [250M].
• multipartClass - El nombre totalmente cualificado de la clase de la implementación de MultipartRequestHandler usado
para procesar uploads de ficheros. [org.apache.struts.upload.DiskMultipartRequestHandler].
• nocache - Si se selecciona a true, añade cabeceras HTTP a cada respuesta para evitar que el navegador almacene en
el cahé cualquier respuesta generado o reenviada. [false].
• null - Si se selecciona a true, configura los recursos de nuestra aplicación a devolver null si se usa una clave de
mensaje desconocida. De otra forma, se devolverá un mensaje de error incluyendo la clave errónea. [true].
• tempDir - El directorio de trabajo temporal usado cuando se procesan uploads de ficheros. [El directorio de trabajo
proporcionado para esta aplicación web como atributo contexto del servlet].
• validate - ¿Estámos suando el nuevo formato de fichero de configuración? [true].
• validating - ¿Deberíamos usar un analizador con validación XML para procesar el fichero de configuración (altamente
recomendado? [true].

Configurar el Mapeo del Servlet Action

Nota: El material de esta sección no es específico de Struts. La configuración del mapeo de servlets está definida en la Java
Servlet Specification. Esta sección describe los significados más comunes de configuración de una aplicación Struts.

Hay dos aproximaciones comunes para definir las URLS que serán procesadas por el servlet controlador -- correspondencia de
prefijo y correspondencia de extensión.

La correspondencia de prefijo significa que queremos que todas las URLs que empiecen con (después de la parte del path de
contexto) un valor particular sean pasadas a este servlet. Dicha entrada se podría parecer a esto:

<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>/execute/*</url-pattern>
</servlet-mapping>

lo que significa que una URI que coincida con el path /logon descrito anteriormente podría parecerse a esto:

http://www.mycompany.com/myapplication/execute/logon

donde /myapplication es el path de contexto bajo el que se ha desplegado nuestra aplicación.

Por otro lado, en el mapeo por extensión, se renvian las URIs solicitadas al servlet action basándose en el hecho de que la URI
termine en un punto seguido por un conjunto defindo por caracteres. Por ejemplo, el servlet de procesamiento JSP está
mapeado al patrón *.jsp para que sea llamado cada vez que se solicite una página JSP. Para usar la extensión *.do (que
implica "hacer algo"), la entrada de mapeo se podría parecer a esta:

<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>

y una URI que corresponda con el path /logon descrito anteriormente se parecería a esto:

http://www.mycompany.com/myapplication/logon.do

Configurar la Librería de Etiquetas de Struts

Luego, debemos añadir una entrada definiendo la librería de etiquetas Struts. Actualmente hay cuatro librerías que vienen con
Struts.

La librería struts-bean contiene etiquetas útiles para acceder a los beans y sus propiedades, así como para definir nuevos
beans (basados en esos accesores) que son accesibles para el resto de la página mediante variables de scripting y atributos
de ámbito de página. También se proporcionan mecanismos convenientes para crear nuevos beans basados en el valor de una
cookie, de las cabeceras y de los parámetros.

La librería struts-html contiene etiquetas para crear formularios de entrada struts, así como otras etiquetas generalmente útiles
en la creación de interfaces de usuario basados en HTML.

La librería struts-logic contiene etiquetas que son útiles para manejar la generación condicional de salida de texto, hacer bucles
sobre colecciones de objetos para generación repetitiva de salida de texto y control del flujo de la aplicación.

La librería struts-template contiene etiquetas que definen un mecanismo de plantillas.

Abajo podemos ver cómo se definirían todas las librerías de etiquetas para usarlas en nuestra aplicación, en realidad, sólo
deberíamos especificar las librerías que vayamos a utilizar:

<taglib>
<taglib-uri>
/WEB-INF/struts-bean.tld
</taglib-uri>
<taglib-location>
/WEB-INF/struts-bean.tld
</taglib-location>
</taglib>
<taglib>
<taglib-uri>
/WEB-INF/struts-html.tld
</taglib-uri>
<taglib-location>
/WEB-INF/struts-html.tld
</taglib-location>
</taglib>
<taglib>
<taglib-uri>
/WEB-INF/struts-logic.tld
</taglib-uri>
<taglib-location>
/WEB-INF/struts-logic.tld
</taglib-location>
</taglib>
<taglib>
<taglib-uri>
/WEB-INF/struts-template.tld
</taglib-uri>
<taglib-location>
/WEB-INF/struts-template.tld
</taglib-location>
</taglib>

Esto le dice al sistema JSP donde encontrar el descritor de librería de etiqueta para esta librería (en nuestro directorio WEB-
INF de la aplicación, en vez de en algún lugar exterior en Internet).

Añadir Componentes Struts a nuestra Aplicación

Para usar Struts, debemos copiar los ficheros .tld que necesitamos en nuestro directorio WEB-INF, y copiar struts.jar (y todos
los otros ficheros commons-*.jar) en nuestro directorio WEB-INF/lib.