Manual Básico de Struts

El Controller comprende la funcionalidad involucrada desde que un usuario genera un est�mulo (click en un link, env�o de un formulario, etc.) hasta que se genera la interfaz de respuesta. Entre medio, llamar� a los objetos de negocio del Model para que resuelvan funcionalidad propia de la l�gica de negocio y seg�n el resultado de la misma ejecutar� la JSP que deba generar la interfaz resultante.

Struts incluye un servlet que a partir de la configuraci�n de struts-config.xml recibe las solicitudes del usuario, llama al Action Bean que corresponda y, seg�n lo que �ste retorne, ejecuta una JSP. Por consiguiente, las tareas que se deben realizar son:

  1. Escribir una clase Action que extienda de org.apache.action.Action. Ver secci�n "Controller Action Bean".
  2. Configurar el struts-config.xml para que incluya el nuevo action mapping y sus posibles forwards de salida. Por ejemplo:
  3. <struts-config>
    ...
      <action-mappings>
    ...
        <action path="/logoff" type="com.empresa.aplicacion.LogoffAction">
          <forward name="success" path="/index.jsp"/>
        </action>
    ...
      </action-mappings>
    ...
    </struts-config>
    

    En este caso, cuando la solicitud sea "/logoff" el Controller llamar� a LogoffAction y si esta retorna un ActionForward con valor success entonces ejecutar� /index.jsp. Pero... �qu� pasa si es una acci�n asociada a un formulario? La respuesta es un poco m�s compleja: se debe definir un Form Bean, un Action Mapping con el Form Bean asociado y el o los forwards necesarios. Por ejemplo:

    <struts-config>
    ...
      <form-beans>
    ...
        <form-bean  name="logonForm" type="com.empresa.aplicacion.LogonForm"/>
    ...
      </form-beans>
    ...
      <global-forwards>
    ...
        <forward   name="success" path="/mainMenu.do"/>
    ...
      </global-forwards>
    ...
      <action-mappings>
    ...
        <action path="/logon" type="com.empresa.aplicacion.LogonAction" 
                name="logonForm" scope="request" input="/logon.jsp"> </action>
    ...
      </action-mappings>
    ...
    </struts-config>
    

    En este caso se ha definido un global-forward que, como su nombre lo indica, viene a ser un forward que se aplica a todos los action-mappings (excepto que se re-defina para alguno en particular).

  4. Incluir los links (preferentemente utilizando <html:link>) o forms (necesariamente utilizando <html:form>) necesarios en las JSPs correspondientes.

.�ActionForm Beans

Los ActionForm Beans son clases que extienden ActionForm y que implementan m�todos get y set para cada una de los inputs de un form de una p�gina, y los m�todos validate y reset.

Cuando un usuario completa un formulario y lo env�a, el Controller busca en el scope especificado el ActionForm Bean correspondiente (todo esto configurado en el struts-config.xml) y si no lo encuentra lo crea. Luego realiza un set por cada input del form y finalmente llama al m�todo validate. Si �ste retornara uno o m�s errores, el Controller llamar�a a la JSP del formulario para que �sta lo volviera a generar (con los valores establecidos por el usuario) e incluyera el o los mensajes de error correspondientes. Si todo estuviese bien, llamar�a al m�todo perform del Action (tambi�n configurado en el struts-config.xml) pas�ndole el ActionForm Bean como par�metro para que sea utilizado para obtener los valores de los datos.

Si bien el ActionForm tienen caracter�sticas que corresponden al Model, los ActionForm pertenecen a la View. Justamente uno de estos puntos comunes es la validaci�n de datos y a fines de evitar la duplicaci�n de funcionalidad, si un desde un ActionForm debe realizar controles de validaci�n que se hubiesen implementado en un objeto de negocio entonces se deber�a utilizar una instancia de �ste para efectuarlos. Ejemplo:

public final class ClienteForm extends ActionForm {
 private String nombre = null;
 ActionErrors errors = null;
 Cliente cliente = null;
 ...
 public ClienteForm() {
  ...
  // Crear u obtener el objeto como sea...
  cliente = new Cliente(); 
  errors = new ActionErrors;
  ...
 }
 public String getNombre() {
  return (this.nombre);
 }
 public void setNombre(String nombre) {
  try {
   cliente.setNombre(nombre);
  } catch (Exception e) {
   errors.add("nombre", new ActionError("error.nombre"));
  }
  this.nombre = nombre;
 }
 public void reset(ActionMapping mapping, HttpServletRequest request) {
  this.nombre = null;
 }
 public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) {
  ...
  return errors;
 }
}

Al momento de escribir un ActionForm debemos tener en mente los siguientes principios:

  • No debe tener nada que corresponda a la l�gica de negocio
  • No deber�a tener m�s que implementaciones de getters y setters (obligatoriamente un par por cada input del form; si el input se llama nombre entonces tendremos getNombre() y setNombre(String nombre)), y de los m�todos reset y validate
  • Debe ser un Firewall entre el usuario y el Action que detenga todo tipo de errores de incompletitud o inconsistencia
  • Si el formulario se desarrolla en varias p�ginas (por ejemplo, en las interfaces de tipo "Wizard"/"Asistentes") el ActionForm y el Action deber�n ser los mismos, lo que permitir�, entre otras cosas, que los input se puedan reorganizar en distintas p�ginas sin cambiar los ActionForm ni los Action

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP