"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.
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.
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.
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.
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.
No hay comentarios:
Publicar un comentario