Tutoriales de Programacion Java

Struts 2 - Parte 4: Scopes de Objetos Web

2011-12-19T21:54:00.000-08:00

Cuando estamos desarrollando una aplicación web debemos almacenar información que será procesada de distinta manera. Dependiendo de cuál sea el propósito de esta información querremos que tenga un tiempo de vida más corto o más largo, alguna información deberá permanecer disponible durante todo el momento que viva nuestra aplicación, mientras que otra solo nos interesará que viva durante una petición. Además habrá información que pertenecerá a cada usuario que acceda a la aplicación y que deberá estar disponible sólo para el usuario correspondiente.

Estos tiempos de vida son llamados scopes, y en las aplicaciones web tenemos un cierto número de ellos. Es importante conocer estos scopes y ver qué tipo de información es conveniente colocar en cada uno de ellos. A la información que colocamos en los distintos scopes les llamamos atributos.

También algunas veces es necesario tener un acceso directamente a los objetos del API de Servlets, como el "HttpServletRequest", o el "ServletContext", o a los parámetros de la petición,

Struts 2 nos proporciona una forma simple y elegante, además de diversa, para manejar todas estas cosas y en este tutorial aprenderemos estas maneras ^_^.

Las aplicaciones web con Java tienen básicamente tres scopes o tiempos de vida:

Application: Es el scope más largo ya que abarca el tiempo de vida completo de la apicación; esto es, los datos vivirán mientras la aplicación esté activa.
Session: Este scope nos permite tener datos que vivirán a lo largo de múltiples peticiones HTTP para un mismo usuario, mientras el usuario esté dentro de la aplicación. Cada usuario verá únicamente sus datos y no habrá forma de que vea los de los demás.
Request: Este es el scope más pequeño, los datos asociados con la petición únicamente estarán disponibles mientras se realiza dicha petición.

Existen algunos otros scopes, pero estos son los más y importantes, además no todos los frameworks proporcionan acceso a los demás scopes.

La información o atributos que se puede colocar dentro de estos scopes son pares nombre valor, en donde el nombre debe ser una cadena y el valor puede ser cualquier objeto que nosotros queramos.

Struts 2 nos proporciona tres formas para colocar y leer los atributos que se encuentren en estos scopes:

Implementación de interfaces Aware
Uso del objeto "ActionContext"
Uso del objeto "ServletActionContext"

Las tres son igual de sencillas y nos permiten obtener más o menos los mismos resultados.

Además podemos usar dos de los métodos anteriores, las interfaces Aware y el objeto "ServletActionContext", para obtener acceso directo a los objetos "HttpServletRequest" y "ServletContext"

Lo primero que haremos es crear un nuevo proyecto web en NetBeans. Vamos al menú "File -> New Project...". En la ventana que aparece seleccionamos la categoría "Java Web" y en el tipo de proyecto "Web Application". Presionamos el botón "Next >" y le damos un nombre y una ubicación a nuestro proyecto; presionamos nuevamente el botón "Next >" y en este punto se nos preguntará el servidor que queremos usar. En nuestro caso usaremos el servidor "Tomcat 7.0", con la versión 5 de JEE y presionamos el botón "Finish".

Una vez que tengamos nuestro proyecto debemos recordar agregar la biblioteca "Struts2" (o "Struts2Anotaciones" si van a hacer uso de anotaciones, como es mi caso ^_^), que creamos en el primer tutorial de la serie de Struts 2. Hacemos clic derecho sobre el nodo "Libraries" del proyecto. En el menú que aparece seleccionamos la opción "Add Library...". En la ventana que aparece seleccionamos la biblioteca "Struts2" o "Struts2Anotaciones" y presionamos "Add Library". Con esto ya tendremos los jars de Struts 2 en nuestro proyecto.

Ahora configuramos el filtro "struts2" en el deployment descriptor. Abrimos el archivo "web.xml" y colocamos el siguiente contenido, como se explicó en el primer tutorial de la serie:


<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>struts2</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Comenzaremos viendo cómo poder agregar y leer datos en los scopes anteriores, y cómo mostrarlos en nuestras JSPs.

Manejo de Scopes

Manejo de Scopes usando interfaces Aware

Struts 2 proporciona un conjunto de interfaces llamadas interfaces Aware (bueno, creo que solo yo las llamo así ^_^) las cuales permite que nuestros Actions reciban cierta información, al momento de inicializarlos. La mayoría de estas interfaces proporcionan un Map con los pares nombre valor de los atributos de cada uno de los scopes.

Struts 2 contiene las siguientes interfaces Aware para obtener y leer atributos de los scopes:

ApplicationAware
SessionAware
RequestAware

Además de un par de interfaces para recibir el "HttpServletRequest" y el "ServletContext", pero hablaremos de ellas en su momento.

El uso de estas interfaces es muy intuitivo, creamos un Action que implemente la interface que nos interese. Cada una de estas interfaces proporciona un método setter que permite inyectar el mapa con los atributos del scope correspondiente.

Los métodos de estas interfaces se muestran a continuación:


public interface RequestAware
{
    public void setRequest(Map<String, Object> map);
}

public interface SessionAware
{
    public void setSession(Map<String, Object> map);
}

public interface ApplicationAware
{
    public void setApplication(Map<String, Object> map);
}

La forma de los tres métodos es prácticamente la misma: no regresan nada y reciben como único parámetro un Map donde el nombre del atributo es un String y el valor es un Object.

Como la forma de trabajo con estas tres interfaces es también el mismo, hagamos un ejemplo de todo en uno.

Lo primero que haremos es crear una nueva JSP llamada "datosScopesInterfaces.jsp":

Esta página contendrá un formulario que nos permitirá establecer el valor de algunos datos que colocaremos posteriormente en cada uno de los scopes. Como usaremos las etiquetas de Struts 2 para generar este formulario, lo primero que debemos hacer es indicar, con la directiva "taglib", que usaremos la bibliotecas de etiquetas de Struts 2:


<%@taglib prefix="s" uri="/struts-tags" %>

Ahora crearemos un formulario con unos cuantos campos de texto, para colocar los valores que enviaremos a nuestro Action para ser procesados. Cada uno de estos valores tendrá un nombre que indica en cuál scope quedará. Este formulario se enviará a un Action llamado "scopesInterfaces" que crearemos un poco más adelante:


<s:form action="scopesInterfaces">
    <s:textfield name="datoSesion" label="Sesion" />
    <s:textfield name="datoRequest" label="Request" />
    <s:textfield name="datosAplicacion" label="Aplicacion" />
    <s:submit />
</s:form>

Ahora crearemos un nuevo paquete, llamado "com.javatutoriales.actions", para colocar nuestros Actions. Dentro de este paquete crearemos una clase llamada "ScopesInterfacesAction", esta clase deberá extender de "ActionSupport":


public class ScopesInterfacesAction extends ActionSupport
{
}

Agregaremos un atributo de tipo String, con sus correspondientes setters, para cada uno de los campos del formulario:


public class ScopesInterfacesAction extends ActionSupport
{
    private String datoSesion;
    private String datoRequest;
    private String datosAplicacion;

    public void setDatoRequest(String datoRequest)
    {
        this.datoRequest = datoRequest;
    }

    public void setDatoSesion(String datoSesion)
    {
        this.datoSesion = datoSesion;
    }

    public void setDatosAplicacion(String datosAplicacion)
    {
        this.datosAplicacion = datosAplicacion;
    }
}

Sólo hemos colocado los setters porque estableceremos estos valores en los scopes correspondientes y, por lo tanto, los leeremos posteriormente de una manera diferente ^_^.

Ahora el tema que nos interesa, las interfaces. Como toda buena interface de Java, para implementar las interfaces Aware lo primero que debemos hacer es declarar que nuestra clase implementará estas interfaces; implementaremos las tres interfaces de una sola vez:


public class ScopesInterfacesAction extends ActionSupport implements RequestAware, SessionAware, ApplicationAware
{
}

Como mencioné antes: estas interfaces tienen solo un método cada una (el método que mencioné anteriormente). Normalmente colocamos un atributo, de tipo "Map<String, Object>" para almacenar el argumento que es establecido por el framework y poder usarlo posteriormente en el método "execute" de nuestro Action; después todo lo que hay que hacer es implementar cada uno de los métodos de estas interfaces de la siguiente forma:


private Map<String, Object> sesion;
private Map<String, Object> application;
private Map<String, Object> request;

public void setRequest(Map<String, Object> map)
{
    this.request = map;
}

public void setApplication(Map<String, Object> map)
{
    this.application = map;
}

public void setSession(Map<String, Object> map)
{
    this.sesion = map;
}

En el método "execute" lo único que haremos es agregar el valor recibido desde el formulario al scope correspondiente, usando el "Map" apropiado:


@Override
public String execute() throws Exception
{
    application.put("datoAplicacion", datosAplicacion);
    sesion.put("datoSesion", datoSesion);
    request.put("datoRequest", datoRequest);
        
    return SUCCESS;
}

Así de simple ^^.

Para terminar este Action debemos agregar las anotaciones que vimos en el primer tutorial de la serie, y que a estas alturas ya conocemos de memoria. El nombre de nuestro Action será "scopesInterfaces" y el resultado será enviado a la página "resultado.jsp":


@Namespace(value = "")
@Action(value = "scopesInterfaces", results ={@Result(name = "success", location = "/resultado.jsp")})
public class ScopesInterfacesAction extends ActionSupport implements RequestAware, SessionAware, ApplicationAware
{
}

La clase "ScopesInterfacesAction" completa queda de la siguiente forma:


@Namespace(value = "")
@Action(value = "scopesInterfaces", results ={@Result(name = "success", location = "/resultado.jsp")})
public class ScopesInterfacesAction extends ActionSupport implements RequestAware, SessionAware, ApplicationAware
{
    private String datoSesion;
    private String datoRequest;
    private String datosAplicacion;
    private Map<String, Object> sesion;
    private Map<String, Object> application;
    private Map<String, Object> request;

    @Override
    public String execute() throws Exception
    {
        application.put("datoAplicacion", datosAplicacion);
        sesion.put("datoSesion", datoSesion);
        request.put("datoRequest", datoRequest);

        return SUCCESS;
    }

    public void setRequest(Map<String, Object> map)
    {
        this.request = map;
    }

    public void setApplication(Map<String, Object> map)
    {
        this.application = map;
    }

    public void setSession(Map<String, Object> map)
    {
        this.sesion = map;
    }

    public void setDatoRequest(String datoRequest)
    {
        this.datoRequest = datoRequest;
    }

    public void setDatoSesion(String datoSesion)
    {
        this.datoSesion = datoSesion;
    }

    public void setDatosAplicacion(String datosAplicacion)
    {
        this.datosAplicacion = datosAplicacion;
    }
}

Ahora crearemos la página "resultado.jsp", en la raíz de las páginas web, para comprobar que los datos se han establecido correctamente. En esta página primero indicaremos que haremos uso de la biblioteca de etiquetas de Struts 2, como lo hicimos anteriormente. Además usaremos la etiqueta "<s:property>" para mostrar el valor en cada uno de los scopes. Para obtener el valor usaremos OGNL con el cual, como recordarán del segundo tutorial de la serie, tiene una sintaxis especial para los objetos que se encuentran en los scopes anteriores. Si no recuerdan la sintaxis pueden regresar a ver el tutorial correspondiente... o continuar leyendo este.

Recuerden que Struts 2 coloca en el "ActionContext" algunos objetos extra además del objeto raíz, para acceder a estos objetos necesitamos usar un operador especial, el operador "#", junto con el nombre del objeto al que queremos acceder. En este caso Struts 2 coloca 3 objetos especiales que hacen referencia cada uno a uno a uno de los distintos scopes:

application
session
request

Y como habíamos visto, es posible obtener el valor de los atributos colocados en estos scopes usando el operador punto (".") o colocando el nombre del parámetro entre corchetes ("[" y "]").

En este caso, para mostrar el valor almacenado en el request debemos hacer:


<s:property value="#request.datoRequest" />

Para el resto de los parámetros se hace algo similar. Al final la página queda de la siguiente forma:


Request: <s:property value="#request.datoRequest" /><br />
Sesión: <s:property value="#session.datoSesion" /><br />
Aplicacion: <s:property value="#application.datoAplicacion" /><br />

Cuando ejecutemos la aplicación y entremos a la siguiente dirección:


http://localhost:8080/scopes/datosScopesInterfaces.jsp

Debemos ver el formulario que creamos anteriormente. Si colocamos los siguientes datos:

Y presionamos el botón de enviar, veremos la siguiente salida:

Ahora, ¿cómo podemos comprobar que cada dato está efectivamente en los scopes indicados? Bueno para esto hay varias formas. Primero, para comprobar el atributo del request podemos entrar directamente a la página del resultado:


http://localhost:8080/scopes/resultado.jsp

Con esto estamos creando una nueva petición, por lo que el atributo que teníamos anteriormente debería desaparecer:

Para el dato de la sesión, podemos esperar a que termine nuestra sesión de forma automática (después de 30 minutos), podemos usar otro navegador para entrar a la misma dirección, o simplemente podemos terminar las sesiones activas de nuestro navegador. Con esto los atributos de la sesión deben desaparecer:

Finalmente, y como podemos ver por la imagen anterior del explorer, los atributos del scope aplicación permanecerán hasta que detengamos nuestro servidor (con lo cual, por cierto, ya no podremos entrar al sitio ^_^).

Como podemos ver, esta forma de establecer (y leer) atributos de los distintos scopes es bastante sencilla pero, como dijimos al inicio del tutorial: no es la única forma. Ahora veremos la segunda forma de hacer esto: usado el objeto "ActionContext"

Manejo de Atributos de Scope usando ActionContext

La segunda forma que tenemos de manejar los atributos de los scopes es a través de un objeto especial de Struts 2 llamado "ActionContext". Este objeto es el contexto en al cual el Action se ejecuta. Cada contexto es básicamente un contenedor para objetos que un Action necesita para su ejecución, como la sesión, sus parámetros, etc.

Dentro de los objetos que se encuentran dentro del "ActionContext" están justamente los mapas que contienen los atributos de sesion y aplicación (así es, no se pueden establecer los atributos de request usando este objeto), que son los que nos interesan para esta pare del tutorial.

Obtener una referencia al "ActionContext" es en realidad muy sencillo ya que, aunque este objeto no es un singleton como tal, lo obtenemos como si fuera uno; veremos esto dentro de un momento, primero crearemos una nueva página que contendrá un formulario como el anterior.

Creamos una nueva página llamada "datosScopesActionContext.jsp". Esta página contendrá un formulario parecido al que creamos anteriormente, con la diferencia de que los datos de este serán procesados por un Action distinto:


<s:form action="scopesActionContext">
    <s:textfield name="datoSesion" label="Sesion" />
    <s:textfield name="datosAplicacion" label="Aplicacion" />
    <s:submit />
</s:form>

Ahora crearemos, en el paquete "actions", una nueva clase llamada "ScopesActionContextAction" que extienda de "ActionSupport":


public class ScopesActionContextAction extends ActionSupport
{
}

Esta clase tendrá dos atributos de tipo String, uno para el dato que irá en sesión y otro para el dato que irá en el scope aplicación, con sus correspondientes setters:


public class ScopesActionContextAction extends ActionSupport
{
    private String datoSesion;
    private String datosAplicacion;

    public void setDatoSesion(String datoSesion)
    {
        this.datoSesion = datoSesion;
    }

    public void setDatosAplicacion(String datosAplicacion)
    {
        this.datosAplicacion = datosAplicacion;
    }
}

Lo último que esta clase necesita es sobre-escribir su método "execute" para, haciendo uso del "ActionContext", establecer los valores en los scopes adecuados.

Para obtener una instancia del "ActionContext" se usa el método estático "getContext()" que nos regresa la instancia de "ActionContext" adecuada para el Action que estamos ejecutando:


ActionContext contexto = ActionContext.getContext();

Y una vez teniendo una referencia al "ApplicationContext" lo único que debemos hacer es usar el método "getApplication()" para obtener un mapa con los atributos del scope application y "getSession()" para obtener un mapa con los atributos del scope session:


Map<String, Object> application = contexto.getApplication();
Map<String, Object> sesion = contexto.getSession();

El resto es solo colocar los atributos que recibidos del formulario en los mapas correspondientes:


application.put("datoAplicacion", datosAplicacion);
sesion.put("datoSesion", datoSesion);

El método "execute" queda de la siguiente forma:


@Override
public String execute() throws Exception
{
    ActionContext contexto = ActionContext.getContext();
        
    Map<String, Object> application = contexto.getApplication();
    Map<String, Object> sesion = contexto.getSession();
        
    application.put("datoAplicacion", datosAplicacion);
    sesion.put("datoSesion", datoSesion);

    return SUCCESS;
}

Lo último que falta es anotar nuestro Action para indicar que responderá al nombre de "scopesActionContext" y que regresará a la página "/resultado.jsp" (la cual creamos para el ejemplo anterior así que ahora la reutilizaremos):


@Namespace(value = "/")
@Action(value = "scopesActionContext", results =
{
    @Result(name = "success", location = "/resultado.jsp")
})
public class ScopesActionContextAction extends ActionSupport
{
}

La clase "ScopesActionContextAction" completa queda de la siguiente forma:


@Namespace(value = "/")
@Action(value = "scopesActionContext", results ={@Result(name = "success", location = "/resultado.jsp")})
public class ScopesActionContextAction extends ActionSupport
{
    private String datoSesion;
    private String datosAplicacion;

    @Override
    public String execute() throws Exception
    {
        ActionContext contexto = ActionContext.getContext();
        
        Map<String, Object> application = contexto.getApplication();
        Map<String, Object> sesion = contexto.getSession();
        
        application.put("datoAplicacion", datosAplicacion);
        sesion.put("datoSesion", datoSesion);

        return SUCCESS;
    }

    public void setDatoSesion(String datoSesion)
    {
        this.datoSesion = datoSesion;
    }

    public void setDatosAplicacion(String datosAplicacion)
    {
        this.datosAplicacion = datosAplicacion;
    }
}

Ahora que ya tenemos todo listo ejecutamos la aplicación y al entrar a la siguiente dirección:


http://localhost:8080/scopes/datosScopesActionContext.jsp

Debemos ver el siguiente formulario, muy parecido al anterior:

Cuando ingresemos algunos valores y demos clic en el botón de enviar, veremos un resultado como el siguiente:

El dato del request queda vacio ya que no lo hemos establecido en esta ocasión.

Podemos ver que esta segunda forma de establecer los datos es también muy simple de utilizar y da buenos resultados.

Veremos la tercer y última forma de manejar los atributos de los scopes request, session y application. Debo decir que esta tercer forma no es recomendable ya que rompe con el esquema de trabajo de Struts 2, el cual oculta detalles de la especificación de Servlets, pero eso lo veremos en un momento.

Manejo de Atributos de Scope usando ServletActionContext

Con esta última forma tendremos acceso directo a los objetos "HttpServletRequest" y "ServletContext", de la especificación de Servlets; haciendo uso de otro objeto especial de Struts 2: "ServletActionContext".

Este objeto especial "ServletActionContext" contiene una serie de métodos estáticos que nos dan acceso a otros objetos de utilidad (entre ellos "ActionContext"). Los métodos que en este momento nos interesan son: "getRequest", con el que podemos obtener el objeto "HttpServletRequest" (desde el cual tenemos además acceso a la sesión) asociado con la petición que el Action está sirviendo, y "getServletContext", que nos regresa el objeto "ServletContext" que representa el contexto de la aplicación web.

El uso de estos dos métodos es muy directo y lo veremos en un momento, pero primero crearemos una nueva página JSP que contendrá el formulario, como los anteriores, que nos permitirá introducir los datos que se agregarán como atributos de cada uno de los scopes. Esta página se llamará "datosScopesServletActionContext.jsp" y contendrá un formulario como el primero que creamos con la diferencia de los datos de este formulario serán procesados por otro Action:


<s:form action="scopesServletActionContext">
    <s:textfield name="datoSesion" label="Sesion" />
    <s:textfield name="datoRequest" label="Request" />
    <s:textfield name="datosAplicacion" label="Aplicacion" />
    <s:submit />
</s:form>

Ahora creamos, en el paquete "actions", una nueva clase llamada "ScopesServletActionContextAction" que extienda de "ActionSupport":


public class ScopesServletActionContextAction extends ActionSupport
{
}

Esta clase tendrá tres atributos de tipo String, con sus correspondientes setters, uno para cada valor que recibimos del formulario:


public class ScopesServletActionContextAction extends ActionSupport
{
    private String datoSesion;
    private String datoRequest;
    private String datosAplicacion;

    public void setDatoRequest(String datoRequest)
    {
        this.datoRequest = datoRequest;
    }

    public void setDatoSesion(String datoSesion)
    {
        this.datoSesion = datoSesion;
    }

    public void setDatosAplicacion(String datosAplicacion)
    {
        this.datosAplicacion = datosAplicacion;
    }
}

Ahora sobre-escribiremos el método "execute" para, haciendo uso de los métodos estáticos de la clase "ServletActionContext", obtener referencias al "HttpServletRequest" y al "ServletContext". Como había dicho "ServletActionContext" nos proporciona métodos estáticos que nos regresan estas referencias de forma directa, por lo que lo único que tenemos que hacer es invocarlos:


HttpServletRequest request = ServletActionContext.getRequest();
ServletContext context = ServletActionContext.getServletContext();

La sesión (el objeto "HttpSession") se obtiene usando el método "getSession()" del objeto "request":


HttpSession sesion = request.getSession();

Y ya con estas referencias podemos obtener los atributos de los scopes correspondientes como lo hacemos cuando trabajamos directamente con Servlets: usando el método "setAttribute" de cada uno de los objetos:


request.setAttribute("datoRequest", datoRequest);
sesion.setAttribute("datoSesion", datoSesion);
context.setAttribute("datoAplicacion", datosAplicacion);

Y eso es todo lo que hay que hacer. El método "execute" queda de la siguiente forma:


@Override
public String execute() throws Exception
{
    HttpServletRequest request = ServletActionContext.getRequest();
    ServletContext context = ServletActionContext.getServletContext();
    HttpSession sesion = request.getSession();
        
    request.setAttribute("datoRequest", datoRequest);
    sesion.setAttribute("datoSesion", datoSesion);
    context.setAttribute("datoAplicacion", datosAplicacion);
        
    return SUCCESS;
}

Lo único que resta hacer es colocar las anotaciones para indicar que esta clase será un Action. Al igual que en los casos anteriores, reutilizaremos la página "resultados.jsp". Como ya conocemos estas anotaciones de memoria, solo mostraré como queda finalmente la clase "ScopesServletActionContextAction"


@Namespace(value = "")
@Action(value = "scopesServletActionContext", results ={@Result(name = "success", location = "/resultado.jsp")})
public class ScopesServletActionContextAction extends ActionSupport
{
    private String datoSesion;
    private String datoRequest;
    private String datosAplicacion;

    @Override
    public String execute() throws Exception
    {
        HttpServletRequest request = ServletActionContext.getRequest();
        ServletContext context =   ServletActionContext.getServletContext();
        HttpSession sesion = request.getSession();
        
        request.setAttribute("datoRequest", datoRequest);
        sesion.setAttribute("datoSesion", datoSesion);
        context.setAttribute("datoAplicacion", datosAplicacion);
        
        return SUCCESS;
    }

    
    
    public void setDatoRequest(String datoRequest)
    {
        this.datoRequest = datoRequest;
    }

    public void setDatoSesion(String datoSesion)
    {
        this.datoSesion = datoSesion;
    }

    public void setDatosAplicacion(String datosAplicacion)
    {
        this.datosAplicacion = datosAplicacion;
    }
}

Cuando ejecutemos nuestra aplicación y entremos a la siguiente dirección:


http://localhost:8080/scopes/datosScopesServletActionContext.jsp

Debemos ver el mismo formulario que en el primer ejemplo:

Al rellenar los campos con algunos datos y enviar el formulario debemos ver el siguiente resultado:

Como podemos ver esta tercer forma abarca en realidad los dos temas del tutorial, establecer valores en los scopes de la aplicación web y obtener los objetos "HttpServletRequest" y "ServletContext", así que a continuación veremos la segunda forma de obtener estos objetos:

Obtención de Objetos "HttpServletRequest" y "ServletContext"

Obtención de Objetos de Servlet usando interfaces Aware

En la primer parte del tutorial vimos cómo trabajan las interfaces Aware, y en el ejemplo anterior vimos cómo tener acceso directo a los objetos de la especificación de Servlets. Así que en este último ejemplo veremos una forma de obtener estos objetos, usando las interfaces Aware.

Para no perder la costumbre de este tutorial, lo primero que haremos es crear una nueva JSP llamada "datosServletsInterfaces.jsp" que contendrá el formulario que también ya debemos conocer de memoria ^_^, en donde, nuevamente, lo único que cambiará es el valor del atributo "action":


<s:form action="datosInterfaces">
    <s:textfield name="datoSesion" label="Sesion" />
    <s:textfield name="datoRequest" label="Request" />
    <s:textfield name="datosAplicacion" label="Aplicacion" />
    <s:submit />
</s:form>

Ahora crearemos una nueva clase llamada "ObjetosServletAction", en el paquete "actions". Esta clase deberá extender "ActionSupport":


public class ObjetosServletAction extends ActionSupport
{   
}

Struts 2 permite obtener una referencia al objeto "HttpServletRequest", que representa la petición actual que está siendo atendida por el Action, y al objeto "ServletContext", que representa el contexto de la aplicación web, implementando las interfaces "ServletRequestAware" y "ServletContextAware" respectivamente.

Ambas interfaces son igual de sencillas que sus contrapartes para los atributos de los scopes. La interface "ServletContextAware" luce de la siguiente forma:


interface ServletContextAware
{  
    public void setServletContext(ServletContext sc);
}

Y la interface "ServletRequestAware" se ve así:


interface ServletRequestAware
{
    public void setServletRequest(HttpServletRequest hsr);
}

Como podemos ver, ambas interfaces tienen tan solo un método que debemos implementar, y que reciben el objeto adecuado perteneciente a la especificación de Servlets (en vez de algún objeto propio de Struts 2 o algún objeto genérico, como estamos acostumbrados al trabajar con este framework), por lo que al implementar estos métodos ya tenemos una referencia directa a estos objetos sin tener que hacer ningún otro proceso, conversión, o invocación.

Junto con la implementación de estas interfaces proporcionaremos un par de atributos, uno de tipo "ServletContext" y uno de tipo "HttpServletRequest", para almacenar los valores recibidos con la implementación.

Así que lo primero que hacemos entonces es declarar que nuestra clase "ObjetosServletAction" implementará las interfaces "ServletContextAware" y "ServletRequestAware":


public class ObjetosServletAction extends ActionSupport implements ServletContextAware, ServletRequestAware
{
}

Ahora colocaremos los atributos (sin getters ni setters) para almacenar las referencias recibidas por los métodos de las interfaces anteriores:


private ServletContext application;
private HttpServletRequest request;

Lo siguiente es proporcionar la implementación de las interfaces, en los cuales almacenaremos las referencias recibidas por estas, en los atributos que hemos colocado en nuestra clase:


public void setServletContext(ServletContext sc)
{
    this.application = sc;
}

public void setServletRequest(HttpServletRequest hsr)
{
    this.request = hsr;
}

Ahora que ya tenemos las referencias que nos interesaban agregaremos los tres atributos, junto con sus setters, que nos permitirán recibir los parámetros provenientes del formulario:


private String datoSesion;
private String datoRequest;
private String datosAplicacion;

public void setDatoRequest(String datoRequest)
{
    this.datoRequest = datoRequest;
}

public void setDatoSesion(String datoSesion)
{
    this.datoSesion = datoSesion;
}

public void setDatosAplicacion(String datosAplicacion)
{
    this.datosAplicacion = datosAplicacion;
}

El siguiente paso es sobre-escribir el método "execute" para establecer los valores de los atributos en cada uno de los scopes. Primero obtendremos el objeto "HttpSession" usando el "HttpServletRequest", como en el ejemplo anterior, para posteriormente poder establecer los atributos en los scopes usando los objetos apropiados:


@Override
public String execute() throws Exception
{
    HttpSession sesion = request.getSession();
        
    application.setAttribute("datoAplicacion", datosAplicacion);
    sesion.setAttribute("datoSesion", datoSesion);
    request.setAttribute("datoRequest", datoRequest);
        
    return SUCCESS;
}

Como ven, la lógica del método es tan sencilla como en todo el tutorial.

El último paso es anotar esta clase para indicarle a Struts 2 que se trata de un Action. Una vez más reutilizaremos la página "resultado.jsp" para mostrar los resultados de la ejecución del Action:


@Namespace(value = "")
@Action(value = "datosInterfaces", results ={@Result(name = "success", location = "/resultado.jsp")})
public class ObjetosServletAction extends ActionSupport implements ServletRequestAware, ServletContextAware
{
}

Al final la clase "ObjetosServletAction" queda de la siguiente forma:


@Namespace(value = "")
@Action(value = "datosInterfaces", results ={@Result(name = "success", location = "/resultado.jsp")})
public class ObjetosServletAction extends ActionSupport implements ServletRequestAware, ServletContextAware
{
    private ServletContext application;
    private HttpServletRequest request;
    private String datoSesion;
    private String datoRequest;
    private String datosAplicacion;

    @Override
    public String execute() throws Exception
    {
        HttpSession sesion = request.getSession();
        
        application.setAttribute("datoAplicacion", datosAplicacion);
        sesion.setAttribute("datoSesion", datoSesion);
        request.setAttribute("datoRequest", datoRequest);
        
        return SUCCESS;
    }
    
    public void setServletContext(ServletContext sc)
    {
        this.application = sc;
    }

    public void setServletRequest(HttpServletRequest hsr)
    {
        this.request = hsr;
    }

    public void setDatoRequest(String datoRequest)
    {
        this.datoRequest = datoRequest;
    }

    public void setDatoSesion(String datoSesion)
    {
        this.datoSesion = datoSesion;
    }

    public void setDatosAplicacion(String datosAplicacion)
    {
        this.datosAplicacion = datosAplicacion;
    }
}

Cuando ejecutemos la aplicación y entremos a la siguiente dirección:


http://localhost:8080/scopes/datosServletsInterfaces.jsp

Debemos ver el formulario al que ahora ya debemos estar acostumbrados ^_^!:

Y, nuevamente, al ingresar algunos datos y presionar el botón enviar debemos ver la siguiente salida:

Como podemos ver, una vez más todo ha funcionado correctamente.

Algunos se preguntarán ¿para qué queremos tener acceso a estos objetos si Struts 2 se encarga de manejar todos los aspectos relacionados con Servlets por nosotros? Bueno me alegra que hagan esa pregunta ^_^.

En realidad esto tiene varios usos, los dos más utilizados que se me ocurren en este momento es el poder obtener la ubicación absoluta de un recurso (un archivo o algún otro elemento) que se encuentra en nuestra aplicación y que por lo tanto no sabemos en qué directorio del disco duro está. Para esto se necesita el método "getRealPath" del objeto "ServletContext" de la siguiente forma:


application.getRealPath("/recurso.ext");

El segundo y más común uso es para invalidar una sesión. Struts 2 no nos da directamente una manera para invalidar la sesión de un usuario de nuestra aplicación web, así que para esto es necesario tener objeto al objeto "HttpSession", y para esto al objeto "HttpServletRequest":


request.getSession().invalidate();

Así que, como podemos ver, algunas veces es útil tener acceso a los objetos de la específicación de Servlets cuando el framework que estamos usando no nos pueda, por la razón que sea, darnos todas las facilidades que necesitemos para hacer algunas cosas específicas.

Esto es todo para este tutorial, espero que les sea de utilidad. En el siguiente tutorial de la serie de Struts 2, veremos los tipos de results que vienen incluidos con Struts 2 y para que pueden servirnos.

No olviden dejar cualquier duda, comentario, o sugerencia que puedan tener.

Saludos.

Descarga los archivos de este tutorial desde aquí:

ScopesDeObjetosWeb

Entradas Relacionadas:

Sun Certified Java Programmer 6, CX-310-065 - Parte 2: Orientación a Objetos

2011-11-05T20:29:00.000-07:00

En este segundo post para la certificación de Java 6 hablaremos sobre conceptos de la orientación a objetos, que abarca temas como la herencia, el polimorfismo, la cohesión, bajo acoplamiento (loose coupling), etc.

Empezaremos hablando sobre la encapsulación:

Encapsulación

La encapsulación es un mecanismo que nos permite que, aunque nuestras clases utilicen muchas variables y métodos para su correcto funcionamiento, no todas sean visibles desde el exterior. O sea que solo exponemos lo que los clientes necesitan para poder hacer uso de los objetos de nuestra clase.

Para entender mejor este concepto imaginemos el siguiente escenario:

Tenemos la siguiente clase:


public class Examen
{
    public String pregunta1;

    public static void main(String... args)
    {
        Examen examen = new Examen();
        examen.pregunta1 = "¿Que es Java?"; // Legal pero no recomendable
    }
}

El ejemplo anterior compilará y se ejecutará de forma correcta. Sin embargo no es recomendable que los atributos de la clase (las variables de instancia) estén expuestas de forma que los clientes puedan leer y escribir sus valores directamente. De esta forma cualquiera podría colocar el valor que quisiera en la variable "pregunta1", aún valores que nuestra aplicación no puede o no está preparada para manejar.

Ahora hagamos una pregunta: ¿Cómo poder cambiar la clase cuando alguien cambia el valor de "pregunta1" por un valor incorrecto? La única forma es volver a la clase e implementar un método de sólo escritura (un método setter: "setPregunta1(String pregunta1)") y ocultar la variable "pregunta1" estableciéndola como privada, pero de esta manera al no establecerla desde un principio con los métodos "set" o "get" todas las personas que han utilizado este código anteriormente y de la manera en la que estaba implementada se encontraran perdidas.

La capacidad de realizar cambios en el código de aplicación sin romper el código de otras personas que utilizan este código es un beneficio clave de la encapsulación. Ocultando los detalles de la implementación a través de métodos de acceso nos brinda la ventaja de poder rehacer el código dentro de los métodos sin forzar a las demás personas a cambios, ya que ellas usan dichos métodos de acceso.

Con todo esto obtenemos las dos promesas/beneficios de la programación orientada a objetos: Flexibilidad y Mantenimiento, pero como vemos estos dos beneficios no llegan solos, nosotros tenemos que implementar nuestro código de manera que brinde y soporte estos beneficios.

Estas son algunas recomendaciones para lograr la encapsulación:

Mantener las variables de instancia protegidas (mayormente con el modificador de acceso private).
Mantener publicos los métodos de acceso a las variables de instancia (modificador de acceso public), así forzamos a llamar a las variables de instancia y a la implementación del mismo a través de estos métodos en lugar de ir directamente por las variables de instancia.
Para los métodos de acceso se recomienda usar las reglas de las convenciones de nombres de JavaBean: set<nombrePropiedad> y get<nombrePropiedad>, de las cuales se habló en el post anterior.

A continuación mostramos un ejemplo más práctico de lo que nos estamos refiriendo:

La clase "A" no puede acceder a las variables de instancia de la Clase "B" sin antes ir a los métodos de acceso ("set" y "get") de dichas variables, las variables de instancia son marcadas privadas y los métodos de acceso son públicos.

Debemos tener presente que el código de estos métodos no solo se utiliza para devolver o establecer los valores de las variables de instancia, también se puede establecer lógica o implementación de muchas más cosas o reglas que queramos definir, por ejemplo:


public void setTamanio(int tamanio)
{
    this.tamanio = tamanio * 0.10;
    this.color = "negro";
}

El encapsulamiento es uno de los mecanismos que nos proporciona la orientación a objetos para poder darle una funcionalidad rica a nuestras clases sin que las personas que las utilicen sepan los detalles exactos de cómo está implementada dicha funcionalidad.

Sin embargo, este no es el único mecanismo proporcionado por la orientación a objetos. A continuación veremos otro de ellos. La herencia.

Herencia, ES–UN, TIENE–UN (IS–A, HAS-A)

En Java, la herencia se encuentra en todos. Es seguro decir que en Java casi nada se puede hacer sin hacer uso de la herencia. Para dar un ejemplo a continuación usaremos del operador "instanceof" (por ahora no ahondaremos mucho en la explicación del uso de este operador ya que se tocará más adelante con mayor detalle, sólo cabe recordar ahora que este operador devuelve un "true" si la variable puesta al principio es del tipo de la variable con la que se está comparando):


public class Test
{
    public static void main(String... args)
    {
        Test t1 = new Test();
        Test t2 = new Test();
        
        if(!t1.equals(t2))
        {
            System.out.println("No son iguales")
        }
        if(t1 instanceof  Object)
        {
            System.out.println("t1 es un objeto");
        }
    }
}

¿De dónde saca "t1" el método "equals"? Si no hemos implementado ningún método dentro de la clase con ese nombre, ¿o sí? Por otro lado se pregunta si "t1" es una instancia de la clase "Object" y de ser así, la condición if será exitosa.

¿Cómo puede ser "t1" del tipo "Object" si solo lo declaramos que sea del tipo de la clase "Test"? Esto ocurre porque todas las clases en java (las que ya están escritas, las que escribimos y las que escribiremos) son una subclase de la clase "Object" (excepto por supuesto la clase "Object" misma) y siempre tendrán métodos como "equals", "clone", "notify", "wait" y otros más. Siempre que creamos una clase, esta hereda todos los métodos de la clase "Object".

El método "equals" por ejemplo: Los creadores de Java asumieron correctamente que nosotros comúnmente desearíamos comparar instancias de las clases para comprobar la igualdad; si la clase "Object" no tuviera un método "equals" tendríamos que implementar nosotros mismos un método para este propósito.

También debemos recordar que las 2 razones más importantes para el uso de la herencia son:

Reutilización de código
Uso del polimorfismo

Empecemos con la reutilización. Un enfoque de diseño común es crear una versión de una clase bastante genérica y después crear subclases muy especializadas que hereden de esta, por ejemplo:


public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoy moviendo");
    }
}


public class Perro extends Animal
{
    public void ladra()
    {
        System.out.println("Estoy ladrando");
    }
}

public class PruebaAnimal
{
    public static void main(String... args)
    {
        Perro perro = new Perro();
        perro.muevete();
        perro.ladra();
    }
}

La salida del código anterior seria:


Me estoy moviendo
Estoy ladrando

Como podemos ver, la clase "Perro" está heredando el método "muevete" de la clase "Animal" y que también tiene su propio método agregado, en este caso es el método "ladra". Aquí se está haciendo uso de la reusabilidad al utilizar un método genérico de una clase padre que en este caso es el método "muevete", con esto podemos crear diferentes tipos de animales y todos van a poder utilizar el método "muevete" sin necesidad de implementarlo ellos mismos.

El segundo objetivo de la herencia es poder acceder a las clases polimórficamente. Imaginemos este escenario: digamos que tenemos una clase llamada "Entrenador" que quiere recorrer todos los diferentes tipos de animal e invocar al método "muévete" en cada uno de ellos, al momento de escribir la clase "Entrenador" no sabemos cuántas clases de "Animal" podría haber y seguro no vamos a querer cambiar el código sólo porque a alguien se le ocurrió crear un nuevo tipo de Animal.

Lo bonito del polimorfismo es que podemos tratar cualquier tipo de "Animal" como un "Animal", en otras palabras podemos decir lo siguiente: No me importa qué tipo de Animal se pueda crear, siempre y cuando extienda (herede) de Animal todos van a poder moverse (método "muevete").

Ahora miremos esto con un ejemplo:


public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoy moviendo");
    }
}

public class Perro extends Animal
{
    public void ladra()
    {
        System.out.println("Estoy ladrando");
    }
}

public class Gato extends Animal
{
    public void ronronea()
    {
        System.out.println("Estoy ronroneando");
    }
}

Ahora imaginemos una clase llamada "Entrenador" que tiene un método que tiene como argumento un "Animal", esto significa que puede tomar cualquier tipo de "Animal", cualquier tipo de animal puede ser pasado a un método con un argumento del tipo "Animal", ejemplo:


public class Entrenador
{
    public static void main(String... args)
    {
        Gato gato = new Gato();
        Perro perro = new Perro();
        mueveteAnimal(gato);
        mueveteAnimal(perro);
    }

    public static void mueveteAnimal(Animal animal)
    {
        animal.muevete();
    } 
}

La salida del código anterior es:


Me estoy moviendo
Me estoy moviendo

El método "mueveteAnimal" está declarando un "Animal" como argumento pero se le puede pasar cualquier sub-clase o sub-tipo de esta clase "Animal", este método podría invocar a cualquier método dentro de la clase "Animal". Lo que si debemos de tener en cuenta es que sólo podemos llamar a los métodos declarados por "Animal", los métodos declarados dentro de las subclases de "Animal" son dependiente del tipo declarado, esto significa que no podríamos llamar al método "ladra" incluso si el "Animal" que se está pasando es del tipo "Perro".

Relaciones IS – A, HAS– A

IS – A

En Orientación a objetos el concepto de "IS-A" (es-un) esta basado en la herencia de una clase ("extends") o en la implementación de una interface ("implements"). IS-A es una forma de decir "Esta cosa es del tipo de esta cosa" (o estos dos tipos pueden ser equivalentes), por ejemplo un "Perro" es del tipo "Animal", en OO nosotros podemos decir: "Perro IS-A Animal", "Lechuga IS-A Vegetal", en java podemos expresar esta relación IS-A por medio de las palabras reservadas "extends" (para la herencia de clases) y de "implements" (para la implementación de interfaces), veamos un ejemplo:


public class Carro
{
    //cualquier código aquí
}

public class Toyota extends Carro
{
    /*Toyota está heredando de carro, no olvidemos que Toyota 
    hereda los miembros de Carro incluido métodos y variables*/
}

"Carro" también es un vehículo así que se podría implementar un árbol de herencia de la siguiente manera:


public class Vehiculo{...}
public class Carro extends Vehiculo{...}
public class Toyota extends Carro{...}

En términos de OO podríamos decir lo siguiente:

Vehículo es la súper clase de Carro
Carro es la subclase de Vehículo
Carro es la súper clase de Toyota
Toyota es la subclase de Carro
Toyota hereda de Carro y de Vehiculo
Toyota deriva de Carro
Carro deriva de Vehículo
Toyota es subtipo de Carro y Vehiculo

Retornando a la relación IS-A, lo siguiente es correcto:

Toyota extends Carro significa Toyota IS-A Carro

Carro extends Vehiculo significa Carro IS-A Vehiculo

Ahora recordemos que al principio usamos el operador instanceof, bueno, si la expresión "Toyota instanceof Carro" es verdadera, entonces es lo mismo que decir "Toyota IS-A Carro", la expresión "Toyota instanceof Vehiculo" también es verdadera aunque explícitamente no dice esto ya que "Toyota" extiende de "Carro", pero por otro lado "Carro" si extiende de "Vehiculo" a esto se le llama herencia indirecta ya que una clase puede ser hijo, nieto, bisnieto, etc. de otra clase, una clase puede extender o heredar de otra directa o indirectamente ya que en el árbol de herencia pueden haber clases intermedias.

HAS–A

La relación HAS-A esta basada en el uso en lugar de la herencia, por ejemplo "A HAS-A B" si la clase "A" tiene una referencia a una instancia de la clase "B", por ejemplo:


public class Animal{ }

public class Gato extends Animal
{
    CajaDeArena miCajaDeArena;
}

En el código anterior la clase "Gato" tiene una referencia una variable de instancia del tipo "CajaDeArena", entonces podemos decir "Gato HAS-A CajaDeArena", en otra palabras, "Gato" tiene una referencia a una "CajaDeArena", la clase "Gato" puede tener un método llamado "llenarCaja(Arena miArena)", de esta manera los usuarios de la clase "Gato" no podrán saber nunca que cuando se invoca al método "llenarCaja" este método delega toda la responsabilidad a la clase "CajaDeArena" llamando a su método "llenarCaja", veamos esto con un ejemplo:


public class Gato extends Animal
{
    private CajaDeArena miCajaDeArena;
    
    public void llenarCaja(Arena miArena)
    {
        miCajaDeArena.llenarCaja(miArena); /*delegando comportamiento al objeto CajaDeArena */
    }
}

public class CajaDeArena
{
    public void llenarCaja(Arena miArena)
    {
        System.out.println("Llenando la caja de arena");
    }
}

En OO muchas veces no queremos que la gente se preocupe por cual clase u objeto está haciendo realmente el trabajo, los usuarios de la clase "Gato" hacen llamado del método "llenarCaja" pero estos no saben si la misma clase hace el trabajo o no, sin embargo a ellos les parece que la propia clase "Gato" lo hace, no tienen ni idea de que existe algo como una clase llamada "CajaDeArena" que es quien realmente hace el trabajo.

Toda la explicación anterior nos servirá para entender mejor otro de los conceptos de la programación orientada a objetos, uno de los más útiles si sabemos cómo utilizarlo correctamente: el polimorfismo.

Polimorfismo

Cualquier clase que pase la prueba de tener la relación "IS-A" puede ser considerada polimórfica, todos los objetos en Java son polimórficos ya que pasan la prueba de la relación IS-A, tanto para su propio tipo como para con la clase "Object". Debemos recordar la única forma de a un objeto es a través de una variable de referencia, hay algunas cosas claves que debemos recordar de las variables de referencia:

Una variable de referencia puede ser sólo de un tipo y una vez declarado este tipo nunca podrá cambiar (aunque el objeto al que hace referencia puede cambiar).
Una referencia es una variable, por lo cual su valor puede ser reasignada a otros objetos a menos que esta sea declarada como final.
Un tipo de variable de referencia determina los métodos que se pueden invocar en el objeto que esta variable está referenciando.
Una variable de referencia puede referirse a cualquier objeto del mismo tipo que el que está declarando, o puede referirse a cualquier subtipo del tipo declarado.
Una variable de referencia puede ser declarado como un tipo de clase o un tipo de interfaz. Si la variable se declara como un tipo de interfaz, se puede hacer referencia a cualquier objeto de cualquier clase que implementa la interfaz.

Anteriormente creamos una clase "Animal" que era extendida por dos clases, "Perro" y "Gato", ahora imaginemos que tenemos una clase llamada "Gaviota", después queremos hacer que algunos tipos de Animal vuelen o se puedan elevar en el aire y otros no como el caso de "Gaviota" que si puede elevar, por el contrario "Perro" y "Gato" no pueden hacerlo, para esto podríamos crear una clase llamada "Elevable" con un método "elevar" y hacer que unos tipos de Animales puedan elevarse y otros no, pero también queremos que todos los tipos de Animal se muevan que es lo que nos permite el método "muevete" de la clase "Animal", pero esto no funcionaría ya que Java solo soporta la herencia simple, esto significa que una sub clase sólo puede tener una clase padre, es decir lo siguiente es incorrecto:


public class Gaviota extends Animal, Elevable // NO!!
{ 
 //Cualquier codigo aquí
}

Una clase NO puede extender de más que de sólo una clase, ante estos casos la solución sería crearse una interface llamada "Elevable" y solo las sub-clases de "Animal" que puedan volar implementen esta interfaz, dicha interfaz quedaría de la siguiente manera:


public interface Elevable
{
    public void volar();
}

public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoymoviendo");
    }
}

A continuación mostramos la clase "Gaviota" que implementa esta interfaz:


public class Gaviota extends Animal implements Elevable
{
    public void volar()
    {
        System.out.println("¡Estoy volando!");
    }
}

Ahora tenemos a la clase "Gaviota" que pasa la prueba de la relación IS-A tanto para la clase "Animal" como para la interfaz "Elevable", esto significa que una "Gaviota" puede ser tratada polimórficamente como una de estas cuatro cosas en un momento dado, dependiendo del tipo declarado de la variable de referencia:

Como un "Object" (ya que todas las clases heredan de la clase Object).
Como un "Animal" (ya que está extendiendo de la clase Animal).
Como una "Gaviota" (ya que es lo que es).
Como un "Elevable" (ya que implementa de la interface Elevable).

Las siguientes declaraciones son legales:


Gaviota gaviota = new Gaviota();
Object object = gaviota;
Animal animal = gaviota;
Elevable elevable = gaviota;

Aquí solo hay un objeto Gaviota pero cuatro diferentes variables de referencia, hagamos una pregunta: ¿Cuál de las cuatro variables de referencia puede llamar al método "muevete"? Recuerden que las llamadas a métodos permitidos por el compilador se basan únicamente en el tipo declarado de la referencia, con independencia del tipo de objeto. Así que buscando en los cuatro tipos de referencia de nuevo, "Object", "Gaviota", "Animal" y "Elevable" ¿cuál de estos cuatro tipos puede llamar al método "muevete()"? La respuesta es la siguiente: El objeto "animal" como el objeto "gaviota" son conocidos por el compilador para poder llamar o invocar al método "muevete".

¿Qué métodos pueden ser invocados cuando el objeto "gaviota" está utilizando la referencia a la inteface "Elevable"? Sólo al método "volar()".

Un beneficio es que cualquier clase desde cualquier lugar en el árbol de herencia puede invocar a la interface "Elevable", que sucedería si tenemos un método que tiene como argumento declarado con tipo "Elevable", podrías pasar una instancia de objeto del tipo "gaviota" y cualquier otra instancia de clase que implemente a la interface "Elevable", podría usar el parámetro del tipo "Elevable" para invocar al método "volar()" pero no al método "muevete()" o cualquier otro objeto que se sabe que el compilador conocer basado en el tipo de referencia.

Otra cosa que debemos saber es que si bien el compilador solo conoce al tipo de referencia declarado, la JVM en tiempo de ejecución sabe lo que el objeto realmente es, y eso significa que incluso si el objeto "gaviota" hace una llamada al método "muevete" usando la variable de referencia "animal", si el objeto "gaviota" sobre-escribe el método "muevete", la JVM invocara a esa versión del método "muevete". La JVM mira al objeto real que se encuentra al otro extremo de la referencia, puede ver que se ha sobre escrito el método del tipo de variable de referencia declarado e invoca al método del objeto de la clase actual.

Siempre se puede hacer referencia a un objeto con un tipo de referencia variable más general (una superclase o interfaz), pero en tiempo de ejecución, las únicas cosas que son seleccionadas dinámicamente basándose en el objeto real (en lugar de tipo de referencia) son métodos de instancia (no los métodos estáticos, no las variables), sólo los métodos de instancia sobre-escritos se invocan de forma dinámica en función del tipo de objeto real.

Ejemplo:


public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoy moviendo");
    }

    public static void respirar() //Método estático
    { 
        System.out.println("Estoy respirando");
    }
}

public class Gaviota extends Animal 
{
    public void muevete()
    {
        System.out.println("La gaviota se mueve");
    }

    public static void respirar() //Método estático
    {
        System.out.println("La gaviota está respirando");
    }
}

public class Prueba
{
    public static void main(String... args)
    {
        Animal a = new Gaviota();
        a.muevete();
        a.respirar();
    }
}

Salida:


La gaviota se mueve 
Estoy respirando

El segundo resultado que vemos se trata de la invocación de un método estático. El comportamiento que vemos pasa porque cuando el compilador ve que se está invocando un método estático, cambia la referencia al objeto por el tipo de la clase, o sea que al final queda de la siguiente manera:


Animal a = new Gaviota();
Animal.respirar();

En el primer caso el método que se invoca es el de "Gaviota" y no el de "Animal", ya que el método "muevete" no es estático sino un método de instancia; por eso dice se dice que sólo los métodos de instancia sobrecargados se invocan de forma dinámica en función del tipo de objeto real.

Sobrecarga y sobre escritura

Sobre escritura de métodos

En cualquier momento que se tenga un método que hereda de una superclase, se tendrá la oportunidad de realizar una sobre-escritura de métodos, a menos que el método este marcado con la palabra reservada final. El principal beneficio de la sobre-escritura de métodos es que se puede definir un comportamiento especial para un método de una subclase. En el siguiente ejemplo veremos cómo la clase "Gaviota" sobre-escribe el método "muevete" de la clase "Animal":


public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoy moviendo");
    }
}

public class Gaviota extends Animal 
{
    public void muevete()
    {
        System.out.println("La gaviota se mueve");
    }
}

Para métodos abstractos que se heredan desde una superclase, no se tiene otra opción más que sobre escribir-dichos métodos. Se deben implementar los métodos a menos que la subclase que los herede también este marcada como abstracta. Los métodos abstractos deben ser implementados por una subclase concreta, esto quiere decir que la subclase concreta sobre-escribe el método abstracto de la superclase. Entonces debemos pensar que los métodos abstractos son métodos que forzosamente deben ser sobre-escritos.

El creador de la clase "Animal" podría haber decidido que, a efectos de polimorfismo, todos los subtipos de Animal deben implementar el método "moverse", de una manera única y especifica. Polimórficamente, cuando alguien tiene una referencia de Animal que no refiere a una instancia de Animal, sino a una instancia de una subclase de Animal, la persona que llama debe ser capaz de invocar al método "muevete" en la referencia a "Animal", pero el objeto en tiempo de ejecución real ejecutará su propio y especifico método "muevete". Marcando el método "muevete" como abstracto es la forma que el programador de la clase "Animal" dice a todos los desarrolladores de las demás subclases: "No tiene ningún sentido para el nuevo subtipo utilizar el método genérico "muevete", por lo que tú debes implementar tu propio método "muevete". A continuación mostraremos un ejemplo de clases no abstractas:


public class Prueba
{
    public static void main(String... args)
    {
        Animal a = new Animal();
       Animal b = new Gaviota(); //Referencia a Animal, pero objeto Gaviota
        a.muevete();
        b.muevete();
    }
}

public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoy moviendo");
    }
}


public class Gaviota extends Animal 
{
    public void muevete()
    {
        System.out.println("La gaviota se mueve");
    }

    public void volar()
    {
        System.out.println("La gaviota vuela");
    }
}

En el código anterior la clase "Prueba" utiliza una referencia a "Animal" para invocar un método en el objeto "Gaviota", hay que recordar que el compilador solo permitirá que se invoquen métodos que se encuentran en la clase "Animal", cuando usas una referencia a un "Animal". Por lo tanto, el siguiente código no es legal:


Animal c = new Gaviota();
c.volar();  // No puedes invocar a "volar()", Animal no tiene un método volar

Para reiterar: el compilar solo mira el tipo de referencia y no el tipo de instancia en tiempo de ejecución. El polimorfismo nos permite tener referencias a súper tipos o a tipos más abstractos (incluyendo las interfaces) para referir a uno de estos subtipos (incluyendo implementación de interfaces).

El método que sobre-escribe no debe tener un modificador de acceso más restringido que el del método a ser sobre-escrito. Por ejemplo no se puede sobre-escribir un método marcado con el modificador de acceso public y cambiarlo a protected. Pensemos en los siguiente: si la clase "Animal" tiene un método "comer()" marcado "public" y alguien tiene una referencia de "Animal", es decir, una referencia declarada del tipo "Animal", se asume que es seguro llamar al método "comer()" en la referencia de "Animal", independientemente de la instancia actual que la referencia a "Animal" está invocando. Si una subclase cambia el modificador de acceso del método sobre-escrito, entonces cuando la JVM invoque la verdadera versión del objeto "Gaviota" en lugar de la versión del tipo de referencia "Animal", el programa perecerá, a continuación un ejemplo:


public class Prueba
{
    public static void main(String... args)
    {
        Animal a = new Animal();
        Animal b = new Gaviota(); // Referencia a Animal, pero objeto Gaviota
        a.muevete();
        b.muevete();
    }
}

public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoy moviendo");
    }
}

public class Gaviota extends Animal 
{
    private  void muevete() //Marcado como privado
    {   
        System.out.println("La gaviota se mueve");
    }
}

Si el código anterior compilara (cosa que no hará) obtendríamos el siguiente error en tiempo de ejecución:


Animal b = new Gaviota(); //Referencia a Animal, pero objeto Gaviota
a.muevete(); //Ocurre una crisis en tiempo de ejecución

La variable "b" es del tipo "Animal", el cual tiene un método público llamado "muevete", pero hay que recordar que en tiempo de ejecución, Java utiliza la invocación de métodos virtuales para seleccionar dinámicamente la versión real del método que se ejecutará, basado en la del tipo del objeto en tiempo de ejecución. Una referencia de "Animal" puede referir siempre a una instancia de "Gaviota" porque "Gaviota" IS-A "Animal" ("Gaviota" ES UN "Animal"). Lo que hace posible que una instancia de una superclase referencie a una instancia de la subclase es que la subclase es capaz de hacer todo lo que la superclase puede hacer (ya que recibe el comportamiento de esta por herencia). Esto quiere decir que cualquiera con una referencia a "Gaviota" usando una instancia de Animal (Animal a = new Gaviota();) es libre de llamar a todos los métodos accesibles de "Animal", no importa si "Gaviota" sobre-escribe los métodos de "Animal" o simplemente los hereda. Un método-sobre escrito debe cumplir con el contrato de la superclase.

Las reglas para sobre escribir un método son las siguientes:

La lista de argumentos debe ser exactamente igual (del mismo tipo y en el mismo orden) que el método a sobre-escribir. Si esta lista no coincide en realidad lo que se está haciendo es una sobrecarga del método (que puede que no sea nuestra intención).
El tipo de retorno del método sobre escrito debe ser el mismo o un subtipo del declarado en el método de la súper clase.
El modificador de acceso no debe ser más restrictivo que del método a sobre-escribir. Por ejemplo, si en la clase base tenemos un método "public" NO podemos sobre-escribirlo poniéndole un modificador "protected".
El modificador de acceso puede ser menos restrictivo que el del método a sobre-escribir. Por ejemplo, si en la clase base tenemos un método "protected" SI podemos sobre-escribirlo poniéndole un modificador "public".
Los métodos de instancia solo pueden ser sobre-escritos si estos son heredados por la subclase. Una subclase dentro del mismo paquete que su superclase puede sobre escribir cualquier método de la súper clase que NO esté marcado como private o final. Una subclase en diferente paquete puede sobre-escribir solo los métodos no finales marcados public o protected (los métodos protected son heredados por la subclase).
Los métodos sobre-escritos no deben lanzar excepciones marcadas (en las que sean necesarias un try catch) que sean nuevas o más amplias que aquellas declaradas en el método que sobre-escribe. Por ejemplo un método que declara un "FileNotFoundException" no puede ser sobre-escrito por un método que declara un "SQLException", "Exception", "IOException" o cualquier otra excepción a menos que esta sea una subclase de "FileNotFoundException".
Los métodos sobre-escritos pueden lanzar excepciones más específicas (excepciones que extiendan de la excepción que se está declarando) o lanzar menos excepciones. Solo porque el método a sobre-escribir puede lanzar excepciones no quiere decir que el método sobre-escrito lanzara estas mismas excepciones, un método sobre-escrito no tiene que declarar una excepción que nunca lanzará. Independientemente de que el método a sobre-escribir las declare.
No se puede sobre-escribir un método marcado con final.
No se puede sobre-escribir un método marcado con static.
Si un método no puede ser heredado entonces no puede ser sobre-escrito. Hay que recordar que la sobre-escritura implica que se está re-implementando un método que está heredanddo. Por ejemplo el siguiente código no es legal:


public class Prueba
{
    public static void main(String... args)
    {
        Gaviota a = new Gaviota(); 
        a.muevete(); //No es legal porque Gaviota no hereda muevete(), muevete() es declarado private en Animal
    }    
}

public class Animal
{
    private void muevete()
    {
        System.out.println("Me estoy moviendo");
    }
}

public class Gaviota extends Animal {}

Invocando a la versión de la superclase de un método sobre escrito

Tal vez queramos tomar ventaja de una parte del código en la versión de la súper clase de un método y aun así sobre-escribirlo para proveer algún comportamiento especifico adicional. Esto es como decir: "Ejecuta la versión de la superclase de un método, después vuelve y termina con mi código para hacer un comportamiento adicional en el método de la subclase", esto es fácil de hacer utilizando la palabra reservada super como en el ejemplo siguiente:


public class Prueba
{
    public static void main(String... args)
    {
        Gaviota a = new Gaviota(); 
        a.muevete();  
    }
}

public class Animal
{
    public void muevete()
    {
        System.out.println("Me estoy moviendo");
    }
}

public class Gaviota extends Animal 
{
    public  void muevete()
    {  
        //podemos agregar alguna cosa mas
        super.muevete(); //invoca al código de la superclase (Animal)
    }
}

Usar la palabra reservada "super" para invocar a un método sobre-escrito sólo se aplica para métodos de instancia, hay que recordar que los métodos marcados con static no pueden ser sobre escritos.

Sobrecarga de métodos

La sobrecarga de métodos permite usar el mismo nombre de un método en una clase, pero con diferentes argumentos y, opcionalmente, un tipo de retorno diferente, el código asume la carga de hacer frente a diferentes tipos de argumentos en lugar de obligar a la persona que llama a hacer las conversiones antes de invocar el método. Las reglas a seguir para la sobrecarga son simples:

Para sobrecargar métodos se debe cambiar la lista de argumentos.
Para sobrecargar métodos se puede cambiar el tipo de datos de retorno.
Para sobrecargar métodos se puede cambiar el modificador de acceso.
Para sobrecargar métodos se pueden declarar excepciones que sean nuevas o más amplias.
El método puede ser sobrecargado en la misma clase o en una subclase.
Si la clase "A" define un método "hacerAlgo(int i)", la subclase "B" puede definir un método llamado "hacerAlgo(String s)", sin sobre-escribir el método "hacerAlgo(int i)" de la súper clase que toma como argumento un entero. Dos métodos con el mismo nombre pero en diferentes clases pueden ser consideradas sobrecargados, si la sub-clase hereda una versión del método y luego declara otra versión sobrecargada en la definición de la clase.

Formas legales de sobrecargar un método

El método que queremos sobrecargar es el siguiente:


public void unMetodo(String str, int t, double d){}

Los siguientes métodos son legales para sobrecargar el método anterior:


public void unMetodo(String str, int t){}

public int unMetodo(String str, double d){}

public void unMetodo(String str, int t)throws IOException{}

Invocando a métodos sobrecargados

Cuando un método es invocado, más de un método con el mismo nombre puede existir para el tipo de objeto que estamos invocando. Por ejemplo la clase "Gaviota" puede tener tres métodos con el mismo nombre pero con diferente lista de argumentos, estos serán métodos sobrecargados. Definir cuál de los diferentes métodos se desea invocar dependerá de la lista de argumentos que contenga. Si estamos invocando a un método que tiene un "String" como argumento, el método que tiene un "String" como argumento será llamado. A continuación veremos un ejemplo:


public class UnaClase
{
    public int unMetodo(int x, int y)
    {
        return x + y;
    }

    public double unMetodo(double x, double y)
    {
        return x + y;
    }
}

public class Prueba
{
    public static void main(String... args)
    {
        UnaClase a = new UnaClase();
        int x = 9;
        int y = 5;
        
        int resultado = a.unMetodo(x, y); //¿Qué versión de "unMetodo" es invocado?

        double otroResultado = a.unMetodo(5.2, 3.6); //¿Qué versión es invocada?
    }
}

En el primer caso se llama a la primera versión del método "unMetodo(x,y)" ya que se está pasando a dos enteros y en el segundo caso se llama a la versión del método "unMetodo" que recibe dos argumentos del tipo double.

La invocación de métodos sobrecargados que reciben objetos en lugar de tipos primitivos es un poco más interesante. Si tenemos un método sobrecargado, que en un método toma un objeto del tipo "Animal" y otro en el que toma un objeto del tipo "Gaviota" (subclase de "Animal"). Si pasamos un objeto del tipo Gaviota cuando invocamos al método, invocaremos a la versión sobrecargada que toma una "Gaviota". O al menos eso parece a primera vista:


class  Animal{}

class Gaviota extends Animal{}

public class UsaAnimales
{
    public void muevete(Animal a)
    {
        System.out.println("Estas en la versión de Animal");
    }

    public void muevete(Gaviota g)
    {
        System.out.println("Estas en la versión de Gaviota");
    }
 
    public static void main(String... args)
    {
        UsaAnimales ua = new UsaAnimales();
        Animal a = new Animal();
        Gaviora g = new Gaviota():
        ua.muevete(a);
        ua.muevete(g);
    }
}

La salida es la que esperamos:


Estas en la versión de Animal
Estas en la versión de Gaviota

¿Pero qué sucede si usamos una referencia de "Animal" para un objeto "Gaviota"?


Animal animalReferenciaGaviota = new Gaviota();
ua.muevete(animalReferenciaGaviota);

¿Cuál de las versiones del método "muévete" es invocada?, podríamos pensar que la respuesta es: "El que toma una "Gaviota", ya que es un objeto del tipo "Gaviota" el que en tiempo de ejecución está siendo pasado al método". Pero no es así como funciona. El código anterior imprime lo siguiente:


Estas en la versión de Animal

El objeto en tiempo de ejecución es una "Gaviota" y no un "Animal". La elección de cuál método sobrecargado se deberá llamar no es decidido dinámicamente en tiempo de ejecución. Sólo hay que recordar que el tipo de referencia, no el tipo de objeto, determina qué método sobrecargado es llamado.

Para resumir lo que hemos visto hasta ahora de sobrecarga y sobre-escritura: cuál versión de un método sobre-escrito es llamado (en otras palabas, desde cuál clase en el árbol de herencia) es decidido en tiempo de ejecución por el tipo de objeto; pero cuál versión del método sobrecargado se llamará está basado en el tipo de referencia del argumento que se pasa en tiempo de compilación. Si invocamos un método pasando una referencia de "Animal" para un objeto "Gaviota", el compilador solo sabe que está recibiendo un "Animal", por lo que elige la versión sobrecargada que toma un "Animal". No importa que en tiempo de ejecución realmente se pase una "Gaviota".

Polimorfismo en métodos sobrecargados y sobre-escritos

¿Cómo trabaja el polimorfismo en métodos sobrecargados? Si pasamos una referencia de "Animal", el método que toma un "Animal" será llamado, incluso si el objeto actual pasado es una "Gaviota". Una vez que la "Gaviota" disfrazada de "Animal" entra en el método, sin embargo, el objeto "Gaviota" sigue siendo una "Gaviota" a pesar de ser pasado a un método que recibe un "Animal". Entonces es verdad que el polimorfismo no determina que versión del método sobrecargado será llamado. El polimorfismo entra en juego cuando se decide cuál versión de un método sobre-escrito es llamado. Pero algunas veces un método puede ser ambos, sobre-escrito y sobrecargado. Imaginemos lo siguiente:


public class Animal
{
    public void comer()
    {
        System.out.println("El Animal genérico está comiendo");
    }
}

public class Gaviota extends Animal
{
    public void comer()
    {
         System.out.println("La gaviota está comiendo");
    }

    public void comer(String s)
    {
        System.out.println("La gaviota está comiendo esto: " + s);
    }
}

Noten que la clase "Gaviota" tiene sobrecargado y sobre-escrito el método "comer" (el método sobrecargado es el que recibe un String y el sobre-escrito el que no recibe nada).

La siguiente tabla muestra cuál de las versiones del método "comer" será llamado dependiendo de cómo sea invocado:

Código de Invocación al método	Resultado
Animal a = new Animal(); a.comer();	"el Animal genérico está comiendo"
Gaviota g = new Gaviota(); g.comer();	"La gaviota está comiendo"
Animal ag = new Gaviota(); ag.comer();	"La gaviota está comiendo" Polimorfismo trabajando: El objeto actual ("Gaviota"), no el tipo de referencia ("Animal"), es usado para determinar cuál versión del método "comer" es llamado.
Gaviota gp = new Gaviota(); gp.comer("peces")	"La gaviota está comiendo esto: peces" El método sobre cargado "comer(String s)" es llamado.
Animal a2 = new Animal(); a2.comer("manzanas");	¡¡Error de compilación!! El compilador mira la clase Animal y ve que no tiene un método comer que reciba un String.
Animal ag2 = new Gaviota(); ag2.comer("peras");	¡¡Error de compilación!! El compilador ve solo la referencia y sabe que "Animal" no tiene un método "comer" que reciba un String. Al compilador no le importa que el objeto actual pueda ser una "Gaviota" en tiempo de ejecución.

Diferencias entre métodos sobre cargados y sobre escritos:

	Método sobrecargado	Método sobre-escrito
Argumento(s)	Debe cambiar.	No debe cambiar.
Tipo de retorno	Puede cambiar.	No puede cambiar, excepto para retornos covariantes.
Excepciones	Puede cambiar.	Pueden no declarar una excepción del método que sobre-escribe, o declarar una subclase de esta excepción. No debe lanzar nuevas excepciones o más "amplias" que aquellas declaradas en el método que sobre-escribe.
Nivel de Acceso	Puede cambiar.	No pueden tener un nivel de acceso más restrictivo, pero si uno igual o menos restrictivo.
Invocación	El tipo de referencia determina cuál método sobrecargado es seleccionado, basado en el tipo de argumentos declarados. Sucede en tiempo de compilación.	El método real que se invoca es todavía una invocación de método virtual que siempre sucede en tiempo de ejecución, pero el compilador ya sabe la firma del método que se invoca. El tipo de objeto determina cuál método es seleccionado. Sucede en tiempo de ejecución.

Casting de variables de referencia

Hasta el momento hemos visto como es posible y común el uso de variables de referencia genéricas para referirse a tipos de objetos más específicos, eso es el corazón del polimorfismo, como ejemplo veamos la siguiente línea de código:


Animal animal = new Gaviota();

¿Pero qué sucede si queremos usar una variable de referencia "Animal" para invocar un método que solo la clase "Perro" tiene? Sabemos que nos estamos refiriendo a un Perro y queremos hacer una cosa específica de Perro.

En la siguiente línea de código tendremos un arreglo de Animales y cada vez que encontremos una Perro en el arreglo, haremos algo especial de Perro. Asumamos por el momento que todo el código escrito a continuación esté correcto, solo que no estamos seguros de la línea de código que invocara al método "hacerRuido".


public class Animal
{
    void hacerRuido()
    {
        System.out.println("Ruido Generico");
    }
}

public class Perro extends Animal
{
    void hacerRuido()
    {
        System.out.println("Ladrando");
    }

    void hacerseElMuerto()
    {
        System.out.println("Muriendo");
    }
}

public class Prueba
{
    public static void main(String... args)
    {
        Animal[] a = {new Animal(), new Perro(), new Animal()};

        for(Animal animal: a)
        {
            animal.hacerRuido();

            if(animal instanceof Perro)
            {
                animal.hacerseElMuerto(); //Se intenta invocar un metodo de Perro?
            }
        }
    }
}

Cuando compilemos el código anterior, el compilador nos enviara un mensaje como:


Cannot find Symbol

El compilador nos está diciendo: "Oye, la clase "Animal" no tiene un método "hacerseElMuerto"".

Ahora modifiquemos el bloque de la condicional if:


if(animal instanceof Perro)
{
    Perro perro = (Perro) animal; // Casteando la variable de referencia
    perro.hacerseElMuerto();
}

El nuevo y mejorado bloque de código contiene un "cast", el cual en algunos casos es llamado down casting, porque estamos bajando en el árbol de herencia a una categoría mas especifica.

Ahora el compilador no nos dará problemas, casteamos la variable "animal" a un tipo "Perro". El compilador nos está diciendo lo siguiente: "Sabemos que nos estamos refiriendo a un objeto del tipo Perro, está bien hacer una nueva variable de referencia de tipo Perro, para referirnos a este objeto", en este caso estamos bien, porque antes de intentar el "cast" hicimos una prueba de instanceof para asegurarnos.

Es importante saber que el compilador confía en nosotros cuando hacemos un down casting aun cuando pudiéramos hacer algo como lo siguiente:


public class Animal{}

public class Perro extends Animal{}

public class Prueba
{
    public static void main(String... args)
    {
        Animal animal = new Animal();
        Perro perro = (Perro)animal; //Compila pero fallara después 
    }
}

Este código compilara correctamente pero cuando intentemos ejecutarlo vamos a obtener una excepción como la siguiente:


java.lang.ClassCastException

¿Por qué no podemos confiar en el compilador para que nos ayude en esto? ¿No puede ver que animal es del tipo "Animal"? Todo lo que el compilador puede hacer es comprobar que los dos tipos pertenezcan al mismo árbol de herencia, por lo que dependiendo de lo que el código puede hacer antes del down casting, es posible de que "animal" sea del tipo "Perro". El compilador puede permitir cosas que posiblemente puedan funcionar en tiempo de ejecución. Sin embargo si el compilador sabe con certeza que el cast no puede funcionar, entonces la compilación fallara. El siguiente bloque de código NO compilará:


Animal animal = new Animal();
Perro p = (Perro) animal;
String s = (String) animal; //animal nunca puede ser un String

En este caso obtendremos un error como el siguiente:


inconvertible types

A diferencia del down-casting, el up-casting (convertir a un tipo más general en el árbol de herencia) trabaja implícitamente porque cuando estmos haciendo up-casting estamos implícitamente restringiendo el numero de métodos que podemos invocar, lo que impide que más adelante podamos invocar a un método más especifico, por ejemplo:


class Animal{}

class Perro extends Animal{}

class Prueba
{
    public static void main(String … args)
    {
        Perro p = new Perro();
        Animal a1 = p;  //upCasting, se puede sin conversión explicita
        Animal a2 = (Animal)p; // upCasting, se puede con conversión explicita
    }
}

Ambos up-castings anteriores compilaran y se ejecutaran sin excepción, porque un "Perro" ES-UN "Animal", lo que significa que lo que cualquier "Animal" pueda hacer, el "Perro" lo hará. Un "Perro" puede hacer más, pero en este punto, cualquiera con una referencia de "Animal" puede llamar con seguridad a los métodos de "Animal" en una instancia de "Perro". Los métodos de "Animal" pueden haber sido sobre-escritos en la clase "Perro", pero todo lo que importa ahora es saber que un "Perro" puede hacer todo lo que un "Animal" puede hacer. El compilador y la JVM saben esto también, entonces el up-casting implícito es siempre legar para la asignación de un objeto de un subtipo para una referencia a su súper tipo o interface. Si "Perro" implementa la interface "Mascota", y "Mascota" define el método "seAmigable()", un "Perro" puede implícitamente hacer casting a una "Mascota", pero el único método de "Perro" que se podrá invocar es "seAmigable()", el cual "Perro" fue forzado a implementar porque "Perro" implementó a la interface "Mascota".

Una cosa más, si "Perro" implementa a la interface "Mascota", y si "Sabueso" extiende a "Perro", pero "Sabueso" no declara que este implementando a "Mascota", "Sabueso" sigue siendo una "Mascota", "Sabueso" es una "Mascota" simplemente porque este está extendiendo a "Perro". La clase "Sabueso" puede siempre sobre-escribir cualquier método que este heredando desde "Perro", incluyendo los métodos que "Perro" implementa para cumplir con el contrato de la interfaz.

Por último, si "Sabueso" declara que implementa a "Mascota", es solamente para que los que busquen en "Sabueso" puedan ver fácilmente que "Sabueso" ES-UNA "Mascota", sin tener que mirar a la superclase de "Sabueso". "Sabueso" no tiene la necesidad de implementar el método "seAmigable()" si la clase "Perro" (súper clase de "Sabueso") ya se ha ocupado de eso. En otras palabras, si "Sabueso" ES-UN "Perro", y "Perro" ES-UNA "Mascota", entonces "Sabueso" ES-UNA "Mascota", y ya ha cumplido con los métodos de "Mascota" para la aplicación del método "seAmigable()", ya que hereda el método "seAmigable()". El compilador es suficientemente inteligente para decir: "Sé que Sabueso es un Perro, pero está bien para que sea más obvio".

Así que no hay que dejarse engañar por el código que muestra una clase concreta que declara que implementa una interfaz, pero no implementa el método de la interface, antes de poder decir si el código es legal, debemos mirar cuál es la superclase de la clase que esta implementado esta interface. Si alguna clase en el árbol de herencia ya ha implementado métodos concretos y ha declarado que ella (la superclase) implementa la interfaz, entonces la subclase no tiene ninguna obligación de volver a implementar (sobre-escribir) los métodos.

Implementando una interface

Cuando implementamos una interface estamos aceptando el contrato definido por la interfaz. Eso quiere decir que estamos obligados a implementar todos los métodos definidos por la interfaz y que cualquiera que conozca los métodos de la interfaz (no como lo implementa pero si como se llaman y que retornan) puede invocar estos métodos en una clase que implementa la interfaz.

Por ejemplo si creamos una clase que implemente a la interfaz "Runnable" (para que el código pueda ejecutarse en otro un hilo), debemos implementar el método "public void run()", de lo contrario el hilo verá que no tenemos implementado el método "run" de la interface "Runnable" y provocará un error. Afortunadamente, Java impide que esta crisis se produzca mediante la ejecución de un proceso de comprobación, en el compilador, de cualquier clase que pretende implementar una interfaz.

Si la clase está implementando una interface, deberíamos tener una implementación para cada método de la interface, con unas pocas excepciones que veremos en un momento.

Por ejemplo, imaginemos que tenemos la interfaz "Rebotable", con dos métodos "rebotar()" y "setFactorRebote", la siguiente clase compilará:


public class Pelota implements Rebotable  //palabra reservada implements
{ 
    public void rebotar(){}
    public void setFactorRebote(int fr){}
}

El contrato garantiza que una clase tenga todos los métodos de una interface pero no garantiza que tenga una buena o correcta implementación en el cuerpo del método. El compilador nunca se fijará que haya algo entre las llaves del método, nunca dirá que es un método y que debería hacer algo, solo se fija en que tenga los métodos que se describen en la interface, nada más.

Las clases que implementan una interface deben de seguir las mismas reglas para una clase que extiende a una clase abstracta.

Las reglas para que una clase NO abstracta implemente correctamente una interface son las siguientes:

Proveer implementación para todos los métodos declarados en la interface.
Seguir todas las reglas para una sobre-escritura legal (overrides).
No declarar excepciones, en la implementación del método, que no estén en el método definido en la interface. Se pueden declarar subclases de las declaradas por el método de la interfaz.
Mantener el mismo nombre del método de la interface y el mismo tipo de dato de retorno (o un subtipo).

Una clase que implementa una interface puede ser abstracta. Por ejemplo:


abstract class Pelota implements Rebotable{}

¿Notan que algo falta?, pues no estamos implementando los métodos de la interfaz "Rebotable", y no tenemos ningún error. Si la clase que implementa una interface es una clase abstracta esta puede simplemente pasar la implementación de los métodos a la primera clase concreta que se implemente.

Por ejemplo si tenemos la clase "PelotaPlaya" y esta extiende de la clase "Pelota", entonces la clase "PelotaPlaya" debe de implementar todos los métodos de la interfaz "Rebotable":


public class PelotaPlaya extends Pelota
{
    /*A pesar que no se dice en la declaración anterior (no hay implements a Rebotable)
      PelotaPlaya tiene que implementar a la interface Rebotable ya que la super clase
      abstracta de PelotaPlaya (Pelota) implementa a Rebotable */
      
    public void rebotar(){}
    
    public void setFactorRebote(int fr){} 
    
    /*Si la clase Pelota hubiera declarado algun método abstracto, entonces
     ese método debería estar implementado aquí también*/
}

A menos que la implementación sea de una clase abstracta, la implementación debe tener todos los métodos definidos por la interface.

Hay dos reglas más que debemos saber:

1. Una clase puede implementar más de una interface, por ejemplo:


public class Pelota implements Rebotable, Runnable, Serializable{}

Persona extends SerHumano

Persona

Programador

Empleado

Pariente

2. Una interface puede también extender a otra interface, pero nunca implementar nada, por ejemplo:


public interface Rebotable extends Movible{}

¿Qué significa esto? La primera clase concreta que implemente "Rebotable" debe implementar todos los métodos de esta interface, pero también debe implementar todos los métodos de la interface "Movible". La sub-interface simplemente está agregando más requerimientos al contrato de la super-interface.

Una interface puede extender a más de una interface, pero sabemos que cuando hablamos de clases esto es ilegal, por ejemplo:


public class Programador extends Empleado, Geek{} //Esto es ilegal!!

Como mencionamos anteriormente una clase no permite extender a más de una clase en Java, una interface, sin embargo, puede implementar a más de una interface, por ejemplo:


public interface Rebotable extends Movible, Inflable //OK
{ 
    void rebotar();
    void setFactorRebote(int fr);
}

interface Movible
{
    void muevete();
}

interface Inflable
{
    void inflate();
}

En el próximo ejemplo, "Pelota" requiere implementar la interface "Rebotable", pero también debe implementar todos los métodos de las interfaces que "Rebotable" ha extendido, incluyendo cualquier interface que aquellas interfaces extienden, y así sucesivamente hasta llegar a la parte superior de la pila. "Pelota" debe tener lo siguiente:


public class Pelota implements Rebotable
{
    public void rebotar(){}               //implementando metodos de la 
    public void setFactorRebote(int fr){} //interface Rebotable

    public void muevete(){} //implementando de Movible

    public void inflate(){} //implementando de Inflable
}

Si la clase "Pelota" no implementa cualquiera de los métodos de "Rebotable", "Movible" o "Inflable", el compilador encontrará errores, al menos que "Pelota" sea una clase abstracta. En el caso de que "Pelota" sea una clase abstracta esta puede implementar todos, algunos o ningún método de las interfaces, puede dejar la implementación a una sub clase concreta de "Pelota", por ejemplo:


abstract class Pelota implements Rebotable
{
    public void rebotar(){}               //define comportamiento de la
    public void setFactorRebote(int fr){} //interface Rebotable

    /*no implementa el resto de los métodos, deja el resto para una sub-clase concreta*/
}

class PelotaFutbol extends Pelota
{
    /*implementando métodos que pelota no hizo*/
    public void muevete(){} //implementando de Movible

    public void inflate(){} //implementando de Inflable

    /*PelotaFutbol puede elegir sobre escribir el método rebotar implementado en pelota*/
    public void rebotar(){} 
}

Comparando ejemplos de abstracto y concreto de extender e implementar:

Ya que "PelotaFutbol" es la primera clase concreta que Implementa "Rebotable", esta debe implementar todos los métodos de la interface "Rebotable", excepto aquellos definidos en la clase abstracta "Pelota". Ya que "Pelota" no provee implementación de los métodos de la interface "Rebotable", es necesario que "PelotaFutbol" implemente todos aquellos métodos.

Tipos Correctos de Retorno

El objetivo de esta sección es cubrir dos aspectos de los tipos de retorno:

1. Qué se puede declarar como un tipo de retorno, y
2. Qué se puede retornar como un valor.

Qué se puede y no se puede declarar es muy sencillo, pero esto depende si estamos sobre-escribiendo un método, heredado o simplemente declarando un método nuevo (el cual incluye sobrecarga de métodos). Daremos solo una pequeña mirada a las diferencias entre las reglas para los tipos de retorno para métodos sobre cargados y sobre-escritos (overloaded y overriding).

Declaración de tipos de retorno

Veremos qué está permitido para declarar como un tipo de retorno, lo cual depende primero en que si estamos sobre-escribiendo, sobrecargando o declarando un nuevo método.

Tipos de retorno en métodos sobre cargados

Recuerden que un método sobrecargado no es más que una forma para la reutilización del mismo nombre de un método pero con diferentes argumentos. Un método sobrecargado es un método completamente diferente de cualquier otro método con el mismo nombre. Si heredamos un método pero lo sobrecargamos este en una subclase, este no está sujeto a las restricciones de sobre-escritura, lo cual implica que podemos declarar cualquier tipo de retorno. Lo que no podemos hacer es cambiar solo el tipo de retorno. Para sobre cargar un método solo debemos cambiar la lista de argumentos, por ejemplo:


public class Animal
{
    void muevete(){};
}

public class Perro extends Animal
{
    String muevete(int numeroPasos)
    {
        return null;
    }
}

Noten que el método de "Animal" tiene un tipo de retorno diferente que el método de "Perro". Esto está bien. En el momento que se ha cambiado la lista de argumentos, hemos sobrecargado el método, entonces el tipo de retorno no tiene que coincidir con el del método de la súper clase, pero por ejemplo, lo siguiente no está permitido:


public class Animal
{
    void muevete(){};
}

public class Perro extends Animal
{
    String muevete() //Error, no se puede cambiar solo el tipo de retorno
    {  
        return null;
    }
}

Sobre escritura y tipos de retorno, retornos covariantes

Cuando una clase quiere cambiar la implementación del método de un método heredado (sobre-escrito), la subclase debe definir un método que debe coincidir exactamente con el método heredado. O, a partir de Java 5, se le permite cambiar el tipo de retorno en el método sobre-escrito siempre y cuando el nuevo tipo de retorno es un subtipo del tipo de retorno declarado en el método a sobre-escribir (superclase).


class Alpha 
{
    Alpha hacerAlgo(char c)
    {
        return new Alpha(); 
    }
}

class Beta extends Alpha
{
    Beta hacerAlgo(char c) //sobre escritura legal en Java 1.5
    { 
        return new Beta();
    }
}

En Java 5 este código compilara sin problemas, pero si intentamos compilar este código con Java 1.4, mostrará el siguiente error:


attempting to use incompatible return type

Otras reglas aplicadas a la sobre-escritura, incluyen aquellas para modificadores de acceso y declaración de excepciones.

Retornando un valor

Tenemos que recordar solo 6 reglas para retornar un valor:

1. Podemos retornar null a los métodos que tengan como tipo de retorno un objeto, ejemplo:


public Button hacerAlgo
{
    return null;
}

2. Podemos declarar un arreglo como tipo de retorno sin problemas, ejemplo:


public String[] go()
{
    return new String[]  {"Alan", "Alex", "Diego", "y Peke", "Henry", "Cesar", "Pedroww"};
}

3. En un método con un tipo de retorno primitivo, podemos retornar cualquier valor o variable que pueda ser implícitamente convertido al tipo de retorno declarado, ejemplo:


public int go()
{
    char c = ‘c’;
    return c; //char es compatible con int
}

4. En un método con un tipo de retorno primitivo, podemos retornar cualquier valor o variable que pueda ser explícitamente convertido al tipo de retorno declarado, ejemplo:


public int go()
{
    float f = 32.5f;
    return (int) f
}

5. No debemos retornar nada desde un método que tiene como tipo de retorno "void", ejemplo:


public void go()
{
    return "Esto es todo"; //Error, no es legal
}

6. En un método con un tipo de retorno con referencia a un objeto, podemos retornar cualquier tipo de objeto que pueda ser implícitamente convertido al tipo de retorno declarado, ejemplo:


public Animal getAnimal()
{
    return new Perro(); //Asumiendo que Perro extiende de Animal
}

public Object getObject()
{
    int[] nums =  {1, 2, 3};
    return nums; //retorna un arreglo de enteros, el cual sigue siendo un //objeto
}

public interface Rebotable{}

public class Pelota implements Rebotable{}

public class TestPelota
{
    //Método con una interface como tipo de retorno 
    public Rebotable getRebotable()
    {
        return new Pelota(); //Retorna un implementador de la interface
    }
}

Y con eso terminamos todo lo concerniente con las reglas para el retorno de tipos de valor. Ahora veremos algunos detalles interesantes sobre constructores e instanciación de objetos.

Constructores e Instanciación

Los objetos son construidos. No podemos crear un nuevo objeto sin invocar a un constructor. No podemos crear un nuevo objeto sin invocar al constructor del objeto actual y a los constructores de sus superclases.

Los constructores son código que se ejecuta cuando usamos la palabra reservada "new". También pueden ser bloques de inicialización que se ejecutan al escribir "new" (son como constructores pero un poco distintos), pero vamos a cubrir estos (bloques de inicialización), y sus homólogos de la inicialización estática, más adelante. Vamos a ver cómo se codifican los constructores y como trabajan en tiempo de ejecución.

Constructores Básicos

Todas las clases, incluyendo las clases abstractas, deben tener un constructor, pero solo porque una clase deba de tener un constructor no quiere decir que necesitamos escribirlo explícitamente. Un constructor es algo como esto:


public class Rectangulo
{
    Rectangulo(){} //Constructor para la clase Rectangulo
}

Un constructor no retorna ningún tipo de valor. Hay dos cosas que siempre debemos recordar acerca de los constructores:

1. No retornan ningún tipo de valor y
2. Llevan el mismo nombre que la clase.

Típicamente los constructores son utilizados para inicializar el estado de las variables de instancia, por ejemplo:


public class Rectangulo
{
    private int ancho;
    private int altura;

    public Rectangulo (int ancho, int altura) 
    {
        this.ancho = ancho;
        this.altura = altura;
    }
}

En el caso anterior, la clase "Rectangulo" no tienen un constructor sin argumentos, lo que significa que el siguiente código fallará en tiempo de compilación:


Rectangulo r = new Rectangulo(); //No compila, no coinciden el constructor

Pero el siguiente código, compilará correctamente:


Rectangulo r = new Rectangulo(4,2); //No hay problema, los argumentos coinciden con el constructor

Es muy común (y deseable) tener un constructor sin argumentos, independientemente del número de constructores sobrecargados que nuestra clase pueda tener (sí, los constructores pueden ser sobrecargados). De vez en cuando se tiene una clase en la que no tiene sentido crear una instancia sin necesidad de suministrar información al constructor. Un "java.awt.Color", por ejemplo, no puede ser llamado mediante una llamada a un constructor sin argumentos, porque es como decirle a la JVM: "Hazme un nuevo color, y no me importa qué tipo de color sea este... tu decide", ¿realmente creen que la JVM pueda tomar decisiones de ese tipo?

Encadenamiento de constructores

Sabemos que los constructores son invocados en tiempo de ejecución cuando usamos la palabra reservada "new" de la siguiente manera:


Perro p = new Perro();

Pero ¿qué es lo que realmente sucede cuando escribimos "new Rectangulo()"?

Asumamos que "Perro" extiende (hereda) de "Animal" y "Animal" extiende de "Object"

1. El constructor de "Perro" es invocado. Cada constructor invoca al constructor de su superclase con una llamada implícita a "super()", a menos que el constructor invoque a un constructor sobrecargado de la misma clase, pero esto lo veremos más adelante.
2. El constructor de "Animal" es invocado ("Animal" es la superclase de "Perro")
3. El constructor de "Object" es invocado ("Object" es la última superclase de todas las clases, entonces "Animal" extiende de "Object" a pesar de que no escribimos explícitamente "extends Object" en la declaración de la clase "Animal". Esto es Implícito), en este punto estamos en el cima de la pila.
4. Se asignan los valores explícitos a las variables de instancia. Nos referimos a las variables que declaramos como "int x = 24", donde 24 es el valor explicito (en comparación con el valor por defecto) de la variable de instancia.
5. El constructor de Object se completa.
6. Se asignan los valores explícitos a las variables de instancia de "Animal" (si tuviera).
7. El constructor de "Animal" completa.
8. Se asignan los valores explícitos a las variables de instancia de "Perro" (si tuviera).
9. El constructor de "Perro" completa.

A continuación mostramos como trabajan los constructores en la pila de llamadas:

4.- Object()
3.- Animal() llamada a super()
2.- Perro() llamada a super()
1.- main() llamada a new Perro()

Reglas para los constructores:

A continuación mostramos lo que debemos recordar acerca de los constructores:

Un constructor puede tener cualquier modificador de acceso, incluso "private" (un constructor privado quiere decir que solo el código dentro de la clase misma puede instanciar un objeto de ese tipo, así que si la clase con constructor privado quiere permitir que una clase pueda instanciarla, la clase debe proveer un método estático o variable que permitan acceder a una instancia creada dentro de la clase).
El constructor debe tener el mismo nombre que la clase.
El constructor no debe retornar ningún tipo de valor.
Es legal (pero tonto) tener un método con el mismo nombre de la clase, pero esto no hace que sea un constructor. Si ven que tiene un tipo de retorno, entonces es un método en vez de un constructor. Podemos tener ambos, un método y un constructor con el mismo nombre (el nombre de la clase) en una misma clase y esto no es problema para Java.
Si no escribimos ningún constructor dentro de la clase, un constructor por defecto será automáticamente generado por el compilador.
El constructor por defecto SIEMPRE es un constructor sin argumentos.
Si deseamos tener un constructor sin argumentos y ya hemos escrito algún otro constructor dentro de la clase, el compilador NO proporcionara un constructor sin argumentos (o cualquier otro constructor). Es decir si hemos escrito algún constructor con argumentos no vamos a tener un constructor sin argumentos a menos que nosotros mismos lo declaremos.
Todos los constructores tienen como primera declaración ya sea una llamada a un constructor sobre cargado "this()" o una llamada al constructor de la superclase "super()", aunque recuerden que esta llamada puede ser insertada por el compilador.
Si escribimos un constructor (en lugar de confiar en el constructor por defecto generado por el compilador), y no escribimos una llamada a this() o a super(), el compilador insertará una llamada sin argumentos a super() por nosotros, como una primera declaración en el constructor.
Una llamada a super() puede ser una llamada sin argumentos o podemos incluir argumentos en él.
Un constructor sin argumentos no es necesariamente el constructor por defecto, aunque el constructor por defecto siempre es uno sin argumentos. El constructor por defecto es el único que el compilador provee, pero podemos insertar nuestro propio constructor sin argumentos.
No podemos hacer una llamada a un método de instancia o acceder a una variable de instancia hasta que se ejecute el constructor super.
Solo variables y métodos estáticos pueden ser accedidos como parte de la llamada a super() o this(). Por ejemplo: super(Animal.NOMBRE) está bien ya que NOMBRE está declarada como variable estática.
Las clases abstractas tienen constructores, y estos constructores son siempre llamados cuando una clase concreta es instanciada.
Las interfaces no tienen constructores, las interfaces no son parte del árbol de herencia de un objeto.
La única forma de que un constructor pueda ser invocado es dentro de otro constructor, en decir, no podemos invocar a un constructor de la siguiente manera:


public class Perro
{
    public Perro(){} //Contructor
    
    public void hacerAlgo()
    {
        Perro(); //llamada al constructor. Error!!
    }
}

Determinar si un constructor por defecto será creado

El siguiente código muestra a la clase "Perro" con dos constructores:


public class Perro
{
    public Perro(){}
    public Perro(String nombre){}
}

¿El compilador insertará un constructor por defecto para la clase anterior? ¡¡NO!!

¿Y para la siguiente modificación en la clase?


public class Perro
{
    public Perro(String nombre){}
}

¿Ahora el compilador insertará un constructor por defecto? ¡¡NO!!

¿Y qué hay de esta clase?


public class Perro
{  
}

El compilador SI generará un constructor por defecto para la clase anterior, porque la clase no tiene ningún constructor definido. Y ahora ¿Qué hay de esta siguiente clase?:


public class Perro
{ 
    void Perro(){}
}

Podría parecer que el compilador no crea un constructor ya que ya hay un constructor en la clase "Perro". ¿Pero realmente hay un constructor? Revisemos nuevamente la clase anterior, pues eso no es un constructor, es solo un método que tiene el mismo nombre que la clase. Recordemos que el tipo de retorno es un claro indicador de que eso es un método y no un constructor.

¿Cómo se sabe con seguridad que un constructor por defecto será creado?

Porque no declaramos NINGUN constructor en nuestra clase.

¿Cómo se verá el constructor por defecto creado por el compilador?

El constructor por defecto tiene el mismo modificador de acceso que la clase.
El constructor por defecto no tiene argumentos.
El constructor por defecto incluye una llamada sin argumentos al súper constructor (super()).

¿Qué sucede si el súper constructor tiene argumentos?

Los constructores pueden tener argumentos así como los métodos, si tratamos de invocar a un método que toma por ejemplo un int y no le pasamos nada al método, el compilador se comportará de la siguiente manera:


class Ejemplo
{
    void tomaUnInt(int valor){}
}

class Test
{
    public static void main(String … args)
    {
        Ejemplo e = new Ejemplo();
        e.tomaUnInt();  //Se está tratando de invocar al metodo "tomaUnInt()" sin argumentos
    }
}

El compilador nos dirá que estamos tratando de invocar a "tomaUnInt()" sin pasarle ningún un int. El compilador, según la versión de la JVM, responderá más o menos de la siguiente manera:


Test.java:7: tomaUnInt(int) in Ejemplo cannot be applied to ()e. tomaUnInt();

Esto quiere decir que debemos pasar los mismos valores o variables que el método acepta y en el mismo orden en el que esté declarado en el método, a lo que queremos llegar es que este mecanismo funciona exactamente igual en los constructores.

A continuación mostramos el código que genera el compilador con respecto a los constructores:

Código de clase (lo que nosotros escribimos)	Código de constructor generado por el compilador
`class Perro { }`	`class Perro { Perro() { super(); } }`
`class Perro { Perro(){} }`	`class Perro { Perro() { super(); } }`
`public class Perro { }`	`public class Perro { public Perro() { super(); } }`
`class Perro { Perro(String nombre){} }`	`class Perro { Perro(String nombre) { super(); } }`
`class Perro { Perro(String nombre) { super(); } }`	Nada, el compilador no necesita insertar nada
`class Perro { void Perro(){} }`	`class Perro { void Perro(){} Perro() { super(); } }` ("void Perro()", es un método no un constructor)

Si el súper constructor (el constructor de su inmediata súper clase o clase padre) tiene argumentos, debemos escribir en la llamada a super() los argumentos adecuados.

Un punto crucial: si nuestra superclase no tiene un constructor sin argumentos, debemos escribir un constructor en la clase (subclase), porque necesitamos un lugar donde insertar, en la llamada a super, los argumentos adecuados.

El siguiente código da un ejemplo del problema:


class Animal
{
    Animal(String nombre){}
}

class Perro extends Animal
{
    Perro()
    {
        super(); //He aquí el problema
    }
}

El compilador nos arrojará algo como esto:


Perro.java:7: cannot resolve symbol
symbol  : constructor Animal  ()
location: class Animal
       super();  // Problema! 
       ^

Otra forma de explicar es la siguiente: Si nuestra superclase no tiene un constructor sin argumentos entonces la subclase no será capaz de usar el constructor por defecto que te provee el compilador, es decir, el compilador puede solo insertar una llamada a "super()" sin argumentos, no será capaz de compilar algo como esto:


class Animal
{
    Animal(String nombre){}   
}

class Perro extends Animal{}

El compilador nos arrojará algo como esto:


Animal.java:4: cannot resolve symbol
symbol  : constructor Animal ()  
location: class Animal
class Perro extends Animal { }
^

El compilador explícitamente está haciendo el código que se muestra a continuación, donde vamos a proveer a "Perro" el mismo constructor que el compilador le proveerá:


class Animal
{
    Animal(String nombre){}
}

class Perro extends Animal
{
    //el constructor a continuación es idéntico al que el compilador proveerá
    Perro()
    {
        super(); //¡¡Se invoca al constructor sin argumentos de "Animal" el cual no existe!!
    }
}

Una última cosa que debemos recordar es que los constructores no se heredan, estos no son métodos los cuales si se heredan. Estos no pueden ser sobre-escritos pero, como hemos visto a lo largo de esta parte de constructores, estos si se pueden sobrecargar.

Sobrecarga de constructores

Sobrecargar un constructor quiere decir que escribimos diferentes versiones del constructor, cada uno tiene diferente número de argumentos, como por ejemplo:


class Perro
{
    Perro(){} 
    
    Perro(String nombre){}
}

La clase "Perro" anterior muestra dos constructores sobrecargados, uno de ellos toma un String como argumento y el otro no tiene argumentos; este es exactamente igual al constructor que el compilador provee, pero recordemos que una vez que nosotros escribamos un constructor en la clase, como por ejemplo el que toma el String, el compilador ya no nos proveerá un constructor por defecto. Si queremos un constructor sin argumentos para sobrecargar el que tiene argumentos nosotros mismo tendremos que escribirlo como en el ejemplo anterior.

Sobrecargando un constructor proveemos diferentes maneras de que se pueda instanciar un objeto de nuestra clase, por ejemplo si sabemos el nombre del Perro, podemos pasarselo a un constructor de "Perro" que toma una cadena. Pero si no sabemos el nombre podemos llamar al constructor sin argumentos para que nos provea un nombre por defecto, a continuación mostramos un ejemplo de lo que estamos hablando:


1. public class Perro {
2.      String nombre;
3.      Perro (String nombre){
4.              this.nombre = nombre;
5.      }
6. 
7.      Perro(){
8.              this(tomaNombreAleatorio());
9.      }
10. 
11.      static  String tomaNombreAleatorio(){
12.               int x = (int) (Math.random() * 5);
13.               String nombre = new String[]{"fido", "tango", "aguao", "rex" , "lassy"}[x];
14.               return nombre;
15.       }
16. 
17.      public static void main(String … args){
18.               Perro a = new Perro();
19.               System.out.println(a.nombre);
20.               Perro b = new Perro("flafy");
21.               System.out.println(b.nombre);
22.       }
23. }

Ejecutando el código unas cuantas veces tendremos un resultado como el siguiente:


% java Perro 
tango  
flafy
% java Perro 
lassy  
flafy
% java Perro 
rex  
flafy
% java Perro 
aguao
flafy

A continuación mostramos la pila de llamadas para la invocación del constructor cuando un constructor es sobrecargado.

4. Object
3. Perro(String nombre) llamada a super()
2. Perro() llamada a this(tomaNombreAleatorio())
1. main() llamada a new Perro()

Ahora vamos a describir el código desde la parte superior:

Línea 2: declaramos una variable de instancia nombre de tipo String
Línea 3 – 5: El constructor toma un String y lo asigna a la variable de instancia nombre
Línea 7: Aquí viene lo interesante. Asumiendo que cada Animal necesita de un nombre, pero la persona que lo invoca no siempre debe saber que nombre será (código de llamada), entonces nosotros establecemos un nombre aleatorio. El constructor sin argumentos genera un nombre aleatorio invocando al método "tomaNombreAleatorio()".
Línea 8: El constructor sin argumentos invoca a su propio constructor sobrecargado que toma un String llamandolo de la misma manera que sería llamado si se hace una nueva instancia del objeto, pasándole un String para el nombre. La invocación al constructor sobrecargado se hace mediante la palabra reservada "this", pero la utiliza como si fuese un nombre de método, this(). Entonces en la línea 8 simplemente se está llamando al constructor sin parámetros que está en la línea 3, pasándole un nombre aleatorio en lugar nosotros establecer el nombre.
Línea 11: Notemos que el método "tomaNombreAleatorio()" está marcado como estático (static), eso es porque no podemos invocar a un método de instancia (en otras palabras, no estático) o acceder a una variable de instancia hasta después de que el super constructor haya sido ejecutado, y hasta que el súper constructor sea invocado desde el constructor en la línea 3, en lugar que de la línea 7, la línea 8 puede usar solo un método estático para generar un nombre. Si nosotros quisiéramos especificar algún nombre en específico en vez de que se genere aleatoriamente, por ejemplo, "Thor", entonces en la línea 8 simplemente pondríamos this("Thor") en lugar de llamar al método "tomaNombreAleatorio()" para generar un nombre aleatorio.
Línea 12: Esto no tiene nada que ver con el constructor pero es bueno aprenderlo, esto genera un numero entero aleatorio entre 0 y 4;
Línea 13: Estamos creando un nuevo String, pero queremos que este String sea seleccionado aleatoriamente desde una lista, entonces necesitamos hacer esto. Para explicarlo con mejor detalle, en esta sola línea de código hacemos lo siguiente:
1. 1. Declaramos una variable del tipo String.
2. 2. Creamos un arreglo de Strings (anónimo ya que no asignamos el arreglo)
3. 3. Obtenemos el String en index [x] (x contiene el numero aleatorio generado en la línea 12) del recientemente creado arreglo de Strings.
4. 4. Asignamos el String obtenido del arreglo a la variable de instancia "nombre". Esto hubiera sido más fácil de leer si hubiéramos escrito esto:
```
String[] lista  = {"fido", "tango", "aguao", "rex" , "lassy"};
String nombre = lista[x];
```
Línea 18: Invocamos al constructor sin argumentos (generando un nombre aleatorio que después será enviado al constructor que recibe un String).
Línea 20: Invocamos al constructor sobrecargado que toma un String que representa el nombre.

El punto cable en el código antes escrito está en la línea 8, en lugar de llamar a super(), estamos llamando a "this()", y "this()" siempre significa llamar a otro constructor en la misma clase. ¿Pero qué sucede al momento de llamar a "this()"? Tarde o temprano el constructor "super()" será llamado, una llamada a "this()" solo significa que estamos retrasando lo inevitable, ya que algún constructor en algún lugar debe hacer una llamada a "super()".

La regla clave: la primera línea de un constructor debe ser una llamada a "super()" o una llamada a "this()".

Sin excepciones. Si el constructor "A()" tiene una llamada a "this()", el compilador sabe que el constructor "A()" no será e que invoque a "super()".

La regla anterior significa que un constructor nunca podrá tener ambas llamadas, es decir no podrá llamar a la vez a "this()" y a "super()". Porque alguna de estas llamadas debe ser la primera sentencia en un constructor, no podemos usar ambas en un mismo constructor. El compilador tampoco insertará una llamada a "super()" si el constructor tiene una llamada a "this()".

¿Qué sucederá si nosotros tratamos de compilar el siguiente código?


class A
{
    A()
    {
        this("test");
    }

    A(String s)
    {
        this();
    }
}

El compilador puede que no capte el problema (esto depende del compilador). Este asume que sabemos lo que estamos haciendo. ¿Captan el problema? Sabemos que el súper constructor siempre debe de ser llamado, entonces ¿Dónde podría ir la llamada a "super()"? Recordemos que el compilador no inserta ningún constructor por defecto si nosotros ya insertamos uno o más constructores en nuestra clase, y cuando el compilador no inserta un constructor por defecto todavía puede insertar una llamada a super() en algún constructor que no tenga explícitamente una llamada a super(), a menos que, el constructor ya tenga una llamada a this() y recordemos que un constructor no puede tener ambas llamadas (this() y super()). Entonces en el código anterior ¿Dónde va la llamada a super()? Si los únicos dos constructores en la clase tienen una llamada a this(), en efecto nosotros tenemos el mismo problema que tendríamos si escribimos los siguientes métodos:


public void ir()
{
    hacerAlgo();
}

public void hacerAlgo()
{
 ir();
}

¿Ahora pueden ver el problema? Podemos ver que el stack explota. Ya que se llamaran uno a otro indefinidamente hasta que la maquina o la JVM estalle (esperamos que lo segundo suceda primero… ¿o lo primero?). Regresando al ejemplo de los constructores podemos decir que dos constructores sobrecargados y ambos con una llamada a this() son dos constructores llamándose uno a otro una y otra y otra vez, resultando en:


% java A
Exception in thread "main" java.lang.StackOverflowError

El beneficio de tener constructores sobrecargados es que ofrecen formas flexibles de poder instanciar un objeto de nuestra clase. El beneficio de que un constructor invoque a otro constructor sobrecargado es evitar duplicación de código, en el ejemplo anterior no hubo algún otro código para establecer el nombre, pero imaginen que después de la línea 4 aún hay muchas cosas que podríamos hacer.

Variables y métodos estáticos

El modificador "static" tiene un impacto tan profundo en el comportamiento de un método o una variable que debemos tratando como un concepto totalmente separado de los demás modificadores. Para entender la manera en que un miembro estático trabaja, primero veremos las razones por las cuales utilizaríamos alguno.

Imaginen que tenemos una clase de utilidad la cual siempre se ejecuta de la misma manera, su única función es devolver, digamos, un número al azar. No nos importa en cuál instancia de la clase se ejecuta el método, ya que siempre se comporta de la misma manera. En otras palabras, el comportamiento del método no tiene ninguna dependencia en el estado (valores de variable de instancia) de un objeto. Entonces ¿Porque es necesario un objeto cuando el método nunca será instanciado? ¿Por qué no solo pedimos a la clase en si misma que ejecute el método?

Ahora imaginemos otro escenario: supongamos que queremos mantener un contador corriendo para todas las instancias de una clase en particular. ¿En dónde incluiremos la variable? No va a trabajar si la incluimos como variable de instancia dentro de las clases en las cuales se quiere hacer el seguimiento, ya que el contador siempre se iniciara a un nuevo valor por defecto cada que nosotros creamos una nueva instancia.

La respuesta a los dos escenarios anteriores (el método de utilidad que se ejecuta siempre de la misma manera, y el contador para mantener el total de instancias actualizado) es utilizar el modificador static.

Las variables y métodos marcados con static pertenecen a la clase y no a una instancia en particular. Podemos usar un método o variable static sin tener instancias de esa clase, solo necesitamos que la clase esté disponible para invocar un método static o acceder a una variable static.

Una variable estática de una clase será compartida por todas las instancias de esa clase, sólo hay una copia.

El siguiente código utiliza una variable static que será utilizada como contador:


class Oveja
{
    static int contadorOvejas = 0; //Declaramos e inicializamos la variable estática 
 
    public Oveja()
    {
        contadorOveja += 1; //Modificamos el valor en el constructor
    }

    public static void main(String … args)
    {
        new Oveja();
        new Oveja();
        new Oveja();

        System.out.println("El contador de ovejas está ahora en: " + contadorOveja);
    }
}

En el código anterior, la variable estática "contadorOveja" es establecida en cero cuando la clase "Oveja" es cargada por primera vez por la JVM, antes de que cualquier instancia de "Oveja" sea creada (en realidad no se necesita inicializar la variable estática en cero, las variable estáticas obtienen los mismos valores por defecto que las variables de instancia obtienen). Cada vez que una instancia de la clase "Oveja" es creada el constructor de "Oveja" es ejecutado y la variable "contadorOveja" es incrementada. Cuando este código es ejecutado, tres instancias de "Oveja" son creadas en el "main()", y el resultado es el siguiente:


El contador de ovejas está ahora en: 3

Ahora imaginemos que sucedería si la variable "contadorOveja" fuera una variable de instancia (es decir, una variable no estática):


class Oveja
{
    int contadorOvejas = 0; //Declaramos e inicializamos la variable de instancia  
 
    public Oveja()
    {
        contadorOveja += 1; //Modificamos el valor en el constructor
    }

    public static void main(String... args)
    {
        new Oveja();
        new Oveja();
        new Oveja();

        System.out.println("El contador de ovejas está ahora en: " + contadorOveja);
    }
}

Cuando este código es ejecutado, este puede todavía crear tres instancias de la clase "Oveja" en el "main()", pero el resultado es un error de compilación. No podemos compilar este código, mucho menos ejecutarlo, porque obtenemos el siguiente error:


Exception in thread "main" java.lang.RuntimeException: Uncompilable source code - non-static variable contadorOveja cannot be referenced from a static context
System.out.println("El contador de ovejas está ahora en: " + contadorOveja);
^

La JVM no sabe a cuál objeto "contadorOveja" de "Oveja" estamos intentando de acceder. El problema está en que el método "main()" en sí mismo es un método estático. Un método estático no puede acceder a una variable no estática (variable de instancia) porque hay que recordar que para acceder a una variable estática no se necesita una instancia de la clase, ya que la variable pertenece a la clase misma.

Eso no quiere decir que no hay instancias de la clase con vida en la heap, si las hay, pero el método estático no sabe nada de ellas.

Lo mismo se aplica a los métodos de instancia, un método estático no pueden invocar directamente un método no estático.

Piensen que static=clase, no-estático=instancia. Haciendo que el método llamado por la JVM ("main()") sea un método estático la JVM no tiene que crear una instancia de la clase sólo para iniciar la ejecución de código.

Accediendo a métodos y variables estáticos

Puesto que no es necesario tener una instancia para invocar un método estático o acceder a una variable estática, entonces ¿cómo invocar o utilizar un miembro estático? ¿Cuál es la sintaxis? Sabemos que con un método de instancia regular, se utiliza el operador punto "." en una referencia, por ejemplo:


class Oveja
{
    static int contadorOvejas = 0; //Declaramos e inicializamos la variable estática  
 
    public Oveja()
    {
        contadorOveja += 1; //Modificamos el valor en el constructor
    }

    public static void main(String... args)
    {
        new Oveja();
        new Oveja();
        new Oveja();
        System.out.println("El contador de ovejas está en: " + Oveja.contadorOveja);
    }
}

Pero para que sea realmente confuso, el lenguaje Java también permite el uso de una variable de referencia de objeto para acceder a un miembro estático:


    Oveja ov = new Oveja();
    ov.contadorOveja; //Accediendo a la variable estática contadorOveja usando o

En el código anterior, hemos instanciado una "Oveja" asignando "new Oveja" a la variable de referencia "ov", y después usamos la referencia "ov" para invocar al método estático. Pero a pesar de que se está utilizando una instancia específica para acceder al método estático, las reglas no han cambiado. Esto no es más que un truco de sintaxis que nos permite utilizar una variable de referencia a objeto (pero no el objeto que se refiere) para llegar a un método o variable estática, pero el miembro estático sigue ignorando la instancia utiliza para invocar al miembro estático. En el ejemplo de la Oveja, el compilador sabe que la variable de referencia "ov" es del tipo de Oveja, por lo que el método estático de la clase Oveja se ejecuta sin conocimiento o interés para la instancia de la Oveja del otro extremo de la referencia "ov". En otras palabras al compilador le importa solo que la variable de referencia "ov" sea del tipo Oveja.

El compilador en realidad hace una transformación a la llamada que acabamos de hacer. Cuando ve que estamos tratando de invocar a un miembro estático, reemplaza la variable de instancia que estamos usando por la clase en la que está dicho miembro. Esto quiere decir que reemplazara esta llamada:


    Oveja ov = new Oveja();
    ov.contadorOveja;

Por esta otra:


    Oveja ov = new Oveja();
    Oveja.contadorOveja;

Así que como podemos ver, finalmente quedamos con una llamada al miembro estático, a través de la clase a la que pertenece dicho miembro.

La siguiente imagen describe el efecto del modificador static en métodos y variables:

Finalmente, recuerden que los métodos estáticos no pueden ser sobrescritos. Pero esto no significa que no puedan ser redefinidos en una subclase. Redefinir y sobrescribir no son la misma cosa. A continuación mostramos un ejemplo sobre redefinir (no sobrescribir) un método marcado como static:


class Animal
{
    static void hacerAlgo()
    {
        System.out.println("a");
    }
}

class Perro extends Animal
{
    static void hacerAlgo()
    {
        System.out.println("b"); //Esto es redefinir, no sobrescribir
    }

    public static void main(String... args)
    {
        Animal[] a = {new Animal(), new Perro(), new Animal()};

        for(int i = 0; i < a.length; i++ )
        {
            a[i].hacerAlgo(); //Invoca al método estático 
        }
    }
}

Ejecutando el código anterior se produce la siguiente salida:


a   a   a

Recuerden, la sintaxis "a[i].hacerAlgo()" es solo un atajo (un truco de sintaxis). El compilador lo sustituye con algo como "Animal.hacerAlgo()", como vimos hace un momento.

Cohesión y acoplamiento (Coupling and Cohesion):

Estos dos temas, la cohesión y el acoplamiento, tienen que ver con la calidad de un diseño orientado a objetos. En general un buen diseño pide un acoplamiento bajo y evita un acoplamiento estrecho y un buen diseño orientado a objetos pide una alta cohesión y evita la baja cohesión. Como con la mayoría de las discusiones sobre diseño de orientación a objetos, las metas de una aplicación son:

Facilidad de creación.
Facilidad de mantenimiento.
Facilidad de mejora.

Acoplamiento

Vamos a empezar haciendo un intento sobre la definición de acoplamiento. Acoplamiento es el grado en el cual una clase sabe acerca de otra clase. Si el único conocimiento que la clase "A" tiene acerca de la clase "B", es lo que la clase "B" ha puesto de manifiesto a través de su interface, se dice que la clase "A" y "B" están débilmente acopladas, lo cual es algo bueno. Si por otro lado, la clase "A" se basa en una parte de la clase "B", que no es parte de la interface de la clase "B", entonces el acoplamiento entre estas dos clases es más estrecho, y esto no es algo bueno. En otras palabras, si la clase "A" sabe más de lo que debería de la forma en que se implementó "B", entonces "A" y "B" están estrechamente acopladas.

Usando este segundo escenario, imaginemos lo que sucede cuando la clase "B" sea mejorada. Es muy posible que el desarrollador que mejore a "B" no tenga conocimiento acerca de "A" ¿Y porque debería de tenerlo? El desarrollador de la clase "B" debe pensar (y es correcto) que todas las mejoras que no quiebren o rompan la interfaz de la clase deben ser seguras, por lo que podría cambiar alguna parte que no tenga que ver con la interface en la clase. Si las dos clases están estrechamente acopladas, este cambio provocaría que la clase "A" se quiebre.

Veamos un ejemplo obvio de acoplamiento fuerte, que ha sido posible gracias a una pobre encapsulación:


class Impuestos
{
    float ratio;
    
    float calculaImpuestoVentaPeru()
    {
        RatioImpuestoVentas riv = new RatioImpuestoVentas(); 
        ratio = riv.ratioVentas;  /*Mal, esto debería ser una llamada a un 
                                    método get para obtener la variable, por ejemplo:
                                    ratio = riv.getRatioVentas("PE");  */
    }
}

class RatiosImpuestoVentas
{
    public float ratioVentas;       //Debería ser privado
    public float ajusteRatioVentas; //Debería ser privado
 
    public float getRatioVentas(String pais)
    {
        ratioVentas = new Impuestos().calculaImpuestoVentaPeru(); //Mal otra vez hacer basado en los cálculos de la región.
        
        return ajusteRatioVentas;
    }
}

Todas las aplicaciones orientadas a objetos que no son triviales son una mezcla de muchas clases e interfaces trabajando juntas. Idealmente, todas las interacciones entre los objetos en un sistema orientado a objetos deben utilizar sus APIs, en otras palabras, los contratos de las clases de los objetos respectivos. Teóricamente, si todas las clases en una aplicación tienen bien diseñada sus APIs, entonces debería ser posible para todas las interacciones entre las clases el uso de las APIs de forma exclusiva. Como hemos comentado anteriormente en este capítulo, un aspecto de buen diseño de una clase y el diseño de la API es que las clases deben estar bien encapsuladas.

Cohesión

Mientras que el acoplamiento tiene que ver con cómo las clases interactúan con las otras clases, la cohesión es acerca de cómo una simple clase es diseñada. El termino cohesión es usado para indicar el grado para el cual una clase tiene un propósito simple bien enfocado . Hay que mantener en mente que la cohesión es un concepto subjetivo al igual que el acoplamiento. Cuanto más enfocada sea la clase en una sola tarea, mayor su cohesión, lo cual es bueno. El beneficio clave de la alta cohesión, es que estas clases son mucho más fáciles de mantener (y menos frecuentes a ser cambiadas) que las clases con baja cohesión. Otro beneficio de la alta cohesión es que las clases con un propósito bien enfocado tienden a ser más reutilizables que otras clases. Veamos un ejemplo:


class ReportePresupuesto
{
    void conectarBaseDatos(){}
    void generarReportePresupuesto(){}
    void guardarArchivo(){}
    void imprimir(){}
}

Ahora imaginen que su jefe llega y dice, "Eh, ¿sabes de la aplicación de contabilidad que estamos trabajando? Los clientes decidieron que también van a querer generar un informe de proyección de ingresos, y que quieren hacer algunos informes de inventario también".

También les dice que se aseguren de que todos estos informes les permitan elegir una base de datos, seleccione una impresora, y guardar los informes generados a ficheros de datos ... ¡Ouch!

En lugar de poner todo el código de impresión en una clase de informe, probablemente hubiera sido mejor usar el siguiente diseño desde el principio:


class ReportePresupuesto
{
    Opciones getOpcionesReporte() {}
    void generarReportePresupuesto(Opciones o){} 
}

class ConexionBaseDatos
{
    ConexionBD getConexion(){}
}

class Impresion
{
    OpcionesImpresion getOpcionesImpresion(){}
}

class AlmacenArchivos
{
    OpcionesGuardado getOpcionesGuardado(){}
}

Este diseño es mucho más cohesivo. En lugar de una clase que hace todo, hemos roto el sistema en cuatro clases principales, cada uno con un rol muy específico (cohesión).

Como hemos construido estas clases especializadas, reutilizables, y va a ser mucho más fácil escribir un nuevo informe, dado que ya tenemos la clase de conexión de bases de datos, la clase de impresión, y la clase para guardar archivos, y eso significa pueden ser reutilizados por otras clases pueden desear imprimir un informe.

Este es el fin del segundo tutorial, donde hemos aprendido un poco sobre algunos de los conceptos más importantes de la orientación a objetos que son necesarios para el examen de certificación, y para nuestra vida como programadores en general.El la próxima entrega seguiremos aprendiendo más temas importantes para nosotros como programadores Java y en particular para los que deseen certificarse como programadores Java.

Muchas gracias a Alan Cabrera Avanto, de Trujillo Perú por este tutorial.

Saludos.

Entradas Relacionadas:

Parte 1: Declaraciones y Controles de Acceso

Struts 2 - Parte 3: Trabajo con Formularios

2011-10-22T14:19:00.000-07:00

En el desarrollo de aplicaciones web, una de las partes más importantes que existen (sino es que la más importante) es el manejo de datos que son recibidos del usuario a través de los formularios de nuestra aplicación.

Aunque es algo que usamos (y hacemos) todos los días, el manejo de los datos de los formularios puede ser un poco engañoso, por no decir complicado, cuando comenzamos a trabajar con la recepción de múltiples valores para un mismo parámetro, o cuando de antemano no conocemos los nombres de los parámetros que recibiéremos; esto sin mencionar las validaciones para los distintos tipos de datos, la carga y descarga de archivos, etc.

En este tutorial aprenderemos la forma en la que se trabaja con formularios en Struts 2, y cómo manejar todas las situaciones mencionadas anteriormente. Concretamente aprenderemos cómo hacer 7 cosas: recepción de parámetros simples, cómo hacer que el framework llene de forma automática los atributos de un objeto si es que todos los datos del formulario pertenecen a ese objeto, a recibir múltiples valores para un mismo parámetro, cómo recibir parámetros cuando no conocemos el nombre de los mismos, a realizar validaciones de datos de varias maneras, cómo subir archivos al servidor, y cómo enviar archivos desde el servidor hacia nuestros clientes.

En el primer tutorial de la serie vimos los pasos básicos para enviar datos a nuestros Actions a través de un formulario, sin embargo en esta ocasión veremos algunos conceptos un poco más avanzados que nos harán la vida más fácil cuando trabajemos con formularios.

Lo primero que haremos es crear un nuevo proyecto en NetBeans. Vamos al menú "File -> New Project...". En la ventana que aparece seleccionamos la categoría "Java Web" y en el tipo de proyecto "Web Application". Presionamos el botón "Next >" y le damos un nombre y una ubicación a nuestro proyecto; presionamos nuevamente el botón "Next >" y en este punto se nos preguntará el servidor que queremos usar. En nuestro caso usaremos el servidor "Tomcat 7.0", con la versión 5 de JEE y presionamos el botón "Finish".

Una vez que tengamos nuestro proyecto debemos recordar agregar la biblioteca "Struts2" (o "Struts2Anotaciones" si van a hacer uso de anotaciones, como es mi caso ^_^), que creamos en el primer tutorial de la serie. Hacemos clic derecho sobre el nodo "Libraries" del proyecto. En el menú que aparece seleccionamos la opción "Add Library...". En la ventana que aparece seleccionamos la biblioteca "Struts2" o "Struts2Anotaciones" y presionamos "Add Library". Con esto ya tendremos los jars de Struts 2 en nuestro proyecto.

Ahora configuramos el filtro "struts2" en el deployment descriptor. Abrimos el archivo "web.xml" y colocamos el siguiente contenido, como se explicó en el primer tutorial de la serie:


<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>struts2</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Ahora procedemos a crear una clase que nos servirá como modelo de datos. Esta será una clase "Usuario" la cual tendrá atributos de varios tipos para que veamos como Struts 2 realiza su "magia".

Creamos un paquete para nuestro modelo de datos. En mi caso el primer paquete se llamará "com.javatutoriales.struts2.formularios.modelo". Hacemos clic derecho sobre el nodo "Source packages" del proyecto, en el menú que aparece seleccionamos la opción "new -> package". En la ventana que aparece le damos el nombre correspondiente a nuestro paquete.

Ahora, dentro de este paquete creamos la clase "Usuario": sobre el paquete que acabamos de crear hacemos clic derecho y en el menú contextual que aparece seleccionaos la opción "new -> Java Class". El la ventana que aparece le damos el nombre "Usuario" y hacemos clic en el botón "Finish". Con esto aparecerá en nuestro editor la clase "Usuario" de la siguiente forma:


public class Usuario
{
}

Antes que nada hacemos que esta clase implemente la interface "java.io.Serializable" como deben hacerlo todas las clases de transporte de datos:


public class Usuario implements Serializable
{
}

Ahora agregaremos unos cuantos atributos a esta clase, de distintos tipos, representado algunas de las características de nuestro usuario. Dentro de estos atributos incluiremos su nombre, edad, y fecha de nacimiento:


public class Usuario implements Serializable
{
    private String nombre;
    private String username;
    private String password;
    private int edad;
    private Date fechaNacimiento;
}

Recuerden que el "Date" de "fechaNacimiento" debe ser de tipo "java.util.Date".

Para terminar con la clase Usuario agregaremos los getters y los setters de estos atributos, y adicionalmente dos constructores, uno que reciba todos los atributos, y uno vacio:


public class Usuario implements Serializable
{
    private String nombre;
    private String username;
    private String password;
    private int edad;
    private Date fechaNacimiento;

    public Usuario()
    {
    }

    public Usuario(String nombre, String username, String password, int edad, Date fechaNacimiento)
    {
        this.nombre = nombre;
        this.username = username;
        this.password = password;
        this.edad = edad;
        this.fechaNacimiento = fechaNacimiento;
    }

    public int getEdad()
    {
        return edad;
    }

    public void setEdad(int edad)
    {
        this.edad = edad;
    }

    public Date getFechaNacimiento()
    {
        return fechaNacimiento;
    }

    public void setFechaNacimiento(Date fechaNacimiento)
    {
        this.fechaNacimiento = fechaNacimiento;
    }

    public String getNombre()
    {
        return nombre;
    }

    public void setNombre(String nombre)
    {
        this.nombre = nombre;
    }

    public String getPassword()
    {
        return password;
    }

    public void setPassword(String password)
    {
        this.password = password;
    }

    public String getUsername()
    {
        return username;
    }

    public void setUsername(String username)
    {
        this.username = username;
    }
}

Lo primero que haremos es recordar cómo podemos obtener parámetros planos o simples desde nuestros formularios:

1. Recepción de parámetros simples

En el primer tutorial de la serie de Struts 2 vimos de una forma muy rápida cómo obtener parámetros de un formulario. Lo único que hay que hacer es:

Colocar un formulario en nuestra JSP usando la etiqueta <s:form>
Colocar los campos del formulario usando las etiquetas correspondientes de Struts
Crear un Action y colocar setters para cada uno de los elementos que recibiremos a través del formulario
Procesar los datos del formulario en el método "execute"

Hagamos un pequeño ejemplo para refrescar la memoria.

En este primer ejemplo obtendremos los datos para crear un nuevo objeto "Usuario", el tipo que definimos anteriormente.

Lo primero que hacemos es crear una nueva página JSP, en la raíz de las páginas web, llamada "nuevo-usuario.jsp". Hacemos clic derecho en el nodo "Web Pages". En el menú que se abre seleccionamos la opción "New –> JSP...".

Colocamos "nuevo-usuario" como nombre de la página y presionamos el botón "Finish".

En esta página indicamos que se usará la biblioteca de etiquetas de Struts 2:


<%@taglib uri="/struts-tags" prefix="s" %>

Usamos la etiqueta "<s:form>" para colocar un formulario en nuestra página. En su atributo "action" colocamos el nombre del Action que se encargará de procesar los datos de este formulario:


<s:form action="datosUsuario">            
</s:form>

Dentro de este formulario colocaremos un campo para cada uno de los atributos que puede recibir un Usuario:


<s:form action="datosUsuario">
    <s:textfield name="nombre" label="Nombre" />
    <s:textfield name="username" label="Username" />
    <s:password name="password" label="Password" />
    <s:textfield name="edad" label="Edad" />
    <s:textfield name="fechaNacimiento" label="Fecha de Nacimiento" />
    <s:submit value="Enviar" />
</s:form>

Ya que nuestro formulario está listo, crearemos el Action que se encargará de procesar los datos del mismo.

Creamos un nuevo paquete, llamado "actions", a la misma altura que el paquete "modelo". Dentro de este paquete creamos una nueva clase Java llamada "UsuarioAction". Haremos que esta clase extienda de "ActionSupport":


public class UsuarioAction extends ActionSupport
{    
}

Recuerden que para recibir los datos del formulario debemos colocar los atributos en los que se almacenarán estos datos, y setters para que los interceptores correspondientes puedan inyectar los valores dentro del Action:


public class UsuarioAction extends ActionSupport
{
    private String nombre;
    private String username;
    private String password;
    private int edad;
    private Date fechaNacimiento;

    public void setEdad(int edad)
    {
        this.edad = edad;
    }

    public void setFechaNacimiento(Date fechaNacimiento)
    {
        this.fechaNacimiento = fechaNacimiento;
    }

    public void setNombre(String nombre)
    {
        this.nombre = nombre;
    }

    public void setPassword(String password)
    {
        this.password = password;
    }

    public void setUsername(String username)
    {
        this.username = username;
    }
}

Cuando esté Action termine su ejecución (la cual aún no hemos implementado), queremos poder crear un Usuario y mostrar sus datos en otra página. Para hacer eso debemos colocar un atributo que almacene una referencia al Usuario, y un getter para poder obtener esta referencia:


private Usuario usuario;

public Usuario getUsuario()
{
    return usuario;
}

Ahora sí, sobre-escribimos el método "execute" para crear un nuevo objeto de tipo Usuario y establecer sus datos usando los valores que recibimos del formulario:


@Override
public String execute() throws Exception
{
    usuario = new Usuario();
    usuario.setNombre(nombre);
    usuario.setUsername(username);
    usuario.setPassword(password);
    usuario.setEdad(edad);
    usuario.setFechaNacimiento(fechaNacimiento);

    return SUCCESS;
}

Y eso es todo, ya hemos creado un nuevo Usuario con los datos que recibimos a través del formulario de captura.

Para que este ejemplo funcione aún tenemos que hacer un par de cosas. Primero marcaremos nuestra clase con la anotación "@Action" para indicar que esta clase debe ser tratada con un Action de Struts 2, como lo vimos en el primer tutorial de la serie:


@Namespace(value="/")
@Action(value="datosUsuario", results={@Result(name="success", location="/datos-usuario.jsp")})
public class UsuarioAction extends ActionSupport
{
}

Como podemos ver, el nombre de nuestro Action es "datosUsuario" (que es el mismo que colocamos en el atributo "action" del formulario que creamos hace un momento). Si todo el proceso de nuestro Action sale bien seremos enviados a la página "datosUsuario.jsp". Esta página solamente mostrará los datos del usuario que se acaba de crear. Antes de ver esta página veamos cómo queda la clase "UsuarioAction":


@Namespace(value="/")
@Action(value="datosUsuario", results={@Result(name="success", location="/datos-usuario.jsp")})
public class UsuarioAction extends ActionSupport
{
    private String nombre;
    private String username;
    private String password;
    private int edad;
    private Date fechaNacimiento;

    private Usuario usuario;

    @Override
    public String execute() throws Exception
    {
        usuario = new Usuario();
        usuario.setNombre(nombre);
        usuario.setUsername(username);
        usuario.setPassword(password);
        usuario.setEdad(edad);
        usuario.setFechaNacimiento(fechaNacimiento);

        return SUCCESS;
    }


    public Usuario getUsuario()
    {
        return usuario;
    }

    public void setEdad(int edad)
    {
        this.edad = edad;
    }

    public void setFechaNacimiento(Date fechaNacimiento)
    {
        this.fechaNacimiento = fechaNacimiento;
    }

    public void setNombre(String nombre)
    {
        this.nombre = nombre;
    }

    public void setPassword(String password)
    {
        this.password = password;
    }

    public void setUsername(String username)
    {
        this.username = username;
    }
}

Ahora sí, creamos una nueva página JSP; el nombre de esta página será "datos-usuario". En esta página haremos uso de algunas etiquetas de Struts, por lo que deberemos indicarlo usando la directiva "taglib" correspondiente:


<%@taglib uri="/struts-tags" prefix="s" %>

En esta página solamente mostraremos los datos del usuario que acabamos de crear. Recordemos que para esto debemos usar la etiqueta "<s:property>". Mostramos cada uno de los datos anteriores del usuario:


Nombre: <strong><s:property value="usuario.nombre" /></strong> <br />
Username: <strong><s:property value="usuario.username" /></strong> <br />
Password: <strong><s:property value="usuario.password" /></strong> <br />
Edad: <strong><s:property value="usuario.edad" /></strong> <br />
Fecha de Nacimiento: <strong><s:property value="usuario.fechaNacimiento" /></strong>

Cuando entremos a la siguiente página:


http://localhost:8080/formularios/nuevo-usuario.jsp

Veremos el formulario para capturar los datos del usuario. En mi caso, con los siguientes datos:

Obtengo la siguiente salida:

En el ejemplo anterior podemos ver que aunque hemos pasado pocos datos al formulario, todos los hemos establecido en el objeto "Usuario", que se creó dentro método "execute", y los pasamos "como van", es decir sin realizar ninguna transformación o procesamiento sobre ellos. Cuando tenemos 5 o 6 atributos esto puede no ser algo muy pesado. Pero ¿qué pasa si tenemos que llenar un objeto con 30 o 40 propiedades? Nuestro Action sería muy grande por todos los atributos y los setters y getters de las propiedades; el trabajo dentro del método "execute" también sería bastante cansado llamar a los setters de nuestro modelos para pasarle los parámetros.

Para esos casos Struts 2 proporciona una forma de simplificarnos estas situaciones usando un mecanismo conocido como "Model Driven" el cual veremos a continuación.

2. Model Driven

Model Driven es una forma que Struts 2 proporciona para poder establecer todos los parámetros que se reciben de un formulario directamente dentro de un objeto. Este objeto es conocido como el modelo.

Usando este modelo nos evitamos estar llamando nosotros mismos a los setters de este objeto modelo.

Esto también permite que si realizamos validaciones de datos del formulario (lo cual veremos cómo hacer un poco más adelante) estas se realizarán sobre este objeto modelo.

Un interceptor especial, llamado model driven interceptor, se encarga de manejar todo esto de forma automática ^_^.

Extenderemos nuestro ejemplo para usar model driven.

Creamos una nueva clase Java, en el paquete "actions", llamada "UsuarioActionMD". Esta clase extenderá de "ActionSupport":


public class UsuarioActionMD extends ActionSupport
{    
}

Para indicarle a Struts 2 que este Action será Model Driven, la clase "UsuarioActionMD" debe implementar la interface "ModelDriven", indicando de qué tipo de objeto será usado como modelo:


public class UsuarioActionMD extends ActionSupport implements ModelDriven<Usuario>
{
}

Ahora pondremos un objeto Usuario dentro de nuestra clase, con una variable de instancia, que será el objeto que usaremos como modelo:


public class UsuarioActionMD extends ActionSupport implements ModelDriven<Usuario>
{
    private Usuario usuario = new Usuario();    
}

Es importante tener creado este objeto antes de que nuestro Action reciba alguna petición, por lo que podemos inicializarlo en la misma declaración o en el constructor del Action, en caso de tener alguno.

La interface "ModelDriven" tiene tan solo un método: "getModel". Esté método no recibe ningún parámetro, y regresa el objeto que estamos usando como modelo:


public Usuario getModel()
{
    return usuario;
}

Lo único que queda es realizar algún proceso en el método "execute", que podría ser almacenar al Usuario en alguna base de datos, enviarlo por algún stream, etc. Como en este caso no haremos nada con el Usuario más que regresarlo para poder mostrar sus datos en una página, nuestro método "execute" solo regresará un valor de "SUCCESS".


@Override
public String execute() throws Exception
{
    return SUCCESS;
}

Noten que en esta ocasión no es necesario tener un getter para poder obtener la instancia del "Usuario" desde nuestra JSP.

Finalmente, anotamos nuestra clase para que Struts 2 lo reconozca como un Action. El nombre del Action será "datosUsuario". Para diferenciar este Action del anterior (que tiene el mismo nombre) lo colocaremos en el namespace "modeldriven".

El Action al terminar de ejecutarse nos enviará a la página "/modeldriven/datos-usuario.jsp":


@Namespace(value = "/modeldriven")
@Action(value="datosUsuario", results={@Result(location="/modeldriven/datos-usuario.jsp")})
public class UsuarioActionMD extends ActionSupport implements ModelDriven<Usuario>
{
}

La clase "UsuarioActionMD" completa (omitiendo los imports) queda de la siguiente forma:


@Namespace(value = "/modeldriven")
@Action(value="datosUsuario", results={@Result(location="/modeldriven/datos-usuario.jsp")})
public class UsuarioActionMD extends ActionSupport implements ModelDriven<Usuario>
{
    private Usuario usuario = new Usuario();

    public Usuario getModel()
    {
        return usuario;
    }

    @Override
    public String execute() throws Exception
    {
        return SUCCESS;
    }
}

Podemos ver que el código de este Action es mucho más pequeño que el que hicimos para el ejemplo anterior.

Ahora antes de crear la página que se encargará de mostrar el resutado, creamos un nuevo directorio para nuestras páginas web. Para eso hacemos clic derecho sobre el nodo "WebPages" de nuestro proyecto. En el menú que aparece seleccionamos la opción "New -> Folder":

Damos "modeldriven" como nombre del directorio y presionamos el botón "Finish".

Dentro de este directorio crearemos dos páginas. Primero crearemos la página que contendrá el formulario que nos permitirá capturar los datos del usuario. Hacemos clic derecho en el directorio "modeldriven" del nodo "Web Pages". En el menú que se abre seleccionamos la opción "New –> JSP...". Damos "nuevo-usuario" como nombre de la página y presionamos el botón "Finish".

El formulario de la página será idéntico al que creamos en la primer parte del tutorial, con la única diferencia de que enviará los datos al Action "datosUsuarioMD":


<s:form action="datosUsuario">
    <s:textfield name="nombre" label="Nombre" />
    <s:textfield name="username" label="Username" />
    <s:password name="password" label="Password" />
    <s:textfield name="edad" label="Edad" />
    <s:textfield name="fechaNacimiento" label="Fecha de Nacimiento" />
    <s:submit value="Enviar" />
</s:form>

La segunda página, que se llamará "datos-usuario.jsp" y que también estará en el directorio "modeldriven", mostrará los valores de los atributos del objeto "usuario" que se usa como modelo. Esta página también será muy parecida a la que creamos anteriormente, solo que en esta ocasión no será necesario indicar que los atributos que estamos usando corresponden al objeto "usuario":


Nombre: <strong><s:property value="nombre" /></strong> <br />
Username: <strong><s:property value="username" /></strong> <br />
Password: <strong><s:property value="password" /></strong> <br />
Edad: <strong><s:property value="edad" /></strong> <br />
Fecha de Nacimiento: <strong><s:property value="fechaNacimiento" /></strong>

Al ejecutar la aplicación y entrar en la siguiente dirección:


http://localhost:8080/formularios/modeldriven/nuevo-usuario.jsp

Veremos un formulario muy parecido al anterior:

Cuando llenemos los datos y enviemos el formulario, deberemos ver una salida también muy parecida a la anterior:

Pero ¿qué ocurre si queremos recibir un parámetro que no sea un atributo del "usuario"? En ese caso, solo tenemos que agregar un nuevo atributo, con su correspondiente setter para establecer su valor (y su getter si es que pensamos recuperarlo posteriormente) dentro de nuestro Action.

Modifiquemos un poco el ejemplo anterior para ver esto. Agregaremos al formulario un campo de texto para que el usuario proporcione un número de confirmación:


<s:form action="datosUsuario">
    <s:textfield name="nombre" label="Nombre" />
    <s:textfield name="username" label="Username" />
    <s:password name="password" label="Password" />
    <s:textfield name="edad" label="Edad" />
    <s:textfield name="fechaNacimiento" label="Fecha de Nacimiento" />
    <s:textfield name="numero" label="Número de Confirmación" />
            
    <s:submit value="Enviar" />
</s:form>

También cambiaremos nuestro Action. Colocamos un atributo de tipo entero para contener este número, junto con sus correspondientes setter (para establecer el valor desde el formulario) y getter (para obtener el valor desde la JSP):


private int numero;

public void setNumero(int numero)
{
    this.numero = numero;
}

public int getNumero()
{
    return numero;
}

De igual forma modificaremos la página "datos-usuarios.jsp" del directorio "modeldriven" para poder mostrar el valor del número de confirmación:


Nombre: <strong><s:property value="nombre" /></strong> <br />
Username: <strong><s:property value="username" /></strong> <br />
Password: <strong><s:property value="password" /></strong> <br />
Edad: <strong><s:property value="edad" /></strong> <br />
Fecha de Nacimiento: <strong><s:property value="fechaNacimiento" /></strong><br />
Número de confirmación: <strong><s:property value="numero" /></strong>

Al ejecutar la aplicación y entrar al formulario, veremos el campo que hemos agregado:

Al enviar los datos del formulario obtendremos la siguiente pantalla:

Ahora veremos cómo podemos hacer para recibir un conjunto de valores en un solo atributo de nuestro Action.

3. Recepción de múltiples parámetros

En los ejemplos anteriores cada uno de nuestros atributos recibe solo un valor de algún tipo. Sin embargo algunas veces nos será conveniente recibir un conjunto de parámetros, ya sea como un arreglo de valores, o como una lista de valores para poder procesar cada uno de sus elementos.

Esto es útil para cuando, por ejemplo, tenemos campos de formulario que se van generando dinámicamente, o que tienen el mismo significado en datos (por ejemplo cuando tenemos varios campos para cargar archivos adjuntos en correos electrónicos, o para poder subir varias imágenes de una vez a un sitio):

Poder obtener estos parámetros es sencillo gracias a los interceptores de Struts 2.

Veamos un ejemplo parecido a la pantalla anterior. Tendremos un formulario que nos permitirá recibir un conjunto de correos electrónicos de personas para ser procesados en el servidor. Colocaremos de forma estática 5 campos (claro que estos podrían ir aumentando de forma dinámica usando JavaScript).

Aunque el formulario tendrá 5 campos para correos, el usuario podría no llenarlos todos, por lo que no sabremos cuántos elementos estaremos recibiendo.

El formulario tendrá además un campo que permitirá que el usuario coloque su correo nombre, para saber quién está enviando los correos.

Comencemos primero con el formulario que mostrará los campos para los correos. Crearemos un nuevo directorio, en la raíz de las páginas web del proyecto, llamado "multidatos" (lo sé, no es un nombre muy original, pero refleja el cometido del ejemplo):

En este directorio crearemos una nueva JSP llamada "datos.jsp". Esta página contendrá el formulario con los 6 campos mencionados antes: un campo para que el usuario coloque su nombre, y 5 para colocar una dirección de correo electrónico:


<s:form action="envioCorreo">
    <s:textfield name="nombre" label="Nombre" />
    
    <s:textfield name="correo" label="Correo" />
    <s:textfield name="correo" label="Correo" />
    <s:textfield name="correo" label="Correo" />
    <s:textfield name="correo" label="Correo" />
    <s:textfield name="correo" label="Correo" />
            
    <s:submit value="Enviar" />
</s:form>

No olviden indicar que usaremos las etiquetas de Struts 2, con la directiva taglib correspondiente:


<%@taglib uri="/struts-tags" prefix="s" %>

Podemos ver en el formulario que los 5 campos para colocar los correos electrónicos son exactamente iguales, todos tienen por nombre "correo". Esto es necesario para podamos recibir los valores como un solo conjunto de datos.

Veamos el Action que recibirá estos valores. Primero crearemos una nueva clase java, llamada "MultiplesDatosAction", en el paquete "Actions". Esta clase extenderá de ActionSupport:


public class MultiplesDatosAction extends ActionSupport
{
}

Ahora colocaremos el atributo que nos permitirá recibir los múltiples parámetros. Para esto debemos colocar un arreglo del tipo de datos que estemos esperando. En este caso será un arreglo de Strings:


private String[] correos;

En realidad, ese es todo el secreto para poder recibir estos múltiples parámetros ^_^. Uno de los interceptores de Struts 2 se encargará de recibir los parámetros del formulario que tienen el mismo nombre; este interceptor colocará los parámetros en un arreglo o una colección, dependiendo de qué es lo que estemos esperando, y lo colocará en nuestro Action usando el setter apropiado.

Según la explicación anterior, debemos colocar el setter del atributo llamado "correos" para poder establecer el arreglo de correos, y su getter para poder obtenerlo posteriormente:


public String[] getCorreos()
{
    return correos;
}

public void setCorreos(String[] correos)
{
    this.correos = correos;
}

Ahora que tenemos el arreglo de valores colocaremos un atributo para mantener el nombre del usuario, con su correspondiente getter y setter:


private String nombre;

public String getNombre()
{
    return nombre;
}

public void setNombre(String nombre)
{
    this.nombre = nombre;
}

Como en esta ocasión no se realizará ningún proceso sobre los datos, por lo que nuestro método "execute" solo regresará un valor de "SUCCESS":


@Override
public String execute() throws Exception
{
    return SUCCESS;
}

Para terminar anotaremos esta clase. Primero indicamos que este Action estará en el namespace "multidatos". Además responderá al nombre de "envioCorreo" (el mismo que pusimos en el formulario). Al terminar el proceso, el Action nos enviará a una página llamada "datos-enviados.jsp" del directorio "multidatos":


@Namespace(value="/multidatos")
@Action(value="envioCorreo", results={@Result(location="/multidatos/datos-enviados.jsp")})
public class MultiplesDatosAction extends ActionSupport
{
}

El código completo de la clase "MultiplesDatosAction" queda de la siguiente forma:


@Namespace(value="/multidatos")
@Action(value="envioCorreo", results={@Result(location="/multidatos/datos-enviados.jsp")})
public class MultiplesDatosAction extends ActionSupport
{
    private String[] correos;
    private String nombre;

    @Override
    public String execute() throws Exception
    {
        return SUCCESS;
    }

    public String getNombre()
    {
        return nombre;
    }

    public void setNombre(String nombre)
    {
        this.nombre = nombre;
    }

    public String[] getCorreos()
    {
        return correos;
    }

    public void setCorreos(String[] correos)
    {
        this.correos = correos;
    }
}

Ahora solo falta crear la página a la que regresaremos al terminar el Action.

Creamos, en el directorio "multidatos" de las páginas web, una nueva JSP llamada "datos-enviados.jsp":

En esta página lo que haremos será mostrar los mismos datos que recibimos del formulario.

Recuerden que primero debemos indicar que usaremos las etiquetas de Struts 2, usando el taglib correspondiente:


<%@taglib uri="/struts-tags" prefix="s" %>

Primero mostraremos el valor del nombre del usuario, de la misma manera en la que hemos venido haciéndolo a lo largo de los ejemplos del tutorial:


<s:property value="nombre" />

Ahora mostraremos los valores de nuestro arreglo de cadenas, para eso Struts 2 proporciona una etiqueta especial que nos permite iterar a través de todos los valores de un arreglo o colección, la etiqueta "iterator".

La etiqueta "iterator" recibirá el arreglo o colección a través del cual ciclaremos para obtener sus valores. Indicamos este arreglo o colección usando el atributo "value". En este caso indicaremos que el valor a través del cual queremos iterar es arreglo llamado "correos":


<s:iterator value="correos">
</s:iterator>

Ya podemos ciclar a través de todos los elementos del arreglo, ahora necesitamos una manera de obtener el elemento actual dentro del ciclo. Para esto usamos el atributo "var", en este indicaremos el nombre de la variable que mantendrá el valor del elemento actual. No debemos de preocuparnos por crear esta variable, ya que Struts 2 la creara automáticamente y la pondrá a nuestra disposición. Esta variable será del tipo de elementos que sea mantenido por nuestro arreglo o colección:


<s:iterator value="correos" var="correo">
</s:iterator>

Algunas veces querremos poder obtener alguna información relativa a la iteración, como el índice del elemento actual, el número total de elementos que tiene el arreglo o colección, si el elemento actual es par o impar, etc. Para obtener esta información podemos indicarle a la etiqueta "iterator" que la coloque, como una instancia de la clase "IteratorStatus" y que la ponga a nuestra disposición en una variable. Para esto, indicamos el nombre de la variable en el atributo "status":


<s:iterator value="correos" var="correo" status="estatus">
</s:iterator>

El estatus es una variable que no será colocada dentro en la raíz del stack de Struts 2 (el cual explicamos en el segundo tutorial de la serie), por lo que es necesario hacer referencia a el usando el operador "#".

Ahora que podemos iterar a través de cada uno de los elementos de nuestro arreglo, solo hace falta mostrar el valor de cada uno de estos elementos, adicionalmente también mostraremos su índice. Colocaremos estos valores en una lista para que se vea más presentable:


<ul>
    <s:iterator value="correos" var="correo" status="estatus">
        <li><s:property value="#estatus.index" /> - <s:property value="correo" /></li>
    </s:iterator>
</ul>

Ahora, cuando coloquemos los siguientes datos en el formulario:

Obtendremos la siguiente salida:

Podemos ver que de una forma sencilla colocamos el conjunto de valores dentro del arreglo. Pero qué pasa si por alguna razón no podemos o no queremos usar un arreglo, y preferimos trabajar con una colección, como un Set o un List, lo único que tenemos que hacer es cambiar el tipo del atributo "correos" (junto con sus correspondientes getters y setters). Usemos un "Set", el cual es una colección que no permite elementos duplicados.

Modifiquemos el atributo "correos" para que quede de la siguiente forma:


private Set<String> correos;

public Set<String> getCorreos()
{
    return correos;
}

public void setCorreos(Set<String> correos)
{
    this.correos = correos;
}

Al introducir los siguientes datos en el formulario:

Obtendremos la siguiente salida:

Podemos ver que en realidad no fue necesario realizar grandes cambios para modificar la forma en la que recibimos los datos. Si quisiéramos que "correos" fuera una Lista, lo único que debemos hacer es, nuevamente, cambiar solo el tipo de dato.

El arreglo o la colección que usemos para mantener los valores, pueden ser de cualquier tipo de dato (cadenas, fechas, wrappers, archivos, etc).

Los ejemplos anteriores funcionan bien cuándo sabemos cuántos y cuáles serán los parámetros que estamos esperando recibir. Pero ¿y si no supiéramos de antemano los parámetros que recibiremos?

Como pueden imaginarse, Struts 2 proporciona una manera elegante de manejar estas situaciones.

4. Recepción de Parámetros Desconocidos

Algunas veces estamos esperando recibir, dentro de nuestro Action, un conjunto de parámetros de los cuales no conocemos ni su cantidad ni sus nombres, como por ejemplo cuando estamos haciendo un filtrado de datos y no sabes qué filtros recibiremos y cuáles serán los valores de estos filtros, o cuando la generación de componentes se realiza de forma dinámica.

Para estos casos Struts 2 proporciona una manera de indicar que deberá entregarnos todos los parámetros en un objeto tipo "java.util.Map". Las llaves de este mapa representarán los nombres de los parámetros, y sus valores representarán un arreglo de Strings con los valores correspondientes de cada parámetro. ¿Por qué un arreglo de Strings? Porque como acabamos de ver, algunos de los parámetros que recibimos pueden tener más de un valor.

Para lograr que Struts 2 nos proporcione estos parámetros, nuestro Action debe implementar la interface "ParameterAware". Esta interface se ve de la siguiente forma:


public interface ParameterAware
{
    void setParameters(Map<String, String[]> parameters);
}

O sea, que esta interface solo tiene un método llamado "setParameters", que tiene como argumento el mapa de parámetros recibidos en la petición.

Veamos un ejemplo para entender cómo funciona esta interface.

Primero crearemos un nuevo directorio, dentro de nuestras páginas web, llamado "multiparametros". Dentro de este directorio crearemos dos nuevas JSPs. La primera, llamada "datos.jsp" contendrá un pequeño formulario que nos permitirá enviar los parámetros dinámicos a nuestro Action. La segunda, llamada "parametros.jsp", mostrara el nombre y el valor de cada uno de los parámetros que hemos colocado en el formulario. Comencemos creando la pagina "datos.jsp".

Primero, indicaremos que haremos uso de las etiquetas de Struts 2 usando el taglib correspondiente:


<%@taglib prefix="s" uri="/struts-tags" %>

Ahora crearemos un formulario, de una forma un poco distinta a como lo hemos estado haciendo hasta ahora. Primero indicaremos, con la etiqueta "<s:form>" que haremos uso de un formulario, los datos del mismo serán procesados por un Action cuyo nombre será "multiparametros":


<s:form action="multiparametros">
</s:form>

Para que sea más claro entender un paso que haremos un poco más adelante, en vez de dejar que Struts 2 sea quien defina la estructura de nuestro formulario, lo haremos nosotros mismos. Para eso debemos indicar, en el atributo "theme" del formulario, el valor "simple":


<s:form action="multiparametros" theme="simple">
</s:form>

Ahora colocaremos un elemento en el formulario, un campo de entrada de texto usando el la etiqueta "<s:textfield>":


<s:form action="multiparametros" id="formulario" theme="simple">
    <s:textfield id="valor1" name="valor1" /> 
</s:form>

Como en esta ocasión no se colocará una etiqueta de forma automática en el campo de texto, deberemos ponerla nosotros mismos, usando la etiqueta "<s:label>", de la siguiente manera:


<s:form action="multiparametros" theme="simple">
    <s:label for="valor1" value="Valor 1: " />
    <s:textfield id="valor1" name="valor1" />
</s:form>

Como pueden ver hemos tenido que colocar un valor en el atributo "id" del textfield, y poner este mismo valor en el atributo "for" de la etiqueta "<s:label>".

Como estamos haciendo nosotros mismos el acomodo de los componentes, también debemos colocar un salto de línea entre los elementos del formulario; de lo contrario aparecerían todos en la misma línea. Para eso usamos la etiqueta "<br>":


<s:form action="multiparametros" theme="simple">
    <s:label for="valor1" value="Valor 1: " />
    <s:textfield id="valor1" name="valor1" /> <br /> 
</s:form>

El siguiente paso consiste en colocar el botón de envió del formulario, usando la etiqueta "<s:submit>":


<s:form action="multiparametros" theme="simple">
    <s:label for="valor1" value="Valor 1: " />
    <s:textfield id="valor1" name="valor1" /> <br /> 
    <s:submit value="Enviar" />    
</s:form>

Hasta ahora tenemos un formulario que se ve de la siguiente forma:

Podemos ver que tenemos un solo parámetro, sin embargo para el ejemplo necesitamos varios campos de texto. Haremos que estos se agreguen de forma dinámica usando una biblioteca de JavaScript: jQuery.

Colocaremos un botón que al presionarlo agregará un nuevo campo para introducir texto, junto con su etiqueta y salto de línea correspondiente.

El HTML del botón es el siguiente:


<button id="btnAgregar">Agregar Elemento</button>

Y el código de jQuery para agregar los elementos al formulario es el siguiente:


$(document).ready(function () 
{
    $("#btnAgregar").click(function() 
    {
        var num = $("input[type=text]").length;
        var numeroSiguiente = num + 1;
        var elementoNuevo = $("#valor" + num).clone().attr('id', 'valor'+numeroSiguiente).attr("name", "valor"+numeroSiguiente);
        var etiquetaNueva = $("label[for=valor"+num+"]").clone().attr("for", "valor"+numeroSiguiente).text("Valor " + numeroSiguiente + ": ");
                           
        $("#valor" + num).after(elementoNuevo);
        elementoNuevo.before(etiquetaNueva);
        etiquetaNueva.before("<br />");
    });
});

Como este no es un tutorial de jQuery no explicaré el código anterior ^_^. Pero el resultado es el siguiente:

Cada vez que presionemos el botón "Agregar Elemento" se agregará un nuevo campo de entrada, de la siguiente forma:

Ahora que tenemos un formulario pasemos a crear nuestro Action. Creamos una nueva clase Java, en el paquete "Actions". El nombre de esta clase será "MultiplesParametrosAction", extenderá de "ActionSupport" e implementará la interface "ParameterAware":


public class MultiplesParametrosAction extends ActionSupport implements ParameterAware
{
}

Debemos colocar una variable que nos permita almacenar la referencia al mapa que los interceptores inyectarán con la lista de parámetros recibidos:


private Map<String, String[]> parametros;

Además debemos implementar el método "setParameters" de la interface "ParameterAware":


public void setParameters(Map<String, String[]> parametros)
{
    this.parametros = parametros;
}

Adicionalmente pondremos un getter para el mapa de parámetros, para poder recuperarlo desde la JSP correspondiente:


public Map<String, String[]> getParametros()
{
    return parametros;
}

Nuestro método "execute" nuevamente será muy simple y solo regresara el valor "SUCESS":


@Override
public String execute() throws Exception
{   
    return SUCCESS;
}

El siguiente paso es anotar nuestra clase para convertirla en un Action. Las anotaciones (y la explicación) serán las mismas que hemos venido usando hasta ahora:


@Namespace(value="/multiparametros")
@Action(value="multiparametros", results={@Result(location="/multiparametros/parametros.jsp")})
public class MultiplesParametrosAction extends ActionSupport implements ParameterAware
{
}

La clase "MultiplesParametrosAction" completa queda de la siguiente forma:


@Namespace(value="/multiparametros")
@Action(value="multiparametros", results={@Result(location="/multiparametros/parametros.jsp")})
public class MultiplesParametrosAction extends ActionSupport implements ParameterAware
{
    private Map<String, String[]> parametros;
    
    public void setParameters(Map<String, String[]> parametros)
    {
        this.parametros = parametros;
    }

    public Map<String, String[]> getParametros()
    {
        return parametros;
    }
    
    @Override
    public String execute() throws Exception
    {   
        return SUCCESS;
    }
}

Finalmente debemos crear el contenido de la pagina "parametros.jsp". Nuevamente usaremos una etiqueta "<s:iterator>". En este caso en vez de pasarle una lista, le pasaremos el mapa con los parámetros que recibimos desde el Action, y nuevamente colocaremos una variable en donde se colocará el valor del elemento actual del ciclo:


<s:iterator value="parametros" var="parametro">
</s:iterator>

Como un Map tiene dos elementos importantes, la llave y el valor, debemos obtener cada uno de estos valores para mostrarlos en nuestra página. Para tener acceso a la llave usamos la propiedad "key" del elemento actual, y para obtener el valor, usamos la propiedad "value" la cual nos regresará el arreglo de cadenas asociado con el parámetro. Para obtener el primer valor de este parámetro debemos accederlo usando la sintaxis de los arreglos, como vimos en el segundo tutorial de la serie:


<s:iterator value="parametros" var="parametro">
    <s:property value="#parametro.key" />: <s:property value="#parametro.value[0]" />
</s:iterator>

Para que todo se vea más ordenado, colocaremos los resultados en una lista:


<ul>
    <s:iterator value="parametros" var="parametro">
        <li><s:property value="#parametro.key" />: <s:property value="#parametro.value[0]" /></li>
    </s:iterator>
</ul>

Ahora que ya tenemos el código listo ejecutemos la aplicación; cuando entremos a la dirección:


http://localhost:8080/formularios/multiparametros/datos.jsp

Veremos el formulario que creamos:

Si ingresamos los siguientes datos, y enviamos el formulario:

Veremos la siguiente salida:

Como podemos ver, aunque no tenemos ni idea del nombre o la cantidad de parámetros que recibiremos en la petición, Struts 2 aún nos proporciona una forma sencilla y elegante de manejarlos.

Hasta ahora hemos visto varias maneras de recibir parámetros desde nuestros formularios. Sin embargo otra parte muy importante del trabajo con estos últimos es el poder realizar algunas validaciones sobre los datos que recibimos. En la siguiente sección veremos cómo usar validaciones en nuestros formularios.

5. Validaciones

Una parte importante del trabajo con formularios es que podamos asegurarnos que la información de los mismos cumpla con ciertos requisitos para poder procesarlos. Por ejemplo que las direcciones de correo electrónico cumplan con el formato establecido, o que ciertos valores estén dentro de un rango valido, o simplemente que se estén proporcionando los campos obligatorios del formulario.

Hacer esto con Struts 2 es muy simple, ya que proporciona varias maneras de realizar validaciones de forma automática para los datos de nuestros formularios.

Las validaciones son realizadas por dos interceptores: "validation" y "workfllow". El primero realiza las validaciones y crea una lista de errores específicos para cada uno de los campos que no pase la validación. Posteriormente el interceptor "workflow" verifica si hay errores de validación; si encuentra algún error regresa un resultado "input", por lo que es necesario que proporcionemos un result con este nombre.

Struts 2 tiene básicamente tres formas de realizar validaciones:

Validaciones mediante un archivo XML
Validaciones mediante anotaciones
Validaciones manuales

Primero comencemos creando la estructura con los elementos que usaremos en las validaciones:

Lo primero que haremos será crear un nuevo directorio en las páginas web, llamado "validaciones". Dentro de este directorio crearemos una nueva JSP llamada "formulario.jsp":

Dentro de esta página crearemos un formulario sencillo que solicitará al usuario algunos datos básicos como nombre, correo electrónico, teléfono, etc. No olviden colocar en la JSP la directiva taglib correspondiente para indicar que esta hará uso de las bibliotecas de etiquetas de Struts. El formulario quedará, por el momento, de la siguiente forma:


<s:form action="validacionDatos">
    <s:textfield name="nombre" label="Nombe" />
    <s:textfield name="username" label="Username" />
    <s:password  name="password" label="Password" />
    <s:textfield name="email" label="Email" />
    <s:textfield name="edad" label="Edad" />
    <s:textfield name="telefono" label="Telefono" />
    <s:submit value="Enviar" />
</s:form>

Otra de las pequeñas ayudas que nos proporcionan las etiquetas de Struts 2 es que nos permiten indicar si cuáles campos son obligatorios, con lo que se le colocará una pequeña marca en la etiqueta para que el usuario sepa cuáles campos son los que está obligado a llenar. Esta marca es solo una ayuda visual, no realizará ningún proceso de validación del campo.

Para agregar dicha marca e indicar que el campo será obligatorio, debemos colocar el valor de "true" en el atributo "required" de las etiquetas del formulario. En este caso todos los campos, con excepción del teléfono, serán requeridos:


<s:form action="validacionDatos">
    <s:textfield name="nombre" label="Nombe" required="true" />
    <s:textfield name="username" label="Username" required="true" />
    <s:password  name="password" label="Password" required="true" />
    <s:textfield name="email" label="Email" required="true" />
    <s:textfield name="edad" label="Edad" required="true" />
    <s:textfield name="telefono" label="Telefono" />
    <s:submit value="Enviar" />
</s:form>

Con el código anterior obtenemos el siguiente formulario:

Debido al tema ("theme") que se usa por default para construir el formulario, los errores serán mostrados directamente sobre los campos que no pasen la validación. Sin embargo, si quisiéramos mostrar, de manera adicional, una lista con todos los errores del formulario, debemos agregar en nuestra JSP la etiqueta "<s:fielderror />". Solo la colocamos sobre el formulario, de la siguiente forma:


<s:fielderror />
        
<s:form Action="validacionDatos">
    <s:textfield name="nombre" label="Nombre" required="true" />
    <s:textfield name="username" label="Username" required="true" />
    <s:password  name="password" label="Password" required="true" />
    <s:textfield name="email" label="Email" required="true" />
    <s:textfield name="edad" label="Edad" required="true" />
    <s:textfield name="telefono" label="Telefono" />
    <s:submit value="Enviar" />
</s:form>

Ahora creamos el Action que se encargará de procesar los datos anteriores. Para eso creamos una nueva clase llamada "ValidacionDatos" en el paquete "Actions". Esta clase extenderá de "ActionSupport" y tendrá las anotaciones que para este momento ya deben sernos más que familiares:


@Namespace(value="/validaciones")
@Action(value="validacionDatos", results={@Result(location="/validaciones/alta-exitosa.jsp")})
public class ValidacionDatos extends ActionSupport
{
    
}

La clase "ValidacionDatos" tendrá setters y getters para cada uno de los valores que recibiremos del formulario. En este caso los getters son importantes por dos razones, la primera es que queremos que el formulario sea repoblado con los valores que el usuario ya habia introducido (los cuales solo pueden obtenerse a partir de los getters); la segunda es que, por alguna razón que no alcanzo a entender, las validaciones se realizan sobre los getters de las propiedades. La case "ValidacionDatos" hasta ahora se ve de la siguiente forma:


public class ValidacionDatos extends ActionSupport
{
    private String nombre;
    private String username;
    private String password;
    private String email;
    private int edad;
    private String telefono;

    public void setEdad(int edad)
    {
        this.edad = edad;
    }

    public void setEmail(String email)
    {
        this.email = email;
    }

    public void setNombre(String nombre)
    {
        this.nombre = nombre;
    }

    public void setPassword(String password)
    {
        this.password = password;
    }

    public void setTelefono(String telefono)
    {
        this.telefono = telefono;
    }

    public void setUsername(String username)
    {
        this.username = username;
    }

    public int getEdad()
    {
        return edad;
    }

    public String getEmail()
    {
        return email;
    }

    public String getNombre()
    {
        return nombre;
    }

    public String getPassword()
    {
        return password;
    }

    public String getTelefono()
    {
        return telefono;
    }

    public String getUsername()
    {
        return username;
    }
}

En su método "execute" esta clase solo se encargará de imprimir los valores que se han recibido a través del formulario:


@Override
public String execute() throws Exception
{
    System.out.println("nombre: " + nombre);
    System.out.println("username: " + username);
    System.out.println("password: " + password);
    System.out.println("email: " + email);
    System.out.println("edad: " + edad);
    System.out.println("telefono: " + telefono);
        
    return SUCCESS;
}

Ahora crearemos la página que se encargará de mostrar el resultado del alta de usuario. Para esto crearemos una JSP llamada "alta-exitosa.jsp" en el directorio "validaciones". Esta página será muy sencilla y solo mostrará el mensaje "Usuario dado de alta exitosamente."

Finalmente, recordemos que si existe un error de validación el interceptor correspondiente regresará un resultado con valor "input". Este resultado debe enviarnos a una página en la que se mostrará la lista de errores de datos de entrada. Normalmente esta página es el mismo formulario de entrada para que el usuario pueda corregir los datos que introdujo de forma incorrecta. Asi que modificaremos la anotación "@Action" de la clase "ValidacionDatos" para aregar un segundo resultado, que en caso de un error de entrada ("input") nos regrese al formulario:


@Action(value = "validacionDatos", results =
{
    @Result(location = "/validaciones/alta-exitosa.jsp"),
    @Result(name="input", location="/validaciones/formulario.jsp")
})

Como podemos ver, en este caso si es necesario indicar de forma explícita el nombre del result usando el atributo "name".

Al ejecutar nuestra aplicación y entrar en la siguiente dirección:


http://localhost:8080/formularios/validaciones/formulario.jsp

Deberemos ver el formulario que creamos hace un momento. Llenemos un par de campos para ver el resultado obtenido:

Al enviar los datos del formulario deberemos ver la siguiente salida:

Si analizamos la salida anterior veremos que esta no es correcta, ya que el usuario no ha proporcionado todos los datos requeridos, por lo que debería ver un mensaje de error. Solucionaremos esto agregando validaciones en los datos. Primero veremos cómo hacer validaciones usando archivos XML.

5.1 Validaciones usando archivos XML

Para realizar validaciones usando archivos en XML debemos crear un archivo por cada una de las clases que será validada. El nombre de este archivo debe seguir una convención muy sencilla:


<NombreDeNuestroAction>-validation.xml

O sea, que debe tener el mismo nombre del Action + la cadena "-validation" y la extensión ".xml". El archivo debe estar colocado en el mismo directorio que la clase Action que validará.

Dentro de este archivo se indicará cuáles campos serán validados y qué validaciones se le aplicarán. Cada una de estas validaciones tiene un parámetro obligatorio, que es el nombre del campo que validará. Adicionalmente pueden o no tener más parámetros.

Struts 2 ya viene con algunas validaciones predeterminadas que podemos usar, aunque también tenemos la posibilidad de crear nuestras propias validaciones en caso de ser necesario. Las validaciones incuidas con Struts 2 se muestran en la siguiente tabla:

Validador	Descripción
required	Verifica que el campo especificado no sea nulo.
requiredstring	Verifica que un campo de tipo String no sea nulo y que tenga un longitud mayor a 0.
stringlength	Verifica que una cadena tenga una cierta longitud.
int, long, y short	Verifica que el int, long, o short especificado estén dentro de un rango determinado.
double	Verifica que el valor double especificado esté dentro de cierto rango.
date	Verifica que la fecha proporcionada esté dentro del rango proporcionado. Por default se usa el formato Date.SHORT para indicar las fechas.
email	Verifica que el campo cumpla con el formato de una dirección de email válida
url	Verifica que el campo cumpla con el formato de una URL válida.
visitor	Permite enviar la validación a las propiedades del objeto del Action usando los propios de archivos de validación del objeto. Esto permite usar ModelDriven y administrar las validaciones de los objetos de modelo en un solo lugar.
conversion	Verifica si ocurre un error de conversión en el campo.
expression	Realiza una validación basada en una expresión regular en OGNL.
fieldexpression	Valida un campo usando una expresión OGNL.
regex	Valida un campo usando una expresión regular.

Sabiendo qué validadores podemos aplicar a los campos del formulario, pasemos a crear nuestro archivo de validación.

Creamos en el paquete "actions" un nuevo archivo XML llamado "ValidacionDatos-validation.xml":

Todas las validaciones deben estar contenidas dentro del elemento "<validators>":


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">
<validators>

</validators>

Lo siguiente es indicar cada campo que será validado usando el elemento "<field>", e indicamos el nombre del campo que queremos validar en su atributo "name":


<field name="nombre">
</field>

Posteriormente indicamos cada una de las validaciones que se aplicarán a ese campo, usando el elemento "<field-validator>" y su atributo "type":


<field name="nombre">
    <field-validator type="requiredstring">
            
    </field-validator>
</field>

Para agregar un parámetro a la validación usamos el elemento "<param>" y colocamos el nombre del parámetro en su atributo "name". En este caso usaremos el parámetro "trim" del validador "requiredstring" para indicar que deseamos que se eliminen los espacios en blanco del inicio y fin de la cadena (en caso de existir) antes de que la validación sea aplicada:


<field-validator type="requiredstring">
    <param name="trim">true</param>
</field-validator>

Para terminar, debemos agregar un mensaje que será mostrado en caso de que la validación no sea exitosa. Para esto usamos el elemento "<message>":


<field-validator type="requiredstring">
    <param name="trim">true</param>
    <message>El nombre del usuario es un campo obligatorio.</message>
</field-validator>

Y esto es todo, con esto el campo "nombre" del formulario ha quedado validado.

Si necesitáramos agregar más validaciones a este campo, solo bastaría con agregar un segundo elemento "<field-validator>". Agregamos un validador de tipo "stringlength" para asegurarnos que el nombre que introduzca el usuario tenga una longitud mínima de 4 caracteres, y una longitud máxima de 12. El proceso es básicamente el mismo por lo que no lo explicaré, pero al final la validación queda de la siguiente forma:


<field-validator type="stringlength">
    <param name="trim">true</param>
    <param name="minLength">4</param>
    <param name="maxLength">12</param>
    <message>El nombre del usuario debe tener entre 4 y 12 caracteres</message>
</field-validator>

Hasta ahora nuestro archivo de validaciones se ve de la siguiente forma:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">
<validators>
    <field name="nombre">
        <field-validator type="requiredstring">
            <param name="trim">true</param>
            <message>El nombre del usuario es un campo obligatorio.</message>
        </field-validator>
        
        <field-validator type="stringlength">
            <param name="trim">true</param>
            <param name="minLength">4</param>
            <param name="maxLength">12</param>
            <message>El nombre del usuario debe tener entre 4 y 12 caracteres</message>
        </field-validator>
    </field>
</validators>

El proceso es básicamente el mismo para todos los campos del formulario que vamos a validar. No explicaré cada una de las validaciones de los campos porque creo que la idea se entiende bastante en este momento, pero el archivo final de validaciones queda de la siguiente forma:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">
<validators>
    <field name="nombre">
        <field-validator type="requiredstring">
            <param name="trim">true</param>
            <message>El nombre del usuario es un campo obligatorio.</message>
        </field-validator>
        
        <field-validator type="stringlength">
            <param name="trim">true</param>
            <param name="minLength">4</param>
            <param name="maxLength">12</param>
            <message>El nombre del usuario debe tener entre 4 y 12 caracteres</message>
        </field-validator>
    </field>
    
    <field name="username">
        <field-validator type="requiredstring">
            <param name="trim">true</param>
            <message>El username es un campo obligatorio.</message>
        </field-validator>
        
        <field-validator type="stringlength">
            <param name="trim">true</param>
            <param name="minLength">6</param>
            <message>El username debe tener al menos 6 caracteres</message>
        </field-validator>
    </field>
    
    <field name="password">
        <field-validator type="requiredstring">
            <param name="trim">true</param>
            <message>La contraseña es un campo obligatorio.</message>
        </field-validator>
        
        <field-validator type="stringlength">
            <param name="trim">true</param>
            <param name="minLength">6</param>
            <param name="maxLength">8</param>
            <message>La contraseña debe tener entre 6  y 8 caracteres</message>
        </field-validator>
        
        <field-validator type="regex">
            <param name="expression">^\w*(?=\w*\d)(?=\w*[a-z])(?=\w*[A-Z])\w*$</param>
            <message>La contraseña debe ser alfanumérica, debe tener al menos una letra mayúscula, una letra minúscula, y al menos un número.</message>
        </field-validator>
    </field>
    
    <field name="email">
        <field-validator type="requiredstring">
            <param name="trim">true</param>
            <message>El correo electrónico es un campo obligatorio.</message>
        </field-validator>
        
        <field-validator type="email">
            <message>El correo electrónico está en un formato inválido.</message>
        </field-validator>
    </field>
    
    <field name="edad">
        <field-validator type="required">
            <message>La edad es un campo obligatorio.</message>
        </field-validator>

        <field-validator type="conversion">
            <message>La edad debe contener solo números enteros.</message>
        </field-validator>
        
        <field-validator type="int">
            <param name="min">0</param>
            <param name="max">200</param>
            <message>La edad proporcionada no está dentro del rango permitido.</message>
        </field-validator>
    </field>
    
</validators>

Ahora que todo está listo podemos ejecutar nuestra aplicación y entrar a la siguiente dirección:


http://localhost:8080/formularios/validaciones/formulario.jsp

Nuevamente veremos nuestro formulario anterior. Si no colocamos ningún valor en ningún campo y simplemente presionamos el botón "Enviar" veremos la siguiente lista de errores:

Podemos ver que estamos obteniendo los errores que definimos en el archivo de validaciones, con los mensajes correspondientes. Si observamos el código fuente de la pagina generada veremos que cada uno de los errores marcados está colocado en un elemento que tiene como clase CSS "errorMessage", por lo que podemos personalizar la forma en la que se muestran los errores de validación de la aplicación a través de una hoja de estilos.

Si ahora colocamos algunos valores incorrectos en los campos del formulario:

Obtendremos una lista distinta de errores:

Si ahora colocamos datos correctos:

Veremos la página correspondiente:

Por lo que los datos han sido validados correctamente.

A pesar de que la mayoría de las veces realizaremos validaciones como las anteriores, o sea validaciones sobre los campos de un formulario, algunas veces será necesario realizar validaciones que no son sobre los campos (llamadas validaciones planes).

Las validaciones planas son un tipo especial de validación que no está atada a un campo específico, como la validación de expresiones. Por ejemplo, agreguemos una validación extra que verifique que el "nombre" y el "username" no sean iguales.

Para agregar una validación plana en vez de usar el elemento "<field>" usamos el elemento "<validator>", que es muy similar a "<field-validator>", indicamos usando su atributo "type" el tipo de validación que se realizará; si la validación necesita algún parámetro lo agregamos con el elemento "<param>"; el mensaje que se mostrará en caso de que la validación no pase lo colocamos con el elemento "<message>".

La validación para verificar que el nombre del usuario y el username no sean iguales queda de la siguiente forma (pueden colocarla después de todas las validaciones "field"):


<validator type="expression">
    <param name="expression">!nombre.equals(username)</param>
    <message>El nombre de usuario y el username no deben ser iguales.</message>
</validator>

Como estas validaciones no son realizadas sobre ningún campo, sus mensajes de error no se mostrarán usando la etiqueta "<s:fielderror />", si queremos verlos en la JSP debemos usar la etiqueta "<s:actionerror />":


<s:fielderror />
<s:actionerror />

Ahora, si volvemos a ejecutar la aplicación e introducimos el mismo nombre de usuario y contraseña:

Y presionamos el botón enviar obtendremos el siguiente resultado:

Con lo que podemos comprobar que estas validaciones también funcionan correctamente.

Ahora que vimos cómo realizar validaciones usando archivos XML veamos cómo realizar esto mismo usando anotaciones.

5.2 Validaciones usando anotaciones

Realizar validaciones de los datos de un formulario usando anotaciones es un proceso muy simple. Modificaremos un poco la clase "ValidacionDatos" que creamos hace un momento (de hecho yo crearé una clase aparte para no modificar el código que ya teníamos).

Las anotaciones que podemos usar para realizar las validaciones se encuentran en el paquete "com.opensymphony.xwork2.validator.annotations", y tenemos las siguientes validaciones disponibles:

@ConversionErrorFieldValidator
@DateRangeFieldValidator
@DoubleRangeFieldValidator
@EmailValidator
@ExpressionValidator
@FieldExpressionValidator
@IntRangeFieldValidator
@RegexFieldValidator
@RequiredFieldValidator
@RequiredStringValidator
@StringLengthFieldValidator
@UrlValidator
@VisitorFieldValidator

Como podemos ver, existe una anotación por cada una de las validaciones que se tienen cuando trabajamos con los archivos XML; la explicación para cada una de las validaciones también es la misma que para el caso anterior.

Esta anotación puede ser colocada tanto en el setter como en el getter de la propiedad que queremos validar. También podemos usar varias validaciones para una misma propiedad.

Veamos un primer ejemplo validando el campo "nombre". En la clase "ValidacionDatos" primero verificaremos que el nombre del usuario no esté vacio cuando se reciba del fomulario, para esto usaremos la anotación "@RequiredStringValidator", yo la pondré en el setter de la propiedad:


@RequiredStringValidator    
public void setNombre(String nombre)
{
    this.nombre = nombre;
}

Todas las anotaciones de validaciones proporcionan una serie de atributos que nos permiten configurar el comportamiento de la validación. Casi en todos los casos lo único que tendremos que configurar es el mensaje que se mostrará en caso de que la validación no sea correcta. Para eso usamos el atributo "message":


@RequiredStringValidator(message = "El nombre de usuario es un campo obligatorio.")
public void setNombre(String nombre)
{
    this.nombre = nombre;
}

También validaremos que el nombre tenga una cierta longitud, o sea que sea mayor a cierto número de caracteres y menor a otro cierto número. Para eso usamos la anotación la anotación "@StringLengthFieldValidator" que colocamos justo debajo de la anotación anterior:


@RequiredStringValidator(message = "El nombre de usuario es un campo obligatorio.")
@StringLengthFieldValidator(minLength="4", maxLength="12", message="El nombre del usuario debe tener entre 4 y 12 caracteres")
public void setNombre(String nombre)
{
    this.nombre = nombre;
}

Haremos lo mismo para cada uno de los campos que necesitemos validar. Nuevamente, no explicaré cada una de las anotaciones ya que son bastante intuitivas, pero al final quedan de la siguiente forma:


@RequiredFieldValidator(message="La edad es un campo obligatorio.")
@ConversionErrorFieldValidator(message="La edad debe contener solo números enteros.")
@IntRangeFieldValidator(min="0", max="200", message="La edad proporcionada no está dentro del rango permitido.")
public void setEdad(int edad)
{
    this.edad = edad;
}

@RequiredStringValidator(message="El correo electrónico es un campo obligatorio.")
@EmailValidator(message="El correo electrónico está en un formato inválido.")
public void setEmail(String email)
{
    this.email = email;
}

@RequiredStringValidator(message = "El nombre de usuario es un campo obligatorio.")
@StringLengthFieldValidator(minLength = "4", maxLength = "12", message = "El nombre del usuario debe tener entre 4 y 12 caracteres")
public void setNombre(String nombre)
{
    this.nombre = nombre;
}

@RequiredStringValidator(message="La contraseña es un campo obligatorio.")
@StringLengthFieldValidator(minLength="6", maxLength="8", message="La contraseña debe tener entre 6  y 8 caracteres")
@RegexFieldValidator(expression="^\\w*(?=\\w*\\d)(?=\\w*[a-z])(?=\\w*[A-Z])\\w*$", message="La contraseña debe ser alfanumérica, debe tener al menos una letra mayúscula, una letra minúscula, y al menos un número.")
public void setPassword(String password)
{
    this.password = password;
}

public void setTelefono(String telefono)
{
    this.telefono = telefono;
}

@RequiredStringValidator(message="El username es un campo obligatorio.")
@StringLengthFieldValidator(minLength="6", message="El username debe tener al menos 6 caracteres")
public void setUsername(String username)
{
    this.username = username;
}

Probemos nuevamente que todo funcione correctamente. Al ejecutar la aplicación y entrar en nuestro formulario, en la siguiente dirección:


http://localhost:8080/formularios/validaciones/formulario.jsp

(Bueno, de hecho mi dirección es un poco distinto porque cree el contenido en una página alterna ^^) Debemos ver el formulario que ya teníamos anteriormente:

Al hacer clic en el botón "Enviar", con los campos vacios, obtendremos la siguiente salida:

Podemos ver que, hasta el momento, las validaciones han funcionado correctamente. Si colocamos algunos datos de forma equivocada:

Obtendremos la siguiente salida:

Si ahora, colocamos los datos de forma correcta:

Obtendremos la salida que estamos esperando:

Como podrán imaginar, todas las validaciones anteriores son validaciones de campos. Usando anotaciones también podemos realizar validaciones planas (las validaciones que no están relacionadas con algún campo del formulario). Solo que en este caso las validaciones planas se colocan directamente en el método "execute" del Action, usando una anotación especial: "@Validations". En los atributos de esta anotación podemos indicar cada una de las validaciones que se necesiten en la aplicación (campos requeridos, emails, urls, longitud de las cadenas, rango de enteros, fechas, etc.). En nuestro caso lo que nos interesa es realizar una validación sobre una expresión. Para esto usamos el atributo "expressions" de la anotación "@Validations":


@Override
@Validations(expressions={})
public String execute() throws Exception

En este atributo colocamos, usando la anotación "@ExpressionValidator", la expresión que será validada, en este caso queremos asegurarnos de que el nombre del usuario y su username no son iguales, por lo que la validación queda de la siguiente forma:


@ExpressionValidator(expression="!nombre.equals(username)", message="El nombre de usuario y el username no deben ser iguales.")

La anotación completa queda de la siguiente forma:


@Override
@Validations(expressions =
{
    @ExpressionValidator(expression = "!nombre.equals(username)", message = "El nombre de usuario y el username no deben ser iguales.")
})
public String execute() throws Exception

Cuando ejecutemos nuevamente la aplicación, poniendo el mismo nombre de usuario y contraseña:

Obtendremos el mensaje correspondiente de error:

Cuando coloquemos los datos correctos deberíamos dejar de ver mensajes de error.

Los dos tipos de validaciones que hemos visto nos permiten verificar que los datos que proporcionemos sean correctos, siempre y cuando conozcamos de antemano los valores, los rangos, o las reglas que los campos del formulario pueden tener pero ¿qué pasa si no conocemos estos valores? por ejemplo, en el caso de que debamos comparar un valor contra un registro de la base de datos o contra algún web service o alguna cosa más sofisticada, las validaciones anteriores nos servirán de poco.

Afortunadamente, para esos casos, Struts 2 nos permite realizar un tercer tipo de validación: las validaciones manuales.

5.3 Validaciones Manuales

Ya sé qué es lo que deben estar pensando: que las validaciones manuales son las que estamos acostumbrados a realizar, que no es un mecanismo automático que nos ayude a simplificar nuestro trabajo de validación de datos. Si es así, no están tan equivocados ^_^; bueno, más o menos.

Las validaciones manuales son aquellas que son tan particulares a nuestro proceso de negocio que estas no se pueden tomar de alguna plantilla, como los ejemplos que mencioné anteriormente.

Este tipo de validación, aunque las tenemos que realizar nosotros mismos, sigue siendo administrado por el framework. Para ello nos proporciona una interface llamada "Validateable", que proporciona únicamente un método:


public void validate();

Afortunadamente para nosotros, la clase "ActionSupport" implementa esta interface, por lo que lo unico que tenemos que hacer es sobre-escribirlo en nuestros Actions y, ayudados de algunos métodos auxiliares de la clase "ActionSupport", enviar los errores correspondientes en caso de que estos existan.

Para poder indicar si existe algún error en las validaciones nos ayudamos del método "addFieldError", en caso de que exista un error de la validación de un campo, y de "addActionError", en caso de existir un error que no esté relacionado con un campo.

"addFieldError" recibe dos parámetros, el primero es el nombre del campo que generó el error y el segundo es la descripción del error. "addActionError" recibe un solo parámetro que es la descripción del error.

Como se podrán imaginar, si existe algún error en un campo este se mostrará en el campo correspondiente del formulario y en la etiqueta "<s:fielderror />". Si existe un error de otro tipo este se mostrará en la etiqueta "<s:actionerror />".

Ahora que conocemos la teoría sobre las validaciones manuales pasemos verlas en la práctica. Para esto modificaremos las validaciones que ya tenemos en nuestra clase.

Lo primero que debemos hacer es sobre-escribir el método "validate":


@Override
public void validate()
{        
}

Las validaciones que realizaremos serán muy simples: si el username es "programadorjava" (supongamos que este fue un nombre que se trajo de la base de datos, para comprobar que no haya nombres repetidos) o el correo es "programadorjavablog@gmail.com" entonces no se le permitirá al usuario completar el registro:


@Override
public void validate()
{
    if("programadorjava".equals(username))
    {
        addFieldError("username", "El username seleccionado ya se encuentra ocupado, por favor seleccione otro.");
    }
    if("programadorjavablog@gmail.com".equals(email))
    {
        addFieldError("email", "El correo electrónico proporcionado ya ha sido registrado anteriormente.");
    }
}

El framework detectará de forma automática si hemos agregado algo a los campos de error, si es así regresará esta lista de errores a nuestro resultado "input", de lo contrario continuará con la ejecución del método "execute".

Si ejecutamos la aplicación y entramos a nuestro formulario, proporcionando alguno de los datos reservados y que son validados dentro del método "validate":

Veremos los mensajes de error que hemos establecido:

Podemos comprobar nuevamente que las validaciones han funcionado correctamente ^_^.

Como vemos, realizar validaciones usando Struts 2 es muy sencillo y puede ahorrarnos bastante tiempo que podemos dedicar a mejorar otros aspectos de nuestra aplicación.

Ahora veremos cómo realizar otro de los trabajos que normalmente hacemos al hacer uso de formularios, la carga de archivos desde el cliente al servidor:

6. Carga de archivos

Hacer carga o upload de archivos desde un cliente hacia nuestro servidor, ya sea para almacenarlos o para procesarlos, es una operación que no siempre es sencilla de realizar. Sin embargo Struts 2 cuenta con una manera que hace que lograr esto sea tan sencillo como el resto de las cosas que hasta ahora hemos aprendido.

Struts 2 proporciona el soporte para la carga de archivos conforme a la especificación de HTML, esto nos permite subir uno o varios archivos desde el cliente al servidor.

Cuando un archivo es cargado, este será almacenado en un directorio temporal por el interceptor correspondiente (fileUpload). El archivo deberá entonces ser procesado o movido a otra ubicación, por nuestro Action, ya que al terminar la petición el interceptor se encargará de eliminar este archivo temporal.

Veamos cómo realizar la carga de archivos con un ejemplo.

Lo primero que haremos será crear un nuevo directorio en las páginas web, llamado "carga". Dentro de este directorio crearemos una nueva JSP llamada "formulario.jsp":

Como hasta ahora, debemos indicar en la JSP que haremos uso de la biblioteca de etiquetas de Struts 2:


<%@taglib prefix="s" uri="/struts-tags" %>

Lo siguiente es crear un formulario. Este será un poco distinto a los que hemos creado hasta ahora. Lo primero es que los datos del formulario deben codificarse de una forma especial antes de que estos sean enviados al servidor. Afortunadamente es el navegador el que se encarga de hacer esta codificación, lo único que nosotros debemos hacer es indicar, usando el atributo "enctype" del formulario, cuál codificación será; cuando cargamos archivos estos deben ir codificados en "multipart/form-data".

Además los datos deben ser enviados por POST (en los formularios HTML el método por default para enviar datos es GET (por la URL), pero en Struts 2 por default se envían por POST (en el cuerpo del mensaje de la petición), así que no debemos agregarle ninguna cosa extra en este caso). El formulario, hasta ahora, se ve de la siguiente forma:


<s:form enctype="multipart/form-data">
</s:form>

Los archivos son cargados con un tipo de campo especial el cual es generado usado la etiqueta "<s:file />". Esta etiqueta funciona de la misma forma que las demás que hemos venido usando hasta el momento:


<s:form action="cargaArchivo" enctype="multipart/form-data">
    <s:file name="archivo" label="Archivo" />
</s:form>

En este caso he llamado a mi archivo "archivo" pero podría tener cualquier nombre, como "imagen", "reporte", "datos", etc.

Agregaré otro campo solo para que vemos que podemos subir archivos junto con datos "planos" del formulario:


<s:form action="cargaArchivo" enctype="multipart/form-data">
    <s:file name="archivo" label="Archivo" />
    <s:textfield name="autor" label="Autor" />
</s:form>

Terminaremos el formulario agregando un botón de envío de formulario y una etiqueta que nos mostrará cualquier error que pudiera ocurrir en el proceso de carga:


<s:actionerror />
<s:form action="cargaArchivo" enctype="multipart/form-data">
    <s:file name="archivo" label="Archivo" />
    <s:textfield name="autor" label="Autor" />
    <s:submit value="Enviar" />
</s:form>

Como ven, el formulario es tan sencillo como todos los que hemos estado haciendo a lo largo del tutorial.

Ahora crearemos el Action que se encargará de procesar los datos de este formulario, y que es donde se encuentra la parte interesante del ejemplo ^^.

Creamos una nueva clase en el paquete "actions" llamada "CargaArchivo". Esta clase extenderá de "ActionSupport":


public class CargaArchivo extends ActionSupport
{
}

Agregaremos una propiedad de tipo String para almacenar el nombre del autor:


public class CargaArchivo extends ActionSupport
{
    private String autor;
}

Ahora viene la parte importante, para poder obtener una referencia al archivo, debemos colocar, en nuestro Action, una propiedad de tipo "File":


public class CargaArchivo extends ActionSupport
{
    private String autor;
    private File archivo;
}

Con esto, cada vez que se cargue un archivo usando el formulario, la variable de tipo "File" que tenemos, hará referencia a este archivo. Lo que nos queda es agregar los respectivos setters para las dos propiedades anteriores:


public class CargaArchivo extends ActionSupport
{
    private String autor;
    private File archivo;

    public void setArchivo(File archivo)
    {
        this.archivo = archivo;
    }

    public void setAutor(String autor)
    {
        this.autor = autor;
    }
}

Ahora sobrecargaremos el método "execute" de nuestro Action para mover el archivo a ua nueva ubicación en nuestro sistema de archivos:


@Override
public String execute() throws Exception
{
    File nuevoArchivo = new File("/", archivo.getName());
    archivo.renameTo(nuevoArchivo);
        
    return SUCCESS;
}

Podemos ver que colocaremos el nuevo archivo en el directorio raíz del sistema operativo y que el nombre del archivo será el mismo que el del archivo que estamos subiendo.

Al terminar el proceso mostraremos un poco de información con respecto al archivo. La información del archivo se verá en la página que enviemos como resultado "SUCCESS", por lo que deberemos proporcionar los getters correspondientes para esta información; en este caso mostraremos el nombre del archivo y la ruta en la que queda almacenado:


public String getNombre()
{
    return archivo.getName();
}
    
public String getRuta()
{
    return archivo.getAbsolutePath();
}

Como ven estamos obteniendo la información directamente del objeto File que representa al archivo que estamos cargando.

Crearemos la página que mostrará los resultados por lo que en el directorio "carga" creamos una nueva JSP llamada "archivoCargado". Dentro de este archivo hacemos indicamos usando la directiva "taglib" que haremos uso de la biblioteca de etiquetas de Struts 2. Después, usando la etiqueta "<s:property>" mostraremos los dos valores de los atributos anteriores:


Nombre: <s:property value="nombre" /><br />
Ruta: <s:property value="ruta" />

Anotaremos este clase como ya sabemos hacerlo, para que el framework la trate como un Action:


@Namespace(value = "/carga")
@Action(value = "cargaArchivo", results =
{
    @Result(location = "/carga/archivoCargado.jsp"),
    @Result(name="input", location = "/carga/formulario.jsp")
}) 
public class CargaArchivo extends ActionSupport

Ya tenemos todo asi que procedemos a ejecutar la aplicación y a ingresar a la siguiente dirección:


http://localhost:8080/formularios/carga/formulario.jsp

Con lo que veremos el formulario que creamos:

Podemos ver que en el campo de tipo "file" que declaramos, existe un pequeño botón que dice "Examinar...". Al presionar este botón se abrirá un cuadro de dialogo que nos permitirá seleccionar un archivo; en mi caso seleccionaré una imagen al azar de mi biblioteca de imágenes:

Cuando presionemos el botón "Enviar" de nuestro formulario, veremos en la página resultante una salida similar a la siguiente:

Podemos notar antes que nada que el archivo que habíamos subido, llamado "logoJT.png", ahora se llama "upload_5829876d_132a34219c9__7ffb_00000000.tmp". Esto ocurre porque cuando enviamos un archivo usando un formulario, el archivo no viaja como tal por la red; son sus bytes los que son enviados (lo sé técnicamente sería lo mismo ya que un archivo es un conjunto de bytes), el interceptor "fileUpload" toma estos bytes y los coloca en un archivo nuevo al cual le coloca un nombre extraño.

Si observamos el directorio a donde hemos movido el archivo que habíamos obtenido notaremos que nuestro archivo efectivamente ha quedado ahí, pero con el nuevo nombre (y extensión) que le ha colocado el interceptor:

Podemos ver que no tenemos información del nombre original del archivo ni de su tipo de contenido. Como podemos imaginar, ambos son datos muy importantes que nos pueden servir en algún momento.

Afortunadamente para nosotros, Struts 2 proporciona una forma en la que podemos obtener esta información de una forma fácil y sencilla (como nos tiene mal acostumbrados este framework ^^).

Para obtener esta información debemos proporcionar dos atributos extra para el archivo (con sus correspondientes getters). El nombre de estos atributos (en realidad solo los setters, pero creo que es más fácil entender de esta forma) debe seguir una cierta convención si queremos que Struts 2 proporcione la información de manera correcta.

Para obtener el nombre original del archivo debemos proporcionar un atributo, de tipo String, cuyo identificador sea "<nombre_del_campo_del_archivo>FileName"; o sea que si el identificador del campo del archivo es "documento", el identificador del campo para el nombre del archivo debe ser "documentoFileName", si el identificador del campo es "miArchivo", el campo para el nombre debe ser "miArchivoFileName".

Para obtener el tipo de contenido del archivo, o sea el "content type", debemos hacer algo similar y proporcionar un campo cuyo nombre sea "<nombre_del_campo_del_archivo>ContentType". Los campos para estos dos datos, junto con sus setters, queda de la siguiente forma:


private String archivoFileName;
private String archivoContentType;

public void setArchivoContentType(String archivoContentType)
{
    this.archivoContentType = archivoContentType;
}

public void setArchivoFileName(String archivoFileName)
{
    this.archivoFileName = archivoFileName;
}

Ahora con estos datos podemos modificar un poco nuestro Action dejando el método "execute" de la siguiente forma:


public String execute() throws Exception
{
    File nuevoArchivo = new File("/", archivoFileName);
    archivo.renameTo(nuevoArchivo);
        
    return SUCCESS;
}

Ahora el nombre con el que guardaremos el archivo que recibimos, es el mismo nombre del archivo original.

Agregaremos también un getter para cada una de las propiedades que no hemos utilizado aún, o sea para "autor" y "archivoContentType" para poder leerlos desde la JSP del resultado:


public String getArchivoContentType()
{
    return archivoContentType;
}

public String getAutor()
{
    return autor;
}

Al final, nuestra clase "CargaArchivo" queda de la siguiente forma:


@Namespace(value = "/carga")
@Action(value = "cargaArchivo", results =
{
    @Result(location = "/carga/archivoCargado.jsp"),
    @Result(name="input", location = "/carga/formulario.jsp")
}) 
public class CargaArchivo extends ActionSupport
{
    private String autor;
    private File archivo;
    private String archivoFileName;
    private String archivoContentType;

    @Override
    public String execute() throws Exception
    {
        File nuevoArchivo = new File("/", archivoFileName);
        archivo.renameTo(nuevoArchivo);
        
        return SUCCESS;
    }

    public String getArchivoContentType()
    {
        return archivoContentType;
    }

    public String getAutor()
    {
        return autor;
    }

    
    public void setArchivoContentType(String archivoContentType)
    {
        this.archivoContentType = archivoContentType;
    }

    public void setArchivoFileName(String archivoFileName)
    {
        this.archivoFileName = archivoFileName;
    }

    public String getNombre()
    {
        return archivoFileName;
    }
    
    public String getRuta()
    {
        return archivo.getAbsolutePath();
    }
    
    public void setArchivo(File archivo)
    {
        this.archivo = archivo;
    }

    public void setAutor(String autor)
    {
        this.autor = autor;
    }
}

Debemos modificar ahora la JSP "archivoCargado" del directorio "carga" para que quede de la siguiente forma:


Nombre: <s:property value="nombre" /><br />
Ruta: <s:property value="ruta" /><br />
Autor: <s:property value="autor" /><br />
Content Type: <s:property value="archivoContentType" />

Con todos los datos que necesitamos. volvemos a ejecutar la aplicación, y debemos ver el mismo formulario de las últimas veces:

Subimos nuevamente nuestro archivo, y al presionar el botón "Enviar" deberemos ver la siguiente pantalla:

Como podemos observar, ahora se está indicando el nombre original de la imagen, y el tipo de archivo que se subió (que en este caso es "image/png"). Si vamos nuevamente al directorio raíz de nuestro sistema operativo veremos que ahora la imagen se ha almacenado de forma correcta, y podemos ver un preview de la misma:

Con lo que podemos comprobar que la carga se realizó de forma correcta ^_^.

Hagamos una segunda prueba, intentemos subir el siguiente archivo (como tip para lo que viene a continuación, fíjense en el tamaño del archivo).

Al tratar de enviar este archivo veremos que obtenemos... un mensaje de error:

Lo que el mensaje básicamente dice es que el tamaño de nuestro archivo excede el tamaño máximo de 2MB que Struts 2 tiene configurado por defecto. ¿Qué podemos hacer entonces para subir archivos que sean más grandes? Como deben estarse imaginando, Struts 2 proporciona una forma de configurar el tamaño máximo de los archivos que se pueden cargar, a través de una constante o a través de un parámetro del interceptor "fileUpload". Estos dos valores no son exactamente para lo mismo, pero lo explicaremos en su debido momento.

Primero veamos cómo establecer este valor como una constante.

Como recordarán, del primer tutorial de la serie, hay dos formas de definir las constantes de Struts 2, la primera es en el archivo "struts.xml" que normalmente usamos cuando realizamos una configuración con XML. El nombre de la constante que debemos definir es "struts.multipart.maxSize".

Esta variable quedaría de la siguiente forma en el archivo "struts.xml" si quisiéramos que el tamaño máximo del archivo fuera de 10MB:


<constant name="struts.multipart.maxSize" value="10485760" />

En donde el valor indica el peso máximo que puede tener el archivo el bytes (así es, leyeron bien: bytes). El valor es calculado de la siguiente forma:


10 * 1024 * 1024
//MB   KB   Bytes

Si no estamos usando un archivo de configuración, como es nuestro caso, la constante se define como un parámetro de inicialización en el filtro de Struts 2:


<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
    <init-param>
        <param-name>struts.multipart.maxSize</param-name>
        <param-value>5097152</param-value>
    </init-param>
</filter>

Si intentamos nuevamente subir nuestro archivo, veremos la siguiente salida:

Podemos ver que en esta ocasión logramos subir el archivo de forma correcta.

El utilizar la constante anterior modifica el límite del tamaño de los archivos en toda la aplicación. Esto es bueno si deseamos aumentar el límite en el tamaño de los archivos que se vaya a subir en cualquier formulario de la aplicación. ¿Pero qué pasaría si necesitáramos que en algún formulario particular el tamaño máximo de los archivos a subir fuera menor que en el resto de la aplicación? Para estos casos es que existe una forma para especificar un límite para un Action particular, estableciendo el parámetro "maximumSize" del interceptor "fileUpload" en el Action que queremos modificar.

Ojo con lo dicho anteriormente, esta segunda forma lo único que permite es hacer que el tamaño máximo para un Action particular sea menor que el resto de la aplicación, lo contrario (que el tamaño máximo para un Action sea mayor que para el resto de la aplicación) no se puede hacer.

Para personalizar el valor de este interceptor para un Action, cuando trabajamos con el archivo "struts.xml", usamos el elemento "<interceptor-ref>" para indicar qué interceptores son los que queremos aplicar a un Action particular y los valores de los parámetros de dichos interceptores. Por ejemplo, para el Action "cargaArchivo", si estuviéramos trabajando con un el archivo "struts.xml" quedaría de la siguiente forma para que el tamaño máximo de un archivo sea de 2MB (2* 1024 * 1024):


<action name="cargaArchivo" class="com.javatutoriales.struts2.formularios.actions.CargaArchivo">
    <interceptor-ref name="fileUpload">
        <param name="maximumSize">2097152</param>
    </interceptor-ref> 
    <interceptor-ref name="defaultStack"/>

    <result>/carga/archivoCargado.jsp</result>
    <result name="input">/carga/formulario.jsp</result>

</action>

Para cuando trabajamos con anotaciones la configuración queda de la siguiente forma:


@InterceptorRefs(value =
{
    @InterceptorRef(value = "fileUpload", params =
    {
        "maximumSize", "2097152"
    }),
    @InterceptorRef(value = "defaultStack")
})

Como de esta forma lo que hacemos es indicar los interceptores que se le aplicarán a este Action, debemos decir que además del interceptor "fileUpload" queremos aplicar el resto de los interceptores que se aplican normalmente a un Action y que se encuentran en el "defaultStack", como explicamos en el primer tutorial de la serie.

Si intentamos subir nuevamente nuestro archivo obtendremos el siguiente mensaje de error:

Podemos ver que este mensaje es ligeramente distinto al que habíamos obtenido anteriormente, pero nos sirve para comprobar que efectivamente el límite se ha modificado.

Si estamos realizando la carga de varios archivos, el tamaño máximo será el de la suma del tamaño de todos los archivos, y no de cada archivo individual. Además el tamaño máximo de archivos que el framework soporta, según la documentación oficial, es de 2GB.

Adicionalmente a restringir el tamaño máximo de los archivos que podemos cargar, Struts 2 nos permite limitar también el tipo (content-type) de los archivos que se cargarán, estableciendo el parámetro "allowedTypes" del interceptor "fileUpload". Supongamos que para el Action anterior, solo queremos permitir que se carguen archivos de imagen en formato "png". Para lograr esto debemos configurar el interceptor "fileUpload" para nuestro Action de la siguiente forma:

Si usamos el archivo "struts.xml":


<action name="cargaArchivo" class="com.javatutoriales.struts2.formularios.actions.CargaArchivo">
    <interceptor-ref name="fileUpload">
        <param name="maximumSize">2097152</param>
        <param name="allowedTypes">image/png</param>
    </interceptor-ref> 
    <interceptor-ref name="defaultStack"/>

    <result>/carga/archivoCargado.jsp</result>
    <result name="input">/carga/formulario.jsp</result>

</action>

Si usamos anotaciones:


@InterceptorRefs(value =
{
    @InterceptorRef(value = "fileUpload", params =
    {
        "maximumSize", "2097152", "allowedTypes","image/png"
    }),
    @InterceptorRef(value = "defaultStack")
})

Al intentar subir cualquier archivo que no sea una imagen en formato png, obtendremos el siguiente error:

Podemos indicar varios formatos permitidos separando cada elemento con comas, por ejemplo:


"image/jpg, image/png, image/ico"

Para terminar de hablar de carga de archivos debemos saber cómo personalizar los mensajes de error que se generan al cargar archivos. Los mensajes que vimos anteriormente, aunque bastante claros tal vez no sean los que querremos que nuestros usuarios finales vean en la aplicación. Para personalizar estos mensajes tenemos tres llaves que nos permiten indicar los mensajes que queremos mostrar en cada caso. Estas llaves son:

struts.messages.error.uploading - Un error general que ocurre y que impide subir un archivo
struts.messages.error.file.too.large - Ocurre cuando un archivo cargado es más grande que el tamaño máximo especificado
struts.messages.error.content.type.not.allowed - Ocurre cuando el archivo cargado no es del tipo permitido (content-type) para la carga

Estas llaves debemos colocarlas en un archivo de propiedades que contendrá los mensajes de error de la aplicación. Para crear este archivo hacemos clic derecho sobre el nodo "Source Package" del panel de proyectos. En el menú contextual que aparece seleccionamos la opción "New -> Properties File..." (si no tienen esa opción en el menú, seleccionen la opción "Other..." y en la ventana que se abre seleccionen la categoría "Other" y el tipo de archivo "Properties File"):

Llamaremos a este archivo "struts-mensajes" (el IDE se encargará de colocar automáticamente la extensión .properties). Damos clic en el botón "Finish" y veremos aparecer en el editor nuestro archivo de propiedades. En este archivo colocaremos los textos que los usuarios verán en caso de que ocurra algún error, por ejemplo podemos poner:


struts.messages.error.file.too.large=El archivo proporcionado supera el tamaño máximo
struts.messages.error.content.type.not.allowed=El archivo proporcionado no es del tipo adecuado

Ya que tenemos definidos los mensajes, lo siguiente que debemos hacer es indicarle a Struts 2 dónde se localiza este archivo. Para ello (si, adivinaron) usamos una constante para indicar el nombre del archivo (el cual será buscado a partir del directorio raíz de los paquetes de la aplicación, o sea en el nodo "Source Packages". La constante que usamos es "struts.custom.i18n.resources", y como ya hemos visto, podemos colocarle en el archivo "struts.xml" de la sigueinte forma:


<constant name="struts.custom.i18n.resources" value="struts-mensajes" />

O como un parámetro de inicialización en el filtro de struts:


<filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
    <init-param>
        <param-name>struts.custom.i18n.resources</param-name>
        <param-value>struts-mensajes</param-value>
    </init-param>
</filter>

Cuando volvamos a ejecutar la aplicación veremos los siguientes mensajes de error:

Esto ya está mejor, ya que podemos colocar un texto tan descriptivo como queramos, sin embargo ahora hemos perdido algo de información importante que los otros mensajes nos daban, como el nombre del archivo que estamos subiendo, y algunos parámetros particulares para cada error.

Afortunadamente una vez más Struts 2 nos da una solución a esto ya que dentro de los mensajes podemos colocar algo llamado "placeholders" o contenedores, que básicamente es un espacio en nuestro mensaje donde Struts 2 se encargará de colocar un parámetro. Los parámetros que proporciona cada tipo de error son:

- 0 - Nombre del parámetro que causó el error (en nuestro ejemplo "archivo")
- 1 - Nombre del archivo que causó el error
- 2 - Nombre del archivo en el servidor (el archivo temporal creado por el interceptor)
- 3 - Tamaño del archivo cargado
- 0 - Nombre del parámetro que causó el error (en nuestro ejemplo "archivo")
- 1 - Nombre del archivo que causó el error
- 2 - Nombre del archivo en el servidor (el archivo temporal creado por el interceptor)
- 3 - Content-type del archivo cargado

Como podemos ver, en ambos casos los parámetros son prácticamente los mismos.

Podemos modificar los mensajes anteriores para que queden de la siguiente forma:


struts.messages.error.file.too.large=El archivo "{1}" supera el tamaño máximo permitido 2097152 bytes (2MB). El tamaño de su archivo es de {3} bytes
struts.messages.error.content.type.not.allowed=El archivo "{1}" no es de un tipo permitido (image/png). Su archivo es de tipo "{3}"

Con lo que obtendríamos los siguientes mensajes de error:

Que ya son mucho más claros para nuestros usuarios finales ^_^.

Como una nota final sobre la carga de archivos debemos decir que existe una constante más, "struts.multipart.saveDir", que podemos usar para indicar dónde queremos que se guarden los archivos temporales de las cargas que genera Struts 2. El uso de esta variable sale del propósito de este tutorial ^_^.

Ahora que hemos hablado bastante de la carga de archivos, pasemos al último tema del tutorial. Veamos como envías archivos desde nuestro servidor a los clientes usando Struts 2:

7. Descarga de Archivos

El poder enviar información binaria o archivos a los usuarios, aunque no es estrictamente parte del trabajo con formularios, es también una parte importante del desarrollo de aplicaciones web ya que tiene muchas aplicaciones prácticas como el enviar un reporte que generamos de forma dinámica, o un archivo que tengamos almacenado en algún lugar, como una base de datos o un directorio externo de la aplicación, o también mostrar imagenes que se hayan cargado o generado de forma dinámica en el sistema.

El realizar la descarga o envío de archivos es una tarea muy simple de hacer cuando trabajamos con Struts 2, ya que nos proporciona un tipo de resultado especial que permite enviar bytes directamente al "ServletOutputStream" del "HttpServletResponse".

Dedicaremos un tutorial completo a hablar de tipos de resultados, así que no entraré en muchos detalles de cómo funcionan estos, pero debemos saber que existen varios tipos de resultados, cada uno de los cuales altera de alguna forma la respuesta que enviamos al cliente. Podemos establecer algunos parámetros para indicar alguna información a nuestro result, entre otras cosas.

El result que nos ayudará en este caso es llamado "Stream Result", y básicamente es un result que permite enviar un flujo de bytes al cliente. Los parámetros que acepta este result son:

contentType: El tipo de contenido que se está enviando al usuario, por default es "text/plain"
contentLength: En número de bytes que se le enviarán al usuario (el navegador lo usa para mostrar de forma correcta una barra de progreso).
contentDisposition: Establece la cabecera "content disposition" que especifica el nombre del archivo, por lo regular ponemos algo como "attachment;filename="documento.pdf"" que muestra un cuadro de dialogo para guardar el documento, su valor por default es "inline" que nos muestra el documento en el mismo navegador
inputName: El nombre del "InputStream" que tiene los bytes del archivo que enviaremos al usuario (quedará más claro con el ejemplo), por default es "inputStream"
bufferSize: El tamaño del buffer que se usa para del flujo de entrada al de salida, por default es "1024"
allowCaching: Indica si el archivo debe ser guardado en caché por el cliente, por default es "true"
contentCharSet: El tipo de caracteres que tiene el contenido que enviamos al archivo, no tiene valor por default y si no lo establecemos no pasa nada ^_^.

Todos los atributos anteriores son opcionales, y por lo regular solo establecemos dos o tres.

Veremos tres ejemplos de este tipo de result.

Lo primero que haremos es crear un nuevo directorio, dentro de las páginas, llamado "descarga":

Para el primer ejemplo tomaremos un archivo que se encuentra en un directorio de nuestra aplicación y se lo enviaremos al usuario. Pueden tomar cualquier archivo que les guste, de preferencia alguno que puedan ver en el navegador como unPDF. Yo tomaré un archivo al azar de mi máquina y lo colocaré en el directorio raíz de la aplicación web, o sea en el directorio "web" de la aplicación que estamos desarrollando:

Abriré este archivo solo para ver el contenido y que cuando lo descarguemos podamos ver que es el mismo:

Ahora crearemos una nueva clase llamada "MuestraArchivo", en el paquete "actions". Esta clase extenderá de "ActionSupport":


public class MuestraArchivo extends ActionSupport
{
}

Lo primero que debemos hacer es colocar en nuestro Action un atributo de tipo "java.io.InputStream". Esta variable contendrá los bytes del archivo que se le enviará al cliente. Existen muchas formas de obtener una referencia a un "InputStream" de manera que solo tengamos que indicar la fuente donde está el archivo, y alguna clase especial se encargue del resto. En el peor de los casos tendremos que obtener estos bytes uno a uno y colocarlos en un objeto especial, pero tampoco es tan complicado; nosotros usaremos las dos formas en distintos ejemplos.

Si le damos a esta variable el nombre de "inputStream" no tendremos que declarar nada más en la configuración del result. Como es lo más fácil para el momento, lo haremos así y agregaremos el correspondiente getter de la propiedad:


public class MuestraArchivo extends ActionSupport
{
    private InputStream inputStream;

    public InputStream getInputStream()
    {
        return inputStream;
    }
}

Ahora sobre-escribiremos el método "execute" para poder obtener un flujo de lectura ("InputStream") a un archivo, usando una clase especial, un "FileInputStream". Para obtener este flujo lo único que debemos saber es la ubicación del archivo. Aquí hay que hacer un paréntesis para explicar un poco cómo se obtienen las rutas dentro de nuestra aplicación cuando estamos trabajando con aplicaciones web.

Dentro de la especificación de Servlets y JSPs se indica que cuando se hace la instalación o deploy de una aplicación web en un servidor (más específicamente en un contenedor de Servlets y JSPs) este debe quedar en un directorio de la máquina donde está instalado el servidor. ¿En cuál directorio?... esa es la cuestión interesante.

En la especificación no se indica dónde debe quedar cada aplicación que despleguemos, así que una vez instalada la aplicación, no podemos estar seguros de en dónde se encuentra físicamente dentro del servidor, por lo tanto si quisiéramos simplemente leer un archivo de nuestra aplicación no podríamos hacerlo ya que no sabríamos que ruta indicar; y todo esto en nuestro servidor local, si hiciéramos la instalación en un servidor remoto, rentado, o del cliente, sería aún peor ya que tal vez ni siquiera sabríamos el sistema operativo del mismo.

Para remediar esto, la especificación también proporciona una forma de obtener la ruta a cualquier recurso de nuestra aplicación. Para hacer esto debemos obtener una referencia al "ServletContext" de la aplicación y luego usar su método "getRealPath" indicando el recurso que del cual queremos obtener la ruta, iniciando desde la raíz de la aplicación (lo que vendría siendo el directorio "web" en NetBeans).

Ahora bien, como estamos usando un framework que se encarga de ocultar algunos detalles de la implementación web de la aplicación (como todo buen framework), no podemos obtener de una forma directa el "ServletContext" ya que no tenemos ninguna referencia a la interface de Servlets dentro de nuestros Actions.

Para remediar esto, Struts 2 nos proporciona una clase auxiliar que ayuda a obtener la referencia al "ServletContext" de una forma sencilla (de hecho también podemos obtener la referencia al "HttpServletRequest" y al "HttpServletResponse"). Esta clase es "ServletActionContext", y tiene una serie de métodos estáticos que permiten obtener referencias a los objetos anteriores.

Después de toda esa explicación, espero que quede claro el siguiente paso dentro de nuestro ejemplo.

Ya tenemos declarada una instancia de "InputStream" y hemos colocado un archivo .pdf, llamado "Ingenieria de software", en la raíz de la aplicación web, ahora crearemos un flujo de entrada para leer ese archivo y así enviarlo al cliente. Hacerlo en realidad es más fácil que decirlo, ya que Java proporciona una clase llamada "FileInputStream" que hace todo esto de forma automática, lo único que debemos hacer es indicarle la ruta en la que está almacenado nuestro archivo, de la siguiente forma:


@Override
public String execute() throws Exception
{
    String ruta = ServletActionContext.getServletContext().getRealPath("/Ingenieria de software.pdf");

    inputStream = new FileInputStream(ruta);

    return SUCCESS;
}

Esto es todo lo que debemos hacer para poder enviar el archivo al usuario, el framework se encargará de hacer el resto.

El paso final en este Action es colocar las anotaciones, que en este momento ya debemos conocer de memoria, para indicarle a Struts 2 que debe tratar esta clase como un Action. Primero que nada indicamos el namespace en el que se colocará al Action, y se le dará un nombre al mismo:


@Namespace(value = "/descarga")
@Action(value = "muestraArchivo)
public class MuestraArchivo extends ActionSupport

Lo siguiente es indicar el resultado de la ejecución de esté Action, la respuesta que será enviada al cliente, para lo cual usamos el atributo "results" y la anotación "@Result". En esta ocasión, como estamos usando un tipo distinto de result, debemos indicarlo dentro de la anotación usando su atributo "type". En este caso debemos indicar que el result es de tipo "stream" o flujo de bytes, de la siguiente forma:


@Namespace(value = "/descarga")
@Action(value = "muestraArchivo", results =
{
    @Result(type = "stream")
})
public class MuestraArchivo extends ActionSupport

El último paso es establecer alguno de los parámetros en el result, para eso usamos el atributo "params" de esta anotación. Este atributo recibe como argumento un arreglo de cadenas, donde los elementos nones representan el nombre del argumento que se quiere establecer, y los pares representan el valor de dicho argumento. En este ejemplo solo usaré el atributo "contentType" para indicar que el tipo de archivo que regresaré al usuario es un archivo pdf ("application/pdf"). Si están usando un archivo de algún otro tipo, una búsqueda rápida en Google les dará el tipo de contenido de su archivo:


@Namespace(value = "/descarga")
@Action(value = "muestraArchivo", results =
{
    @Result(type = "stream", params =
    {
        "contentType", "application/pdf"
    })
})
public class MuestraArchivo extends ActionSupport

Nuestra clase "MuestraArchivo" queda de la siguiente forma:


@Namespace(value = "/descarga")
@Action(value = "muestraArchivo", results =
{
    @Result(type = "stream", params =
    {
        "contentType", "application/pdf"
    })
})
public class MuestraArchivo extends ActionSupport
{
    private InputStream inputStream;

    @Override
    public String execute() throws Exception
    {
        String ruta = ServletActionContext.getServletContext().getRealPath("/Ingenieria de software.pdf");

        inputStream = new FileInputStream(ruta);

        return SUCCESS;
    }

    public InputStream getInputStream()
    {
        return inputStream;
    }
}

Si estuviéramos trabajando con archivos de configuración, el Action quedaría de la siguiente forma:


<action name="muestraArchivo" class="com.javatutoriales.struts2.formularios.actions.MuestraArchivo ">
    <result type="stream">
        <param name="contentType">application/pdf</param>
    </result>
</action>

Para este tipo de result, hablando estrictamente, no se necesita una página para mostrarlo, basta con colocar el nombre del Action en la barra de direcciones del navegador; nosotros crearemos una solo para ver cómo podemos invocarlos. Dentro del directorio "descarga" de las páginas web del proyecto creamos una nueva JSP llamada "archivo". Dentro de esta JSP, indicamos que haremos uso de la biblioteca de etiquetas de Struts 2, con la directiva "taglib" correspondiente:


<%@taglib prefix="s" uri="/struts-tags" %>

Ahora usaremos la etiqueta "<s:a>" para crear un enlace a nuestro Action. Esta etiqueta es smuy fácil de utilizar, solo hay que indicar el nombre del Action, en su atributo "action", su namespace, en su atributo "namespace", junto con el texto que tendrá el enlace, de la siguiente forma:


<s:a action="muestraArchivo" namespace="/descarga">Ver archivo</s:a>

Ahora que está todo listo, ejecutamos nuestra aplicación e ingresamos a la siguiente dirección:


http://localhost:8080/formularios/descarga/archivo.jsp

Con lo que debemos ver la siguiente página:

Lo único que tiene esta página es un enlace a nuestro Action, cuando entramos en la misma deberemos ver el siguiente resultado:

Como podemos ver, el documento se ha incrustado en nuestro navegador, por lo que nuestro primer ejemplo ha funcionado de forma correcta ^_^.

En el ejemplo anterior, el archivo que se envío al usuario se mostró dentro del mismo navegador. Esto nos sirve con ciertos tipos de archivos y bajo ciertas circunstancias, pero no siempre querremos que el usuario vea los archivos en su navegador, algunas veces querremos que sea forzoso que los descargue a su computadora.

En nuestro segundo ejemplo veremos cómo hacer este cambio. Afortunadamente es algo muy sencillo de hacer, basta con agregar otro parámetro, "contentDisposition", a nuestro result. "contentDisposition", como pueden ver en la lista anterior de parámetros, especifica cómo será enviado este archivo al cliente, si "inline" (para mostrarse en el navegador) o "attachment" (para que el archivo sea descargado en la máquina del cliente). Ambas opciones nos permiten indicar un "filename" que es el nombre que tendrá el archivo al ser enviado.

Como el código del Action que se necesita para hacer este ejemplo, es muy parecido al anterior, crearé una nueva clase llamada "DescargaArchivo" y copiaré el código anterior.

Agregaremos este parámetro a nuestro result, y como nombre del archivo colocaremos simplemente "tutorial.pdf":


@Namespace(value = "/descarga")
@Action(value = "descargaArchivo", results =
{
    @Result(type = "stream", params =
    {
        "contentType", "application/pdf",    
        "contentDisposition","attachment;filename=\"tutorial.pdf\""
    })
})

Con archivos XML quedaría de la siguiente forma:


<result type="stream">
    <param name="contentType">application/pdf</param>
    <param name="contentDisposition">attachment;filename="tutorial.pdf"</param>
</result>

Agregamos la liga correspondiente a este nuevo Action en la página "archivo.jsp":


<s:a action="descargaArchivo" namespace="/descarga">Descargar archivo</s:a>

Con este simple cambio, al volver a ejecutar nuestra aplicación y entrar en nuestro Action, ahora en lugar de ver el documento en pantalla veremos el cuadro de diálogo del navegador que nos pregunta qué queremos hacer con el archivo:

Podemos ver en la imagen anterior, que el nombre que tendrá el archivo es el mismo nombre que estamos regresando como el "filename". En esta ocasión hemos puesto el nombre de forma estática, pero esta no será siempre la forma en la que querremos indicar el nombre del archivo, en la mayoría de las ocasiones este nombre deberá ser generado de forma dinámica. Para lograr esto, todas las propiedades de todos los results de Struts 2 permiten establecer sus valores usando expresiones, esto es colocar una marca que indique que esa propiedad deberá ser leída de algún getter de la clase.

En este caso indicaremos que el nombre del archivo deberá ser obtenido usando el método "getNombreArchivo" de la clase:


@Result(type = "stream", params =
{
    "contentType", "application/pdf",
    "contentDisposition","attachment;filename=\"${nombreArchivo}\""
})

Podemos ver que solo colocamos "nombreArchivo" entre los signos "${" y "}" (que indican que lo que esté contenido entre ambos es una expresión) y el framework automáticamente sabrá que debe buscar un getter.

Con archivos XML queda exactamente igual:


<result type="stream">
    <param name="contentType">application/pdf</param>
    <param name="contentDisposition">attachment;filename="${nombreArchivo}"</param>
</result>

En este caso, nuestro método "getNombreArchivo" regresará una cadena estática, pero en una aplicación real esta podría ser generada de forma dinámica:


public String getNombreArchivo()
{
    return "documento.pdf";
}

Ejecutamos nuevamente la aplicación y podremos ver que ahora el nombre del archivo está siendo efectivamente leído a través del getter correspondiente:

Hasta ahora nuestra descarga parece realizarse de forma correcta, pero si prestamos un poco de atención al cuadro de descarga podremos ver que hay algo que no nos agrada mucho:

¿Lo han notado? Y no, no me refiero a mi velocidad de descarga (aunque a mí no me agrada mucho que digamos ^^). El cuadro de descarga nos dice que no conoce el tamaño del archivo que estamos enviando al cliente, solo sabe la cantidad de información que ya ha descargado. Esto es muy molesto para los clientes, porque no saben cuánto tiempo deberán esperar para descargar su archivo.

Remediemos este pequeño error, para eso usaremos un parámetro más que nos proporciona el result "stream", "contentLength". Este parámetro, como su nombre lo indica, permite especificar cuál es el tamaño del archivo que estamos enviando, para que el navegador pueda colocar la barra de progreso de descarga del archivo de forma correcta.

Para usar esta propiedad deberemos hacer unos pequeños cambios en nuestro código. Antes que nada debemos agregar un atributo, con su correspondiente getter, que contenga el número de bytes que pesa nuestro archivo:


private long bytesArchivo;

public long getBytesArchivo()
{
    return bytesArchivo;
}

Ahora debemos modificar el código del método "execute" para que obtenga el dato anterior, para eso haremos uso de otro de los constructores de la clase "FileInputStream" que hemos estado usando para leer el archivo. Este segundo constructor recibe, en vez de la ruta en la que se encuentra el archivo a leer, un objeto de tipo "File" que representa el archivo; por lo que ahora crearemos un objeto de tipo "File" y se lo pasaremos al constructor de "FileInputStream":


@Override
public String execute() throws Exception
{
    String ruta = ServletActionContext.getServletContext().getRealPath("/Ingenieria de software.pdf");

    File archivo = new File(ruta);
        
    inputStream = new FileInputStream(archivo);

    return SUCCESS;
}

¿Por qué hemos hecho esto? Bueno, porque la clase "File" contiene un método que nos permite obtener justamente el tamaño del archivo, de la siguiente forma:


@Override
public String execute() throws Exception
{
    String ruta = ServletActionContext.getServletContext().getRealPath("/Ingenieria de software.pdf");

    File archivo = new File(ruta);
    bytesArchivo = archivo.length();
        
    inputStream = new FileInputStream(archivo);

    return SUCCESS;
}

Con esto hemos terminado con las modificaciones al método "execute" y lo único que falta es agregar el parámetro correspondiente a nuestro result, para esto nuevamente haremos uso de una expresión:


@Result(type = "stream", params =
{
    "contentType", "application/pdf",
           "contentDisposition","attachment;filename=\"${nombreArchivo}\"",
    "contentLength", "${bytesArchivo}"
})

Con archivos XML queda de la siguiente forma:


<result type="stream">
    <param name="contentType">application/pdf</param>
    <param name="contentDisposition">attachment;filename="${nombreArchivo}"</param>
    <param name="contentLength">${bytesArchivo}</param>
</result>

Y esto es todo. Ahora cuando volvamos a intentar descargar nuestro archivo obtendremos el siguiente dialogo de descargar:

En esta ocasión se indica el tamaño del archivo y el tiempo que hace falta para concluir con la descarga, por lo que nuestro segundo ejemplo ha funcionado correctamente ^^.

Ahora pasaremos a ver el tercer y último ejemplo. En este veremos un uso aún más común del result "stream": enviar imágenes del servidor al navegador y mostrárselas al usuario.

Para este último ejemplo del tutorial crearemos una nueva clase llamada "GeneradorImagenes", dentro del paquete "actions", esta clase extenderá de "ActionSupport":


public class GeneradorImagen extends ActionSupport
{
}

Como regresaremos un flujo de bytes al usuario, debemos declarar una variable de tipo "InputStream" con su correspondiente getter. El identificador de esta variable puede ser cualquiera que queramos, en mi caso lo llamaré "imagenDinamica":


private InputStream imagenDinamica;

public InputStream getImagenDinamica()
{
    return imagenDinamica;
}

Ahora viene la parte interesante, generaremos la imagen de manera dinámica y la guardaremos de forma que al ser enviada al navegador este pueda entenderla para mostrarla.

Sobre-escribimos el método "execute" e indicamos cuál será el alto y el ancho de nuestra imagen:


@Override
public String execute() throws Exception
{
    final int ANCHO_IMAGEN = 260;
    final int ALTO_IMAGEN = 130;
}

El hecho de que las variables estén marcadas como final es solo para asegurarme de que su valor no cambie durante la ejecución del método.

Ahora crearemos un objeto que nos permita manipular de una forma sencilla imágenes generadas por nosotros mismos. Para esto haremos uso de la clase "BufferedImage". Esta clase recibe en su constructor el ancho y alto de la imagen, además de indicar el tipo de la imagen que será creada, en nuestro caso será una sencilla imagen en RGB:


BufferedImage imagen = new BufferedImage(ANCHO, ALTO, BufferedImage.TYPE_INT_RGB);

Existen muchas formas de establecer los colores de cada uno de los pixeles de una "BufferedImage": podemos obtener un objeto "Graphics2D" usando su método "createGraphics()" y posteriormente dibujar sobre este usando el API 2D de Java. Aunque la forma más rápida para este ejemplo es usar directamente su método "setRGB". A este método se le indica la posición del pixel que queremos establecer, en coordenadas "x,y", y el color del pixel en exadecimal, o sea "0xFF0000" para el rojo, "0x00FF00" para el verde, y "0x0000FF" para el azul.

Crearemos dos ciclos, uno para recorrer todos las filas de la imagen, y otro para recorrer todas sus columnas. Dentro del ciclo más anidado estableceremos el color del pixel apropiado usando una instancia de la clase "Color" que recibe el valor correspondiente al rojo, verde, azul, y la transparencia del color. Los valores deben están dentro del un rango de 0 a 255, siendo 0 el tono más obscuro (negro) y 255 el más claro (blanco). Si el color se sale del rango la imagen no se mostrará, por lo que usaremos el operador modulo "%" para hacer que los valores se queden en este rango. Como el valor del pixel debe ser pasado como un entero, usaremos al final el método "getRGB()" de "Color" para obtener el valor correspondiente al color que estamos estableciendo:


for(int alto = 0; alto < ALTO_IMAGEN; alto++)
{
    for(int ancho = 0; ancho < ANCHO_IMAGEN; ancho++)
    {
        imagen.setRGB(ancho, alto, new Color((ancho*alto)%255, (ancho*alto)%255, (ancho*alto)%255, 255).getRGB());
    }
}

También pudimos haber hecho algo más sencillo como:


imagen.setRGB(ancho, alto, ancho*alto);

Pero no se obtiene el mismo resultado, y es un poco menos claro lo que está pasando ^_^.

Nuestra imagen ya tiene color, ahora debemos transformarla a un formato que pueda ser entendido por un navegador web. Para esto haremos uso de la clase "ImageIO", la cual tiene un método estático, "write", que permite convertir las imágenes en formatos "png", "jpg", "gif" y "bmp". Este método recibe como parámetros la imagen que queremos dibujar, el formato en el queremos que quede la imagen, y un "OutputStream" en donde quedarán los bytes de la imagen.

Para el ultimo parámetro usaremos un tipo de "OutputStream" que nos permita recuperar los bytes de esa imagen de una forma simple, por lo que usaramos un objeto de tipo "ByteArrayOutputStream":


ByteArrayOutputStream bytesImagen = new ByteArrayOutputStream();
ImageIO.write(imagen, "png", bytesImagen);

El último paso es crear el "InputStream" desde el cual Struts 2 leerá nuestra imagen. La imagen ya está en un arreglo de bytes, el del objeto de tipo "ByteArrayOutputStream", por lo que usaremos un objeto que nos permita usar este arreglo de bytes para crear un "InputStream". Usaremos un objeto de tipo "ByteArrayInputStream" que en su constructor recibe un arreglo de bytes, en este caso el arreglo de bytes que representa nuestra imagen:


imagenDinamica = new ByteArrayInputStream(bytesImagen.toByteArray());

Eso es todo. Nuestro método "execute" queda de la siguiente forma:


public String execute() throws Exception
{
    final int ANCHO_IMAGEN = 260;
    final int ALTO_IMAGEN = 130;
        
    BufferedImage imagen = new BufferedImage(ANCHO_IMAGEN, ALTO_IMAGEN, BufferedImage.TYPE_INT_RGB);
        
    for(int alto = 0; alto < ALTO_IMAGEN; alto++)
    {
        for(int ancho = 0; ancho < ANCHO_IMAGEN; ancho++)
        {
            imagen.setRGB(ancho, alto, new Color((ancho*alto)%255, (ancho*alto)%255, (ancho*alto)%255, 255).getRGB());
        }
    }
        
    ByteArrayOutputStream bytesImagen = new ByteArrayOutputStream();
    ImageIO.write(imagen, "png", bytesImagen);
    
    imagenDinamica = new ByteArrayInputStream(bytesImagen.toByteArray());
        
    return SUCCESS;
}

Como ven, es más sencillo de lo que parecía ^_^.

Para terminar con nuestro Action debemos colocar las anotaciones que indican que esta clase debe ser tratada como un Action de Struts 2. Casi todas ya las hemos visto hasta el cansancio, por lo que solo comentaré que nuestro result debe ser de tipo "stream" y que le estableceremos dos parámetros: "inputName" que indica el nombre de la propiedad de tipo "InputStream" que contiene los bytes que serán regresados al usuario, en nuestro caso esta es "imagenDinamica".

El otro parámetro que debemos establecer es el "contentType" que indica el formato de nuestra imagen, en este caso "image/png". También podríamos indicar el tamaño de la imagen usando el parámetro "contentLength", pero esto queda como ejercicio para el lector ^_^!.


@Namespace(value = "/descarga")
@Action(value = "imagenGenerada", results =
{
    @Result(type = "stream", params =
    {
        "inputName", "imagenDinamica",
        "contentType", "image/png"
    })
})

Con archivos XML quedaría de la siguiente forma:


<result type="stream">
    <param name="inputName">imagenDinamica</param>
    <param name="contentType">application/pdf</param>
</result>

La clase "GeneradorImagen" queda finalmente de la siguiente forma:


@Namespace(value = "/descarga")
@Action(value = "imagenGenerada", results =
{
    @Result(type = "stream", params =
    {
        "inputName", "imagenDinamica",
        "contentType", "image/png"
    })
})
public class GeneradorImagen extends ActionSupport
{
    private InputStream imagenDinamica;
    
    @Override
    public String execute() throws Exception
    {
        final int ANCHO_IMAGEN = 260;
        final int ALTO_IMAGEN = 130;
        
        BufferedImage imagen = new BufferedImage(ANCHO_IMAGEN, ALTO_IMAGEN, BufferedImage.TYPE_INT_RGB);
        
        for(int alto = 0; alto < ALTO_IMAGEN; alto++)
        {
            for(int ancho = 0; ancho < ANCHO_IMAGEN; ancho++)
            {
                imagen.setRGB(ancho, alto, new Color((ancho*alto)%255, (ancho*alto)%255, (ancho*alto)%255, 255).getRGB());
            }
        }
        
        ByteArrayOutputStream bytesImagen = new ByteArrayOutputStream();
        ImageIO.write(imagen, "png", bytesImagen);
    
        imagenDinamica = new ByteArrayInputStream(bytesImagen.toByteArray());
        
        return SUCCESS;
    }

    public InputStream getImagenDinamica()
    {
        return imagenDinamica;
    }  
}

El último paso consiste en indicar en una JSP que debe mostrar una imagen usando este Action. Para eso usaremos la etiqueta "<img>" de HTML. Para no crear una nueva JSP colocaremos esta etiqueta en la página "archivo.jsp" que hemos estado usando. En esta etiqueta debemos indicar que la fuente (el source) de la imagen en nuestro Action, de la siguiente forma:


<img src="imagenGenerada.action" alt="imagen" />

Así de simple. Ahora si volvemos a ejecutar nuestra aplicaciones, debemos ver la siguiente salida

No es la mejor imagen del mundo, pero es dinámica y es nuestra ^_^

Con esto damos fin a este largo tutorial en el que hemos visto todo lo que debemos saber para el trabajo de formularios con Struts 2.

Cualquier duda, comentario, sugerencia, aclaración o corrección pueden dejar un comentario o enviar un correo a "programadorjavablog@gmail.com".

Saludos y gracias.

Descarga los archivos de este tutorial desde aquí:

Trabajo con Formularios

Entradas Relacionadas: