3. Construcción Componentes Vistas

"Que si debiera caer a través del centro de la tierra... y salir del otro lado, donde la gente caminan al revés "

3.1 Visión General

 El framework provee soporte de infraestructura para componentes de vista, pero no provee cualquier componente propios vista. Varias tecnologías de presentación están disponibles, incluyendo a lo largo de otros, Cocoon, JSP, Plantillas Velocity y XSLT.

Características previstas por el framework por el uso directo por los componentes vista incluyen Recursos de Mensajes para localizar texto e imágenes y FormBeans para proveer una población automática y validación.

3.2 Mensajes internacionalizados

Hace unos años, las aplicaciones de desarrolladores podría contar en tener  soporte solo residentes en su propio país, que son usados solo uno(o algunas veces dos) lenguajes y un camino que representa cantidades numéricas como fechas, números y valores monetarios. Sin embargo, la explosión de aplicaciones desarrolladas basadas en tecnologías web, así como el despliegue de tales aplicaciones en el Internet y otros ampliamente redes accesibles, tengan prestados limites nacionales invisibles en muchos casos. Esto tiene traducido (si me permite el juego de palabras) dentro de una aplicación necesaria para soporte internacionalización(a menudo llamado "i18n" porque 18 es el número de letras entre la "i" y la "n") y localización.

El framework se basa en las clases estándar disponibles en la plataforma Java para construir aplicaciones internacionalizadas y localizada. El concepto clave para familiarizarse con estos:

• Locale - La clase fundamenta de Java que soporta internacionalización es Locale. Cada Locade representa una opción en particular de país y lenguaje(mas un lenguaje variante opcional)  y un conjunto de supuestos formatos para pensar como números y datos.
• ResourceBundle - La clase java.util.ResourceBundle provee herramientas fundamentales para el soporte de mensajes en múltiples lenguajes. Ver el Javadocs para la clase ResourceBundle y la información de Internacionalización en la documentación acumulada para tu JDK libre, para mas información.
• PropertyResourceBundle - Uno de implementación estandar de ResourceBundle que permite definir recursos usando la misma sintaxis "name=value" usado para inicializar propiedades de archivos. Hay muchos convenientes para preparar recursos con mensajes que son usados en una aplicación web, porque estos mensajes son generados en texto
• MessageFormat - La clase java.text.MessageFormat permite remplazar una parte de la cadena del mensaje(en este caso, recuperar desde un manojo de recursos) con argumentos específicos en tiempo de ejecución. Esto es útil en casos donde creas una sentencia, pero las palabras podrían aparecer en un diferente ordeny en diferentes lenguajes. La cadena de marcador de posición {0} en el mensaje es remplazado por el primer argumento en ejecución, {1} es remplazado por el segundo argumento, etcétera.
• MessageResource - La clase del framework org.apache.struts.util.MessageResources permite tratar un conjunto  de recursos aplicados como una base de datos y permite una solicitud un mensaje de cadenas en particular para un local en particular(normalmente un asociado con el usuario en particular) en lugar de el Local por default el servidor mismo este corriendo.

Por favor nota que el soporte i18n en el framework del lado del servidor es limitado a la presentación de texto y texto internacionalizado para el usuario. Soporte para métodos de entrada de Locales específicos(usados con lenguajes tales como Japones, Chino y Koreano) a la izquierda en el dispositivo del usuario, la cual es usualmente un web browser.

Para una aplicación internacionalizada, sigue los pasos descritos en el documento internacionalizado en la documentación JDK compilada para la plataforma para crear un archivo de propiedades conteniendo los mensajes para cada lenguaje. Un ejemplo mas se ilustrará:

Asume que el código fuente es creado en un paquete com.mycompany.mypackage, por lo que es almacenado en un directorio(relativo al directorio fuente) nombrado com/mycompany/mypackage. Para crear un recurso compilado llamado com.mycompany.mypackage.MyApplication, crearia los siguiente archivos en el directorio com/mycompany/mypackage:

• MyApplication.properties - Contiene los mensajes en el lenguaje inicial para el servidor. Si el lenguaje inicial es el Ingles, es posibles que tengas una entrada como esto: prompt.hello=Hello

• MyApplication_xx.properties - Contiene los mismos mensajes en el lenguaje cuyo código lenguaje ISO es "xx"(Ver la página ResourceBundle Javadoc para un enlace en la lista actual). Para la versión Frances de los mensajes mostrados arriba se tendrá esta entrada: prompt.hello=Bonjour Puedes tener archivos de recursos compilados para muchos lenguajes que sea necesarios.

Cuando configures el controlador servlet via el archivo de configuración struts-config.xml, una cosa que necesitaras definir es la base del nombre del recurso compilado para la aplicación. En el caso descrito arriba, este seria com.mycompany.mypackage.MyApplication.

<message-resource parameter="com.mycompany.mypackage.MyApplication"/>

La cosa importante es por el recurso compilado que se encuentran en el camino de las clases de la aplicación. Otros enfoques es almacenar en el archivo de MyResources.properties en el folder de la aplicación. Lo puedes simplificar especificando "myResources" como el valor de la aplicación. Pero ten cuidado este no debe ser borrado si construyes clases como parte de un objetivo de "limpia".

Si lo hace, aquí la tarea de Ant es correr cuando compilas la aplicación que copia el contenido del directorio src/conf al directorio clases:

<!--Copy any configuration files-->
<copy todir="classes">
<fileset dir="src/conf"/>
</copy>

3.3 Interacciones Forms y FormBean

Nota: Mientras el ejemplodado aqui usa JSP y tags personalizado, el beans ActionForm y otros componentes controladores son una Vista neutral. El framework tambien puede ser usado con Cocoon, Plantillas Velocity, XSLT y cualquier otra tecnología de presentación que pueden ser prestados vía un servlet Java.


3.3.1 Población Automática de Form

De una sola vez u otras, más desarrolladores web han construidos forms usando las capacidades estándar de HTML, tales como el tag <input>. Los usuarios han venidos esperando que las aplicaciones interactivas tengan ciertos comportamientos y una de estas expectativas relaciona el manejo de errores -- si el usuario marca un error, la aplicación debería permitir la reparación solo que sea necesario ser cambiado -- sin tener que reingresar cualquier información en la página actual o form.

Cumpliendo esta expectación es tediosa y engorrosa cuando codificamos con el estandar HTML y páginas JSP. Por ejemplo, un elemento de entrada para un campo usarname se veria como este(en JSP):

<input type="text" name="username"
value="<%= login.Bean.getUsername() >"/>

el cual es dificil para escribir correctamente, confuso a los desarrolladores HTML quien no estan bien informados acerca de los conceptos de programación y puede causar problemas con los editores HTML. En vez Struts Taglib provee una facilidad comprensiva para construir forms, basados en laBiblioteca Tag Personalizada faclitada por JSP 1.1. El caso de arriba serían prestados como se usan los Struts Taglibs:

<html:text property="username"/>;

sin necesidad para referirse de forma explicita  a el JavaBean desde el cual el valor inicial es recuperado. Eso se maneja automáticamente por el tag JSP, usando las facilidades proporcionados por el framework.

Forms HTML son algunas veces usadas para actualizar otros archivos. Mas browser esto a través de un elemento <input type="file">, que genera un botón de archivo navegable, pero le tocaal desarrollador  manejar los archivos de entrada. El framework maneja estos forms "multiparte" en un idéntico camino para construir forms normales.

Para un ejemplo de uso del framework para crear un simple form login, ver Construir un ActionForm Howto.

3.3.2 Validación Automática Form

En suma a las interacciones de form y bean descritas arriba, el framework ofrece una facilidad para validar la entrada de campos que ha recibido. Para utilizar estas características, reescribir el siguiente método en la clase ActionForm:

validate(ActionMapping mapping HttpServletRequest request);

El método validate es llamado por el controlador servlet despues la propiedad bean ha sido poblada, pero antes el correspondiente método execute de la clase action es invocada. El método validate tiene las siguientes opciones:

• Realizan la apropiada validación y no encuentran problemas -- Regresan null o una instancia de longitud cero y el controlador servlet procederá a llamar al método execute de la clase Action.
• Realizan la apropiada validación y encuentran problemas -- Regresa una instancia ActionError conteniendo ActionMessage, los cuales son clases que contienen llaves de mensajes de error(dentro compilados de MessageResource de aplicaciones) que deberían ser mostrados. El controlador servlet almacenará estas colecciones como un atributo de solicitud adecuada para el uso del tag <html:errors> y reenviará de regreso el control al form de entrada(identificado por la propiedad input para esta ActionMapping).

Como se mencionó anteriormente, estas características son enteramente opcionales. La implementación inicial del método validate regrese null y el controlador servlet asumirá que requiera cualquier validaciónque sea hecha por la clase action.

Un enfoque común  es realizarlo simple, la prima facia validación usa el método ActionForm validate y luego maneja la validacion de "lógica de negocios" desde el Action.

El Struts Validator cubierta en la proxima sección, puede ser usado para facilitar la validación ActionFroms.

3.3.3 El Validador Struts

Configurar el Validador para ejecutar la validación del form es fácil.

   1. El bean ActionForm deberá extenderse ValidatorForm.
   2. Los JSP de forms incluye el tag <html:javascript> para el lado de la validación del cliente.
   3. Deberá definir las reglas de validación en un archivo xml como este:

         <form-validation>
         <formset>
         <form name="logonForm">
            <field property="username" depends="required">
               <msg name="required" key="error.username"/>
            </field>
          </form>
          </formset>
          </form-validation>

     El punto elemental msg a la llave de recursos de mensaje  para usar cuando generamos el mensaje de error.

   4. Por último debe habilitar el ValidatorPlugin en el archivo struts-config.xml como sigue

       <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
       <set-property property="pathnames" value="/org/apache/struts/validator/validator-rules.xml, /WEB-INF/validation.xml"/>
       </plug-in>

Nota: Si requiere la propiedad de form si uno de los objetos representados de  Java de tipos primitivos(p.e. java.lang.Integer) debe establecer el paramaetro convertNull init de ActionServlet's a verdadero. Si no se hace este regresará la validación requerida no se realizará en el campo porque este será de inicio 0.

Para más acerca de Struts Validator, ver el Guía de los Desarrolladores

3.3.4 Composición de Páginas con Azulejos

Los azulejos con una poderosa biblioteca de plantillas que permite construir vistas conteniendo varios "azulejos".  He aquí una instalación rápida:

   1. Crear un archivo /layout/layout.jsp que contiene las aplicaciones comunes para verse y sentirse:

      <html>
         <body> 
            <tiles:insert attribute="body">
         </body>
      </html>

   2. Crear un archivo página de inicio /index.jsp

       <h1>This is my hompage</h1>

   3. Crear un archivo /WEB-INF/tiles-defs.xml que se vea como sigue:

      <tiles-definitions>
         <definition name="layout" path="/layout/layout.jsp">
            <put name="body" value=""/>
         </definition>
         <definition name="homepage" extends="layout">
            <put name="body" value="/index.jsp">
         </definition>
      <tiles-definitions>
    
   4. Configurar el TilesPlugin en el archivo struts-config.xml

      <plug-in className="org.apache.struts.titles.TilesPlugin">
         <set-property property="definitions-config" values="/WEB-INF/tiles-defs.xml"/>
      </plug-in>

   5.Configurar un mapeo action en struts-config.xml al punto al azulejo de la pagina de inicio:

      <action path="/index" type="org.apache.struts.actions.ForwardAction" parameter="homepage">

La configuración TilesPlugin a un especial RequesProcessor que determina si la solicitud fue vista es un azulejo y procesarlo en consecuencia. Nota que hicimos el azulejo de página de inicio extendido a nuestro plan raiz y cambiar los atributos del cuerpo. Los azulejos insertan el nombre del archivo en los atributos del cuerpo dentro del plan principal.

Ver el página web de Azulejos Struts para ejemplos en profundidad.

3.4 Presentación de Frameworks

El framework es soportado por muchas tecnologías de presentación y hay un buen de números de extensiones que facilitan la creación de componentes vistas aun más fácil. Algunas tecnologías de presentaciones populares son:

• Struts Taglib
• Struts Cocoon
• Velocity Struts
• Stxx for XLST

3.5 Otras Técnicas de Presentación

Aunque la apariencia de la aplicación puede ser completamente construida basada en las capacidades estándar de las bibliotecas de presentación, es posible que necesites emplear otras técnicas para hacer algunas respuestas directamente.

3.5.1 Componentes de Interpretación de Imágenes

Algunas aplicaciones requieren imágenes generadas dinámicamente, como los gráficos de precios en la existencia de reporte del sitio. Dos diferentes enfoques son comunmente usados para conocer estes requerimientos:

Hacer un enlace con la URL que ejecuta una solicitud servlet. El servlet usará una biblioteca de gráficos para hacer la imágen, configurar el tipo de contenido apropiadamente(tal como image/gif) y enviar de vuelta los bytes de la imagen al browser, la cual mostrará como si hubiera recibido un archivo estático.

Hacer el código HTML necesario para descargar el applet JAva que crea el gráfico solicitado. Puedes configurar el gráfico configurando los parámetros de inicialización apropiados para el applet en el código realizado, o puedes hacer el applet con la misma conexión al server para recibir estos parámetros

3.5.2 Interpretando Imágenes

Algunas aplicaciones requieren texto generado o de margen, tal como XML. Si una página completa que se quedan y puede ser la salida usando un PrintWriter, esto es muy fácil de hacer desde un Action:

response.setContentType("text/plain"); // or text/xml
PrinterWriter writer = response.getWriter();
//use writer to render  text
return(null);

Siguiente: Construcción de Componentes Controladores

© 2000-2008 Apache Software Foundation

2. Construcción de Componentes Modelo

"Si yo tengo un mundo a mi disposición, todo sería absurdo. Nada seria lo que es, porque  todo seria lo que no es. Y un sabio contrario, que es, no seria. Y que esto no seria, esto seria. Lo ves?"

2.1 Visión General

Muchos documentos de requerimientos son usados para construir aplicaciones web enfocados en la Vista. Sin embargo, debes asegurar que el proceso requerido para cada solicitud es enviada es claramente definida desde la perspectiva del Modelo. En general,  el desarrollador de los componentes Modelo será centrándose sobre la creación de clases JavaBeans que soporten todos los requerimientos funcionales. La naturaleza precisa de los beans requeridos por una aplicación en particular variará ampliamente dependiendo sobre estos requerimientos, pero ellos  pueden generalmente ser clasificados dentro de varias categorías discutidas abajo. Sin embargo,  una breve reseña del concepto de "alcance" lo que se refiere a beans y JSP es útil.

2.2 JavaBeans y Enfoques

Dentro de una aplicación web, los JavaBeans pueden ser almacenados en (y acceder desde) un numero de colecciones diferentes de "atributos". Cada colección tiene diferentes reglas del tiempo de vida de esta colección y la visibilidad de los beans almacenados ahí.  Juntos, las reglas definiendo el tiempo de vida y la visibilidad son llamados el alcance de estos beans. Las Especificaciones de las Páginas JavaServer definen las opciones de alcance usando los términos siguientes(con el equivalente concepto API servlet definido en paréntesis):

• page - Bean que es visible dentro de una página JSP, por el tiempo de vida de la solicitud actual.(Variables locales del método service)
• request - Beans que esta disponible dentro de una página JSP, así como cualquier página o servlet que sea incluido en la página o remitido por esta página.(Atributos de solicitudes)
• session - Beans que esta visible a todas las páginas JSP y servlets que participan en una sesión  particular del usuario, a través de una o mas solicitudes.(Atributos de Sesiones)
• application - Beans que esta visible a todas las páginas JSP y servlets que son parte de una aplicación web.(Atributos de contextos servlets)

Es importante recordar que las páginas JSP y servlets en la misma aplicación web comparten el conjuntos de colecciones bean. Por ejemplo, un bean almacenado como un atributo solicitud en un servlet como este:

MyCart mycart= new MyCart(...);

request.setAttribute("cart",mycart);

es inmediatamente visible a la página JSP el cual este servlet adelantado, usando un tag accion estandar como este:

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

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

2.3 ActionForm Beans

Nota: Mientras un beans ActionForm a menudo tienen propiedades que corresponden a propiedades en el bean Modelo, el bean form ellos mismos deben ser considerados un componente Controlador. Como tal, hay la capacidad para transferir información entre las capas Modelo y Vista.

El framework Struts generalmente asume que tiene definido un bean ActionForm(que es, una clase Java extendiendo la clase ActionForm) para la foms de entrada en la aplicación. Los beans ActionForms son alguna veces solamente llamados "form beans".  Estos pueden ser objetos finamente cristalizados, así que hay un bean para cada form o toscamente cristalizado de modo que  un bean sirve a varias form o aun a una aplicación entera.

Si declaras tal como los bean en el archivo de configuración Struts(ver Escribir Mapeo Action), el controlador servlet Struts automáticamente ejecutará los siguientes servicios por ti, antes de invocar el método Action apropiado:

• Chequeo para una instancia de un bean de la clase apropiada, debajo de la llave apropiada, en el apropiado alcance(solicitud o sesión).
• Si hay no muchas instancias bean  disponibles, un nuevo es automáticamente creado y añadido al alcance apropiado(solicitud o sesión).
• Por cada parámetro de solicitud cuyo nombre corresponde al nombre de una propiedad en el bean, el correspondiente método setter será llamado. Estos manejos en una manera similar a la acción estandar JSP <jsp:setProperty> cuando usas el comodín asterisco para seleccionar todas las propiedades.
• El bean actializado ActionForm será pasado por el método execute de una clase Action [org.apache.struts.Action], de modo que los valores pueden estar disponibles en el estado del sistema y los beans de la lógica de negocios.

 Para mas acerca de codificación Actions y beans ActionForm, ver la sección Construcción de Componentes Controladores.

Deben tener en cuenta que un "form"(en el sentido discutido aqui) no necesariamente corresponde a una simple página JSP en la interface de usuario. Es común en muchas aplicaciones tener un "form" (desde la perspectiva del usuario) que extienda varias páginas múltiples. Pensar, por ejemplo del estilo del asistente de la interfaz de usuario es comunmente usado cuando instalamos nuevas aplicaciones. Struts alienta definir un simple bean ActionForm que contiene propiedades para todos los campos, no importando cuales páginas el campo es actualmente mostrado. Asimismo, varias páginas del mismo form deben ser todos enviados a la misma Clase Action. Si sigues estas sugerencias, la página diseñada puede reorganizar los campos a través de varias páginas, a menudo sin requerir cambios en la lógica de procesamiento.

Aplicaciones pequeñas podrían solo necesitar un simple ActionForm para el servicio de todas las entradas forms. Otras aplicaciones usaría una simple ActionForm para cada subsistema importante de la aplicación.  Algunos equipos preferirían tener una clase ActionForm separada por cada entrada form distinta o flujo de trabajo. Cuantas o cuan pocos ActionForms  lo utilizan. Al framework no le importa.

2.4 Estados de Sistemas Beans

El estado actual de un sistema es normalmente representado como un conjunto de uno o mas clases JavaBeans, cuyas propiedades define el estado actual. El sistema de un carrito de compras, por ejemplo, incluirá un bean que represente el carrito siendo mantenido por cada comprador individual y (a través de otras cosas) incluir un conjunto de artículos que el comprador tiene actualmente seleccionado para la compra. Separadamente el sistema también incluirá deferentes beans para la información del perfil del usuario(incluyendo su tarjeta de crédito y direcciones de envío) como el catálogo de artículos disponibles y los niveles de inventarios actuales.

Para sistemas de escala pequeños o sistemas de información que no necesiten mantener un largo periodo de tiempo, un conjunto de beans de sistemas de estado podrán contener todo el conocimiento que el sistema aun  tiene en detalles particulares.  O como a menudo es el caso, el bean de sistema de estado representará información que almacene permanentemente en una base de datos externa(tal como un objeto CustomerBean que corresponde a una columna en particular en la tabla CUSTOMERS) y son creados o removidos desde la memoria del servidor como sea necesario. Entity Enterprise JavaBean son usados para este propósito en aplicaciones de de larga escala.

2.5 Lógica de Negocio Beans

Debes encapsular la lógica de la aplicación como llamadas de métodos en el diseño de JavaBeans para este propósito. Estos métodos pueden ser parte de la misma clase usadas para el beans de estado del sistema o ellos deben ser separado en clases dedicadas para la ejecución de la lógica. En este último caso usualmente necesitarás pasar al bean de sistema de estado para manipular estos métodos como argumentos.

Para un máximo reuso de código, el beans de lógica de negocios debe ser diseñado e implementado así que ellos no lo saben lo que esta  siendo ejecutado en el ambiente  de la aplicación web. Si encuentras tu mismo teniendo que importar una clase javax.servlet.* en tu bean, estas atando esta lógica de negocios al ambiente de la aplicación web. Considera reordenar las cosas a tus clases Action (parte del rol de Controlador, como se describe abajo) traducir toda la información requerida desde la solicitud HTTP siendo procesada dentro de las llamadas de  las propiedades setter sobre el bean de lógica de negocio, después el cual una llamada a un método execute puede ser hecho. Tal una clase de lógica de negocios puede ser reusada en otros ambientes de la aplicación web por la cual eran inicialmente construidos.

Dependiendo en la complejidad y alcance de la aplicación, el bean de la lógica de negocios sería un JavaBean ordinario que interactúa con el bean del sistema de estado pasando  como argumentos o un JavaBean ordinario que accesa a la base de datos usando llamadas JDBC. Para aplicaciones largas, estos bean a menudo serian en lugar de con o sin estado Enterprise JavaBean(EJBs).

Para mas acerca del uso de base de datos con tu aplicación, ver Acceso a Base de Datos HowTo.

Para mas acerca de la lógica de negocios y framework de acceso de datos, ver  llaves de teconologias primarias.

2.5.1 DynaBeans

DynaBeans combina la extensibilidad con la flexibilidad de un Mapa. Definiendo aun lo mas simple JavaBean requiere definir una nueva clase y codificación a un campo y dos nuevos métodos para cada propiedad. Las propiedades de un DynaBean puede ser configurada vía el descriptor XML. Las propiedades virtuales de un DynaBean no pueden ser llamados por métodos estandar Java, pero trabajan muy bien con componentes que confían en reflección e introspección.

En la aplicación , puedes usar DynaBeans para describir en la forms HTML. Esta estrategia puede evitar crear una subclase JavaBean formal para almacenar unas pocas propiedades simples.

Para mas acerca DynaBeans ver

• Los BeanUtils Comunes Descripción de Paquetes y Javadocs.
• Struts FormDef

2.6 Cadenas Comunes

Una técnica popular para organizar el flujo de ejecución de procesamiento complejo es el patrón "Cadena de Responsabilidad", como se describe(entre muchos otros lugares) en el clásico libre de diseño de patrones "Gang of Four". El GoF resuma el patrón de la Cadena de Responsabilidad como "Evitar acoplamiento el remitente de una solicitud que ha recibido dando mas que un objeto a cambio para el manejo de la solicitud. La cadena recibe objetos y pasa la solicitud a lo largo de la cadena hasta que un objeto los maneje."

El patrón CoR nos ayuda a mantener componentes de software vagamente acoplado. Un componente puede llamar a una Cadena de Responsabilidad, sin conocer que objetos son en la cadena o como ellos son implementados. Lo mas importante, nosotros podemos ajustar la Cadena sin cambiar como los comunicantes invocan la Cadena. Como la versión 1.3, la Solicitud Procesador inicial, la cual actúa como el "kernel" de framework, es una Cadena de Responsabilidad.

Para implementar esta Cadena, la Solicitud Procesador usa el componente Cadena de Responsabilidad en los Apache Commons los cuales proveen una implementación estándar del patrón de CoR, a lo largo de varias implementaciones del Contexto y objetos de Comando usados por la Cadena al servicio a una solicitud.

Para mas acerca de Cadena de Responsabilidad, ver

• Cadenas de Responsabilidad ordinarias
• Una vista de Cadena Ordinaria
• Código mejor con Struts 1.3

Como de Struts 1.3 Cadenas ordinarias son usados para construir Solicitudes Procesadores iniciales para el framework.

GUÍA DE USUARIO
TABLA DE CONTENIDO

1. Introducción
1.1 Hacia dentro del pasado

• 1.2.1 El Modelo:Estados de Sistema y Lógica de Negocios JavaBeans
• 1.2.2 La Vista: Páginas JSP y Componentes de Presentación

1.3 Flujo de Control

2. Construcción de Componentes Modelo
2.1 Visión General
2.2 JavaBeans y su alcance
2.3 ActionForm Beans
2.4 Estado de Sistema Beans
2.5 Lógica de Negocios Beans

• 2.5.1 DynaBeans

2.6 Cadenas Ordinarias

3. Construcción de Componentes Vista
3.1 Visión General
3.2 Internacionalización
3.3 Interacciones Forms y FormBean

• 3.3.1 Población automática de Form
• 3.3.2 Validación automática de Form
• 3.3.3 El Validador Struts 

3.4 Frameworks de Presentación
3.5 Técnicas de Presentación Directa

• 3.5.1 Componentes de Representación de Imágenes
• 3.5.2 Representación de Texto

4. Construcción de Componentes Controlador
4.1 Visión General
4.2 El ActionServlet
4.2.1 Procesador de solicitudes
4.3 Clases ActionForm
4.3.1 Clases DynaActionForm
4.3.2 Clases LazyActionForm
4.3.3 Clases Map-backed ActionForm
4.4 Clases Action
4.4.1 Pautas de Diseño de la Clase Action
4.5 Manejo de Excepciones
4.6 Clases Plugin
4.7 La Implementación ActionMapping
4.8 Escritura ActionMapping
4.8.1 Ejemplo de ActionMapping
4.9 Uso de ActionMapping  para páginas
4.10 Uso de comodines en ActionMapping
4.11 Uso de Interface de Logueo Comunes

5. Configurar aplicaciones
5.1 Visión General
5.2 El Archivo de Configuración
5.2.1 Configuración  del Controlador
5.2.2 Configuración de Mensajes de Recursos
5.2.3 Configuración de PlugIn
5.3 Configurar la aplicación por módulos
5.3.1 Archivo de Configuración de Modulo
5.3.2 Informar al Controlador
5.3.3 Conmutación de módulos
5.4 El Deployment Descriptor de la aplicación web
5.4.1 Configurar la Instancia Action Servlet
5.4.2 Configurar el Mapeo de Action Servlet
5.4.3 Configurar Struts taglib
5.5 Añadir componentes framework a la aplicación
5.6 Logging

6. Inicios
6.1 Notas de Liberación
Notas de Liberación 1.3.7
Notas de Liberación 1.3.6
Notas de Liberación 1.3.5
Notas de Liberación 1.3.4
Notas de Liberación 1.3.3
Notas de Liberación 1.3.2
Notas de Liberación 1.3.1
Notas de Liberación 1.2.9
Notas de Liberación 1.2.8
Notas de Liberación 1.2.7
Notas de Liberación 1.2.4
Notas de Liberación 1.1
Notas de Liberación 1.1-rc2
Notas de Liberación 1.1-rc1
Notas de Liberación 1.1-b3
Notas de Liberación 1.1-b2
Notas de Liberación 1.1-b1
6.2 Instalación
IPlanet
Portal Application Server
Jetty
JRun 3.0
Orion Application Server
SilverStream Application Server 3.7.1  y demas
Tomcat con Apache
BLuestone Universal Business Server 7.2
WebShere Application Server 3.5 FixPack 2
WAS con el aplicación de ejemplo
Weblogic 5.1 sp8




© 2000-2008 Apache Software Foundation

1. Introducción

"Leer las instrucciones lo dirigirán directamente a la dirección correcta"

La documentación del framework es escrita para desarrolladores de web activos y asuman como un  conocimiento de trabajo acerca de como las aplicaciones web de Java están construidas. Para mas acerca de tuercas y tornillos, visita la Key Tecnologies Primer.

1.1 Hacia el centro del Pasado!(O una breve historia de Struts)

Cuando Java servlets fueron inventados, muchos programadores rápidamente los realizaron y pensaron que eran Buenas Cosas. Estos eran rápido y mas poderoso que el estándar CGI, portable e infinitamente extensible.

Pero escribir HTML para enviar al browser en interminables sentencias println() fue tedioso y problemático. La respuesta a esto fue Páginas JavaServer, las cuales turnaron la escritura dentro-fuera del Servlet. Ahora los desarrolladores podrán fácilmente combinar código HTML con Java y tener todas las ventajas del servlet. El cielo fue el límite.

Las aplicaciones web Java se convirtieron rápidamente en "JSP centric". Este en y de este mismo no fue una Mala Cosa, pero fue pequeño para resolver cuestiones de flujo de control y otros problemas endémicos a las aplicaciones web.

Claramente, otros paradigmas fueron necesarios.

Muchos desarrolladores inteligentes que realizaron páginas JSP y servlets podrían usar ambos para desplegar la aplicación web. Los servlet podrán ayudar con el flujo de control y los JSPs podrán enfocar en los sucios negocios de escribir HTML.  En cursos dúos, usar ambos JSPs y servlets se convertirán en conocidos Modelo 2(significado, presumiblemente,  que usen solo JSP que fue Modelo 1).

Por supuesto, no hay nuevos debajo el Sol... y muchos tienen un rápido punto de salida que el Modelo 2 de JSP seguidos del clásico patrón de diseño Modelo-Vista-Controlador abstracto desde el venerable framework Smalltalk MVC. los desarrolladores web Java ahora tienden a usar los términos de intercambio del Modelo 2 y MVC. En esta guía, nosotros usaremos el paradigma MVC para describir la arquitectura del framework, los cuales podrían  ser los mejores diseños denominados como Modelo 2/MVC.

El proyecto Apache Struts fue lanzado en Mayo 2000 por Craig R McClanahan para proveer un framework estándar MVC a la comunidad Java. En Julio 2001, la versión 1.0 fue liberado y IOHO, el desarrollo Modelo 2 Java nunca ha sido lo mismo.

1.2 Diseño de patrones Modelo-Vista-Controlador('MVC')

El termino "MVC" se origino en el framework de SmallTalk Modelo-Vista-Controlador. Debajo MVC, una aplicación es vista como tener tres partes distintas. El problema dominante es representado por el Modelo. La salida al usuario es representado por la Vista. Y la entrada desde el usuario es representado por el Controlador.

1.2.1 El Modelo: Sistemas de Estado y Lógica de Negocios JavaBeans

La porción del Modelo de un sistema basado en MVC puede ser a menudo dividido en dos subsistemas importantes -- el estado interno del sistema y las acciones que pueden tomar el cambio de este estado.

En términos gramaticales, podríamos pensar acerca del estado de la información como sustantivos(cosas) y acciones como verbos(cambios al estado de esas cosas).

Muchas aplicaciones representan el estado interno del sistema como un conjunto o mas de JavaBeans. Las propiedades bean representan los detalles del estado del sistema. Dependiendo de la complejidad de la aplicación, estos beans pueden ser auto contenidos(y conocidos como la persistencia de su propio estado) o ellos podrían ser la fachada que se conoce como la recuperación del estado del sistema desde otro componente. Este componente puede ser una base de datos, una máquina de búsqueda, Entity Enterprise JavaBean, un servidor LDAP o algo completamente distinto.

Apliacaciones de larga escala a menudo representan un conjunto de posibles operaciones de negocios como métodos que pueden ser llamados en un bean o beans manteniendo el estado de información. Por ejemplo es posible que tenga un carrito de compras bean, almacenados en sesiones de alcance por cada uno de los usuario actuales, con propiedades que representan el conjunto actual de artículos que el usuario ha decidido comprar. Este bean también podría tener un método checkOut() que autorize la tarjeta de crédito del usuario y enviar la orden al almacén  de datos para ser recogido y transportado. Otros sistemas representarían las operaciones disponibles separamente, quizás como Session Enterprise JavaBeans(Sesione EJB).

En una pequeña  aplicación a escala, en la otra mano, la disponibilidad de operaciones puede ser empotradas dentro de las clases Action que son parte del framework de la capa de control. Este puede ser útil cuando la lógica es muy simple o donde se reuse la lógica de negocios en otros ambientes que no estén contemplados.

La arquitectura del framework es suficientemente flexible para soportar cualquier propuesta para acceder al Modelo, pero nosotros fuertemente recomendado que separa la lógica de negocios("como se hizo") desde el rol que las clases Action juegan("que hacer").

Para mas acerca  para adaptar el Modelo de las aplicaciones al framework, ver el capítulo Construcción de Componentes  Modelo.

1.2.2. La Vista: Páginas JSP y Componentes de Presentación

La porción Vista de una aplicación basada en Struts es a menudo construida usando la tecnología de Páginas JavaServer. Las páginas JSP pueden contener texto HTML estático(o XML) llamado "plantilla de texto", mas la habilidad para insertar contenido dinámico basado en la interpretación(en la página de solicitud de tiempo) de acciones de tag especiales. El ambiente JSP incluye un conjunto de tag estándar action, tales como <jsp:useBean> cuyo propósito es descrito en las Especificaciones de Páginas JavaServer. En suma a las acciones built-in, hay una facilidad estándar para definir nuestros propios tags, las cuales son organizadas dentro de "custom tab libraries."

El framework incluye un conjunto de bibliotecas tag que facilita crear interfaces de usuario que son totalmente internacionalizado e interactúa gratamente con los beans ActionForm. Los ActionForms capturan y validan cualquier entrada si es requerida por la aplicación.

Para mas acerca de tablis Struts y el uso de páginas de presentación con el framework, ver la sección Construcción de Componentes Vista. La documentación adicional respecto a los taglibs esta disponible en el subproyecto Taglibs.

1.2.3 El Controlador: ActionServlet y ActionMapping

Struts provee la porción Controlador de la aplicación. El controlador es enfocado en recibir solicitudes desde el cliente(típicamente un usuario en un web browser), decide que función de lógica de negocios es ejecutada y este delegando responsabilidad para producir la próxima fase de la interfase de usuario a un apropiado componente Vista. El componente primario del Controlador en el framework es un servlet de clase ActionServlet. Este servlet es configurado para definir un conjunto de ActionMapping.  Un ActionMapping define un camino(path) que es igualado con la solicitud URI de la solicitud de entrada y usualmente especifica el nombre de clase complemente competente de una clase Action. Todas las Actions son subclases desde [org.apache.struts.action.Action]. Las Actions encapsulan las llamadas a la clse de la lógica de negocios, interpretando los resultados  y en última instancia el control de despacho al apropiado componente Vista para crear la respuesta. Mientras el framework despacha a la Vista, actualmente la prestación a la Vista es la salida este de su ámbito de aplicación.

El framework también soporta la capacidad de usar las clases ActionMapping que tienen propiedades adicionales mas allá del estandar requerido para operar el controlador. Este permite almacenar información especifica adicional a la aplicación y todavía utilizar las caracteristicas restantes del framework. En suma, el framework te permite definir la lógica "nombres" a que control deberá  ser remitido así que un método acción puede preguntar por la página del "Menú Principal" (por ejemplo), sin conocer la ubicación de la página JSP correspondiente. Estas características en gran medida ayudan en separar la lógica de control(que hacer) con la lógica de la vista(como fue interpretado).

Para más acerca de la capa control, ver el capítulo Construcción de Componentes Controladores.

1.3 Framework Control de Flujo

El framework provee varios componentes que maquillan la capa Control de una aplicación estilo MVC. Esta incluye un componente controlador(servlet), manejador de solicitudes definidos por el desarrollador y varios objetos de soporte.

El componente Struts Taglib provee soporte directo a la capa Vista de la aplicación MVC. Algunos de estos tags acceden a los objetos de la capa control. Otros son tags genéricos que se encuentran convenientes cuando escribes aplicaciones. Otros tags, incluidos JSTL pueden ser usados con el framework. Otras presentaciones de tecnologías, como las plantillas Velocity  y XSLT pueden ser usadas con el framework.

La capa Modelo en una aplicación MVC es a menudo un proyecto especifico. EL framework es diseñado para hacer fácil el acceso el fin del negocio de la aplicación, pero deja esa parte de la programación a otros productos, como JDBC, Enterprise Java Beans, Object Relational Bridge o iBATIS por nombrar unos pocos.

Repasemos como encaja todo

Cuando inicializamos, el controlador analiza el archivo de configuración(struts-config.xml) y lo usa para desplegar otros objetos de capas de control. Ambos, estos objetos forman el Struts Configuration. La configuración define (entre otras cosas) la colección de ActionMapping[org.apache.struts.action.ActionMapping] para una aplicación.

El componente controlador consulta los ActionMappings como las solicitudes de rutas de HTTP a otros componentes en el framework. Las solicitudes pueden ser remitido a las Páginas JavaServer o subclases  Action[org.apache.struts.action.Action] previstas por la aplicación del desarrollador. A menudo una solicitud es primera en ser remitida a una Action y luego a un JSP(u otras páginas de presentación). El mapeo ayuda al controlador turnar solicitudes HTTP dentro de las acciones de la aplicación.

Una ActionMapping individual[org.apache.struts.action.ActionMapping]  por lo general contiene un número de propiedades incluidas:

• un camino de solicitud(o "URI")
• el tipo de objeto(subclases Action) para actuar sobre la solicitud
• otras propiedades como sean necesarias

El objeto Action puede manejar la solicitud y responder al cliente(por lo general un Web browser) o indicar que control será remitido a otros lugares. Por ejemplo si un login tiene éxito, una acción login tal vez desee enviar la solicitud en la página mainMenu.

Objetos Action tienen acceso a los controladores de componentes de las aplicaciones y así que tienen acceso a esos métodos  de miembros. Cuando enviamos el control un objeto Action puede indirectamente enviar uno o mas objetos compartidos incluyendo JavaBeans, colocándolos en uno de los contextos estándar compartidos por Java Servlets.

Por ejemplo, un objeto Action puede crear un bean  carrito shopping, añadir un artículo al carrito, colocar el bean en el contexto de sesión y a continuación enviar el control a otro mapeo. Ese mapeo puede utilizar una página JavaServer para mostrar el contenido del carrito de usuario. Desde cada cliente tiene su propia sesión, lo harán cada vez uno también su propio carrito shopping.

La mayoría de la lógica de negocios en una aplicación puede ser representada usando JavaBeans. Un Action puede llamar las propiedades de un JavaBEan sin conocer como trabaja actualmente. Este encapsula la lógica de negocios, así que puede enfocar un manejo de error y donde enviar el control.

JavaBeans puede  ser usado para manejar la entrada forms. Un problema principal en el diseño de aplicaciones Web es la retención y validación que un usuario tiene registado entre solicitudes. Puede definir su propio conjunto de clases de entrada bean, de subclases ActionForm[org.apache.struts.action.ActionForm].  La clase ActionForm lo hace fácil de almacenar y validar los datos de las entradas forms de la aplicación. El bean ActionForm es automaticamente guardado en un estándar, compartir el contexto de las colecciones, así que este puede ser usado por otros objetos, como un objeto ACtion u otro JSP.

El form bean puede ser usado por un JSP para colectar datos desde el usuario por un objeto Action para validar el dato de entrada del usuario y por el JSP otra vez repoblar los campos del form. En el caso de errores de validación, el framework tiene un mecanismo de almacenado para el levantamiento y mostrar los mensajes de error.

Otros elementos de al configuración son los ActionFormBeans[org.apache.struts.action.ActionFormBeans]. Esta es una colección de objetos descriptor que son usados para crear instancias de los objetos ActionForm en tiempo de ejecución.  Cuando un mapeo es necesario como ActionForm, el servlet busca el descriptor form-bean por el nombre y usa para crear una instancia ActionForm del tipo especifico.

Aquí esta la secuencia de eventos que ocurren cuando una solicitud llama para un mapeo que usa un ActionForm:

• El controlador servlet ya sea que recupere o crea las instancias bean ActionForm.
• El controlador servlet pasa el bean al objeto Action.
• Si la solicitud esta siendo usada para entregar una página de entrada, el objeto Action puede examinar la información. Si es necesario, la información puede ser enviada de regreso a lo largo de forms de entrada con una lista de mensajes para mostrar sobre la página. De otra manera la información puede ser pasada a lo largo del nivel de negocios.
• Si la solicitud esta siendo utilizada para crear  una página de entrada, el objeto Action puede poblar el bean con cualquier información que la página de entrada podría necesitar.

El componente Struts Taglib provee tags personalizados que pueden automáticamente poblar campos desde un JavaBean. Casi todas las Páginas JavaServer realmente necesitan conocer si el nombre del campo se usa y donde lo entrega el form.

Otros tags pueden automáticamente poner en cola mensajes de salida por un Action o ActionForm y simplemente necesitan estar integrados dentro del marco de las páginas. El mensaje esta diseñado para la localización y hará que el mejor mensaje disponible para el lugar del usuario.

El framework y Struts Taglib fueron diseñados desde el con soporte de características de construcción de internacionalización dentro de la plataforma Java. Todas la etiquetas de los campos y mensajes pueden ser recuperados desde una fuente de mensajes. Para proveer otro lenguaje. simplemente añadir otro archivo a la fuente de paquetes.

El internazionalismo de este lado, otros beneficios a los recursos de mensajes se enfocan son consistentes etiquetando entre forms y la habilidad de repasar todas las etiquetas y mensajes desde un lugar cental.

Por la mas simple aplicación, un objeto Action pueden algunas veces manejar la lógica de negocios asociado con una solicitud. Sin embargo, en la mayoría de los casos, un objeto Action deberá invocar otros objetos, por lo general un  JavaBean para ejecutar la lógica de negocios actual. Este deja al Action enfocar un manejo de  error y flujo de control, mas bien que la lógica de negocios.  Permite reusar sobre otras plataformas, la lógica de negocios JavaBeans no deberá  referir a cualquier objeto de aplicación Web. El objeto Action deberá traducir los detalles necesarios desde la solicitud HTTP y pasar estos a lo largo del bean de lógica de negocios como variables regulares Java.

En una aplicación de base de datos, por ejemplo:

• Un bean de lógica de negocios se conectará y la consulta a la base de datos
• El bean de lógica de negocios regresa un resultado al Action
• El Action almacena el resultado en un bean form en la solicitud
• La página JavaServer muestra el resultado en una forma HTML

Ni el Action o el JSP necesitan saber(o cuidar) desde donde el inicia el resultado. Ellos solo necesitan conocer el paquete y mostrarlo.

Otras secciones en este documento cubre varios componentes en mayor detalle. El componente Struts Taglib incluye varios temas de Guías de Desarrollo cubriendo aspectos de tags personalizados. Un número simple de aplicaciones son compilados con la distribución que muestran como todos se reúnen.

El framework es distribuido bajo la licencia Apache Software Foundation. El código tiene derechos de autor, pero es libre para usar en cualquier aplicación.

Siguiente: Construcción de Componentes Modelo

© 2000-2008 Apache Software Foundation

¿Como funciona Struts?

[Desde la página Kickstart FAQ]

"Java Servlet está diseñado para manejar solicitudes hechas por el browser. Las páginas del servidor están diseñadas  para crear páginas web dinámicas que puedan turnar los sitios en cartelera dentro de aplicaciones interactivas. Struts usa un servlet especial como un centro de control para la rutas de solicitudes desde el browser a las apropiadas páginas del servidor. Esto hace que las aplicaciones web sean mucho mas fácil para diseñar, crear y mantener."

Esta es una buena descripción de alto nivel, pero dejar describir el mecanismo y las dependencias del framework en más detalle.

• La aplicación web que desarrolles tiene un deployment descriptor[descriptor de despliegue](WEB-INF/web.xml) el cual deberás escribir. Este archivo describe la configuración de tu aplicación web, incluyendo páginas de bienvenida(el archivo que es mostrados en un directorio cuando ninguna es especificada por la solicitud), mapeando los servlets(rutas o extensiones de nombre) y parámetros de aquellos servlets. En el archivo web.xml, configuras el framework ActionServlet como un servlet que manejará todas las solicitudes por un mapeo dado(usualmente la extensión usada es .do). El ActionServlet es el "centro de control" mencionado en el párrafo de apertura. También en el web.xml, configuras el ActionServlet para usar uno o más archivos de configuración para el mismo Struts. Por ahora, digamos instalamos la aplicación web en el servidor usando como ubicación /myapp y usaremos la mas simple configuración posible de esta. Si necesitas mas detalles sobre deployment descriptors,  revisa las Especificaciones  de Servlet disponibles en el sitio de Java de Oracle.
• En los archivos de configuración del framework, se asocian rutas con los componentes del controlador de la aplicación, conocido como clases Action(es decir "login" ==> clase LoginAction). Este le dice al ActionServlet que para una solicitud de entrada http://myhost/myapp/login.do este deberá invocar al componente controlador, LoginAction. Nota la extensión .do en esta URL. La extensión hace que tu contenedor (por ejemplo Tomcat) llame al ActionServlet, el cual ve la palabra "login" como una cosa que quieres hacer. La configuración es referenciada y tu LoginAction es ejecutado.
• Por cada Action, también puedes configurar el framework con los nombres del resultado de las páginas que se muestran como resultado de la acción. Ahí puede haber más de una vista como resultado de una acción(a menudo hay al menos dos: una para los "success"[éxitos] y una para las "failure"[fracaso] ). Tu Action (el componente controlador que escribiste) es basado sobre estas lógicas de resultados de nombres de mapeo. Este reporte al ActionServlet usando palabras como "success", "failure", "ready", "ok", "UserError", etc. El framework(a traves de la configuración escrita) conoce como avanzar a la página específica correcta. Tienes que añadir la ventaja de reconfigurar la capa vista por simple edición del archivo de configuración XML. En este punto, el framework conoce como delegar los componentes del controlador  y que mostrará como resultado del proceso del controlador.
• Puedes también asociar un JavaBean con una acción(o conjunto de acciones) en el archivo de configuración del framework. El JavaBean es usado como un repositorio para un form o mostrar datos que se puedan comunicar entre las vistas y la capa del controlador. Estos Beans son automáticamente hechos visibles a los componentes del controlador(como la clase LoginAction) y cualquier página vista que es asociada con este controlador. Estos Beans pueden también ser validados con la ayuda del framework para ayudar asegurar que el usuario poner buenos datos en el form. Ellos pueden ser realizados a lo largo de una sesión, permitiendo forms para el lapso de múltiples páginas del a vista, Actions en el controlador. Nota: Deberías usar alguna tecnología pequeña del lado del servidor(JSP, Velocity, XSLT) para la capa vista(hacia el cliente) para ver este dato(HTML plano no funciona). El framework trabaja en el lado del servidor, así que las vistas del cliente estarán compuestas. Las alimentaciones del cliente al dato regresan a través de los métodos de form normal de entrega(POST/GET) y el framework actualiza estos datos en el Bean antes de llamar a los componentes del controlador.
• Dentro de tu aplicación web estarán las páginas que representan las vistas de los usuarios verán. Estas pueden ser páginas JSP, plantillas Velocity, páginas XSLT y así sucesivamente. Conjuntos de tags de JSP y JSTL están disponibles para el framework así que puedes iniciar inmediatamente, pero cualquier tecnología estándar de presentación puede ser usada con el framework. Aun archivos planos HTML pueden ser usados dentro de la aplicación, sin embargo estos no tomaran ventaja de todas las características dinámicas. Siguiendo el ejemplo de las taglibs Struts JSP, varios paquetes están disponibles para hacer el framework fácil de usar con tu tecnología favorita de presentación. Para plantillas Velocity hay las ViewTools Velocity para Struts. Si quieres usar XSLT en tu aplicación, puedes escoger entre stxx y StrutsCX. Estos paquetes hacen el elemento estándar Struts framework se vea y se sienta como una parte de la tecnología de presentación original sin costura. Struts también lo hace fácil de mezclar e igualar. Si lo necesitas puedes utilizar JSP, plantillas Velocity y XSLT todo en la misma aplicación! Desde Struts depende en los estándares de tecnologías Servlet, deberías ser capaz de usar cualquier tecnología de presentación Java con Struts.
• Mientras el enfoque del framework Struts es en el controlador, la capa de presentación es una parte significante de cualquier aplicación. Los taglib Struts JSP incluye un número de tag genéricos y específicos de Struts para ayudar al uso dinámico de datos en la vista. Los tags a cuenta personalizados JSP para un buen  trato del código base de Struts. Esto es educacional para anotar como de la versión 1.1b3 el código Java para el corazón de Struts fue de 28,000 lineas y el código Java para las bibliotecas tag(incluyendo baldosas) fue acerca de 41,000 lineas. Estos tags ayudan pegar a la capa vista a la capa controlador sin tener que empotrar un poco de Java en el JSP. Este da la página una vista XML y puede ser más fácil para los diseñadores web para tratar  con un JSP plano. Este también ayuda minimizar dependencias entre el controlador y la vista. Los tags personalizados son usados para crear forms(y interactuar invisiblemente con el Bean mencionado previamente), lógicamente hacia adelante a otras páginas e invocar otras acciones de las aplicaciones web. Hay también tags que ayudan con la internacionalización, errores de mensajes, etc. Todas de estas habilidades depende en el mismo camino en la configuración de archivos suministrados a Struts.

 Esto es importante para recordar que el mecanismo descrito aquí es solo un efecto cuando el ActionServlet es manejado por la solicitud.

Desde esto solo pasa cuando una solicitud es entregada que causa al contenedor(por ejemplo Tomcat, WebShere, etc) para llamar ActionServlet, deberás estar seguro que cualquier página depende en Struts esta hecho a través que será mapeado al ActionServlet(por ejemplo este tiene la extensión .do).

© 2000-2008 Apache Software Foundation