A menudo, la documentación del software consiste en grandes, pesados y amenazadores manuales que nadie nunca lee. De hecho, durante los últimos cinco años, la mayoría de los manuales que venían con productos software han sido en realidad copias de “La danza de la muerte” de Stephen King, con nuevas tapas pegadas.

– Dave Barry

Componentes en Joomla

Los componentes son extensiones más complejas que los módulos, y suelen contar con una parte pública o frontend y otra de administración o backend.

Sólo puede haber un componente activo por página, y este se determina mediante un argumento option en la petición HTTP, que contendrá el nombre del componente a cargar. Para un componente con nombre com_componente, por ejemplo, la URL para ejecutar el backend sería http://servidor.com/administrator/index.php?option=com_componente y la del frontend, http://servidor.com/index.php?option=com_componente.

Cuando Joomla! se encuentra con una URL de este tipo, con un parámetro option indicando el nombre de un cierto componente, el engine busca y ejecuta el archivo components/com_nombre/nombre.php si se trata del frontend y administrator/components/com_nombre/nombre.php si vamos a cargar el backend.

Aunque podríamos escribir todo el código del componente en estos dos archivos, es conveniente que nuestro código esté algo más estructurado.

De un tiempo a esta parte, afortunadamente, se está tendiendo a utilizar el patrón MVC a la hora de crear componentes para Joomla, por lo que el contenido de estos dos archivos suele consistir simplemente en la instanciación y ejecución de un controlador.

El patrón MVC en los componentes Joomla

¿Que qué es un controlador, o el patrón MVC, ya que estamos? MVC es un viejo conocido de los desarrolladores web que propone usar una arquitectura dividida en 3 capas diferenciadas, en pos de reducir el acoplamiento. Estas capas, cuyas siglas dan nombre al patrón son:

• Modelo: los datos que maneja la aplicación y las reglas de negocio que operan sobre ellos
• Vista: genera la interfaz con la que la aplicación interacciona con el usuario
• Controlador: comunica la vista y el modelo respondiendo a eventos generados por el usuario en la vista, invocando cambios en el modelo, y proporcionando a la vista la información del modelo necesaria para que pueda generar la respuesta adecuada para el usuario

El patrón MVC se implementa en Joomla utilizando 3 clases distintas, una por cada componente del patrón: JModel para el modelo, JView para la vista y JController para el controlador.

Un controlador en Joomla es una clase que extiende JController, con un método para cada tarea con la que el controlador tenga que tratar: mostrar un elemento, crear un elemento, borrar un elemento, etc. En estos métodos el controlador analiza la entrada del usuario y lleva a cabo los pasos necesarios para generar la respuesta (seleccionar el modelo o modelos necesarios y la vista a utilizar y asociarlos, hacer una redirección, generar un error…)

Un modelo en Joomla es una clase que extiende JModel, con distintos métodos para realizar distintas acciones sobre los datos. No importa la forma que tomen estos datos o la forma en la que trabajemos con ellos: podríamos utilizar JTable, JDatabase, mysqli, las funciones para trabajar con ficheros…

Una vista en Joomla es una clase que extiende JView, con uno o más métodos para generarar la página HTML, el feed, el PDF, … que mostrar al usuario como respuesta. Cuando la respuesta es una página HTML, la vista suele hacer uso de plantillas.

Punto de entrada al componente

Ahora que ya hemos establecido en qué consiste el patrón MVC, veamos el aspecto que tendrá el archivo que actúa a modo de punto de entrada al componente, y que, como dijimos anteriormente, se ejecuta al cargar la URL http://servidor.com/index.php?option=com_nombre (vamos a centrarnos en este artículo en el frontend)

Recordaréis que este archivo debía instanciar el controlador y ejecutarlo. Eso es lo que hace este fragmento de código:

<?php
defined('_JEXEC') or die('Restricted access');

$controller = JRequest::getWord('controller', 'default');
$path = JPATH_COMPONENT.DS.'controllers'.DS.$controller.'.php';

if(file_exists($path)) {
  require_once($path);
  $classname = 'EjemploController'.$controller;
  $controller = new $classname();

  $controller->execute($task);
  $controller->redirect();
}

Es una práctica común el utilizar un controlador por cada tipo de entidad con el que vayamos a trabajar, y utilizar el parámetro controller para indicar el controlador a usar; ese es el motivo de que usemos JRequest para obtener su valor. En caso de que no se haya encontrado ningún parámetro controller en la petición, la variable $controller obtendrá como valor ‘default‘.

Una vez sabemos qué controlador cargar (uno especificado en la URL, o default) comprobaremos si realmente existe un archivo PHP con ese nombre en la carpeta controllers de nuestro componente.

Si es el caso, cargaremos el código del componente, instanciaremos la clase, llamaremos a su método execute pasándole como argumento el valor del parámetro task de la URL (que se guarda automáticamente en $task), y llamaremos a su método redirect.

El método execute del controlador es el encargado de llamar a uno u otro de los métodos del controlador para tratar la petición. Normalmente se ejecutará el método que tenga el nombre pasado como parámetro a execute, aunque se puede modificar el mapeo utilizando el método registerTask() (por ejemplo para que el mismo método se encargue de la tarea de editar y crear un nuevo elemento). Si la URL no tiene ningún parámetro task, y por lo tanto se le pasa una cadena vacía a execute, o si el valor no se encuentra en el mapeo, se ejecutará por defecto el método de nombre display.

El método redirect sirve para redirigir el navegador en caso de que en el método ejecutado en el controlador se estableciera una redirección (mediante el método setRedirect).

Controlador

Un controlador muy sencillo, que no hace más que ejecutar la vista asociada podría tener este aspecto:

<?php
defined('_JEXEC') or die('Restricted access');

jimport('joomla.application.component.controller');

class EjemploController extends JController {
  function display() {
    parent::display();
  }
}

De hecho, como nuestro método display, que, como ya hemos comentado, es el que se ejecuta si no se pasa ningún argumento a execute en el punto de entrada, sólo llama al método display del objeto padre, no tendríamos si quiera por qué sobre escribirlo:

<?php
defined('_JEXEC') or die('Restricted access');

jimport('joomla.application.component.controller');

class EjemploController extends JController {}

Pero normalmente nuestros controladores no serán tan sencillos. Lo más habitual es encontrarse con 2 tipos de métodos: aquellos en los que sólo queremos mostrar una cierta información al usuario, y otros en los que realizaremos una acción sobre el modelo, y redirigiremos el navegador a otra URL para mostrar el resultado.

En el primer caso sólo tenemos que establecer la vista y la plantilla a utilizar, y ejecutarla.

function display() {
  JRequest::setVar('view', 'persona');
  JRequest::setVar('layout', 'default');

  parent::display();
}

o bien

function display() {
  JRequest::setVar('view', 'persona');

  parent::display('default');
}

dado que default es la plantilla que se carga por defecto, si sólo vamos a usar una plantilla, o bien, si vamos a utilizar la plantilla default, no será necesario indicarlo

function display() {
  JRequest::setVar('view', 'persona');

  parent::display();
}

En el segundo caso tendríamos algo así

function guardar() {
  $modelo = $this->getModel('persona');
  if($modelo->guardarPersona())
    $this->setRedirect('index.php?option=com_nombre', 'Persona guardada con exito');
  else
    $this->setRedirect('index.php?option=com_nombre', 'Error al guardar', 'error');
}

Vista

Como dijimos, las vistas consisten en clases que extienden JView. En estas clases nos interesará sobreescribir el método display, donde asignaremos las variables que la plantilla pueda necesitar con assign o assignRef (el primero asigna una copia del dato y el segundo una referencia) y llamaremos al método display de la clase padre para que renderice la plantilla.

class EjemploViewDefault extends JView {
  function display($tpl=null) {
    $this->assignRef('mensaje', 'Hola mundo');

    parent::display($tpl);
  }
}

Para obtener datos del modelo en la vista se puede hacer lo siguiente

class EjemploViewDefault extends JView {
  function display($tpl=null) {
    $modelo =& $this->getModel('MiModelo');
    $mensaje = $modelo->getMensaje();
    $this->assignRef('mensaje', $mensaje);

    parent::display($tpl);
  }
}

Si el modelo tiene el mismo nombre que la vista, lo cuál suele ser habitual, porque es práctica común usar una vista y un modelo por entidad, de la misma forma que hacíamos con los controladores, el modelo estará asociado automaticamente con la vista, y bastará con hacer algo así:

class EjemploViewDefault extends JView {
  function display($tpl=null) {
    $mensaje =& $this->get('Mensaje');
    $this->assignRef('mensaje', $mensaje);

    parent::display($tpl);
  }
}

Al llamar al método get la vista buscará en el modelo asociado un método con nombre get seguido de la cadena pasada como parámetro (getMensaje en el ejemplo) y lo ejecutará.

Por último, como dijimos, si vamos a usar la plantilla por defecto, default.php, no necesitaremos pasar a display ningún parámetro:

class EjemploViewDefault extends JView {
  function display($tpl=null) {
    $mensaje =& $this->get('Mensaje');
    $this->assignRef('mensaje', $mensaje);

    parent::display();
  }
}

Las plantillas son archivos PHP en los que casi todo es HTML, y se usan pequeños snipets PHP para imprimir los valores necesarios en las posiciones adecuadas. Se podría crear el código HTML de la respuesta en la clase de la vista utilizando echo, por ejemplo, pero el uso de plantillas facilitará la vida a los diseñadores, o, si no hay diseñadores, a nosotros, cuando tengamos que reutilizar código o mantener el componente.

En la plantilla se accede a los datos que se han asignado con assign y assignRef usando $this->dato

<h1><?php echo $this->dato; ?></h1>

En la plantilla también se puede usar $this->loadTemplate('plantilla'); para cargar otra plantilla y tener así un diseño más modular. En el siguiente código se cargaría una plantilla default_cabecera.php, por ejemplo:

<?php $this->loadTemplate('cabecera'); ?<

<h1><?php echo $this->dato; ?></h1>

Modelo

Por último tenemos el modelo. Estas son las clases más sencillas. Basta extender JModel y crear tantos métodos como queramos, que realizarán las operaciones sobre los datos que necesitemos. Un ejemplo podría ser

<?php
defined('_JEXEC') or die('Restricted access');
jimport('joomla.application.component.model');

class ModelEjemplo extends JModel {
  function getMensaje() {
    $db =& JFactory::getDBO();
    $query = 'SELECT mensaje FROM #__mensajes ORDER BY RAND() LIMIT 1';
    $db->setQuery($query);
    return $db->loadResult();
  }
}

Crear un componente de ejemplo

Para continuar, vamos a crear un pequeño componente de ejemplo, basado en el típico hola mundo, que mostrará un mensaje aleatorio de entre los almacenados en una tabla de la base de datos.

Lo primero que tenemos que hacer es crear una carpeta en nuestra máquina, com_ejemplo, digamos, en la que almacenaremos los archivos de nuestro nuevo componente. Dentro de esta carpeta crearemos un archivo ejemplo.xml con la información del componente e información de la instalación (puede tener un nombre cualquiera, pero lo habitual es utilizar el nombre del componente, o install.xml):

<?xml version="1.0" encoding="utf-8"?>
<install type="component" version="1.5">
  <name>Ejemplo</name>
  <author>Raul Gonzalez</author>
  <creationDate>Febrero 2010</creationDate>
  <copyright>(C) Raul Gonzalez</copyright>
  <license>GPL</license>
  <authorUrl>http://mundogeek.net/</authorUrl>
  <authorEmail>zootropo en gmail</authorEmail>
  <version>0.1</version>
  <description>Componente de ejemplo que muestra mensajes aleatorios escritos por los lectores</description>
  <install>
    <queries>
      <query>CREATE TABLE IF NOT EXISTS jos_mensajes(
              id int NOT NULL auto_increment,
              mensaje varchar(300) NOT NULL, PRIMARY KEY(id));</query>
      <query>INSERT INTO jos_mensajes(mensaje) VALUES
              ('At your command'),
              ('Hay 10 tipos de personas en el mundo: los que entienden binario y los que no'),
              ('Es mio, solo mio. Miii.... tessssssooooroo'),
              ('Hasta luego, y gracias por el pescado');</query>
    </queries>
  </install>
  <files>
    <file>ejemplo.php</file>
    <file>ejemplo.xml</file>
    <folder>controllers</folder>
    <folder>models</folder>
    <folder>views</folder>
  </files>
  <administration/>
</install>

como véis no es muy distinto del archivo de instalación que utilizamos al crear nuestro primer módulo, a excepción de la sección administration, que en este ejemplo está vacía, pero normalmente listará los archivos de la parte de administración, y la sección install, que utilizamos en este caso para crear la tabla que usaremos para almacenar los mensajes, e introducir algunos mensajes iniciales.

El siguiente paso es crear el archivo que sirve de punto de entrada al componente, que, como ya comentamos, tendrá como nombre el mismo del componente sin el com_; es decir, en este caso, ejemplo.php. El contenido del mismo ya lo explicamos anteriormente:

<?php
defined('_JEXEC') or die('Restricted access');

$controller = JRequest::getWord('controller', 'mensaje');
$path = JPATH_COMPONENT.DS.'controllers'.DS.$controller.'.php';

if(file_exists($path)) {
  require_once($path);
  $classname = 'EjemploController'.$controller;
  $controller = new $classname();

  $controller->execute($task);
  $controller->redirect();
}

En este ejemplo, que es tan sencillo, no tiene mucho sentido tener más de un controlador, pero utilizaremos este código igualmente para que nuestro componente sea más fácil de extender y para que el ejemplo sea más instructivo.

Ahora tenemos que crear una carpeta controllers (fíjate en el valor de $path en el código anterior) en la que crearemos el archivo de nuestro controlador por defecto, que en este caso, como habréis supuesto por el segundo argumento de JRequest::getWord, será mensaje.php. Como dijimos, es habitual utilizar un controlador por entidad con la que vayamos a tratar, y el nombre del archivo suele ser el de la entidad. El nombre de la clase suele ser el nombre del componente, seguido de ‘Controller‘ y el nombre de la entidad (EjemploControllerMensaje en este caso).

En este ejemplo sólo necesitamos un método display (mostrar), que, como comentamos, es el que se ejecuta por defecto de no pasarse ningún otro valor al método execute.

<?php
defined('_JEXEC') or die('Restricted access');

jimport('joomla.application.component.controller');

class EjemploControllerMensaje extends JController {
  function display() {
    JRequest::setVar('view', 'mensaje');
    parent::display();
  }
}

Listo. Con algo tan simple ya tenemos nuestro primer controlador. Vayamos con la vista.

Creamos una carpeta views en el directorio del componente. En esta carpeta, para cada vista que vayamos a utilizar tendremos un directorio con el nombre de la vista, que contendrá a su vez un archivo view.html.php si vamos a generar una página HTML, view.feed.php si vamos a generar un feed, view.pdf.php si la salida será un PDF, o view.raw.php para cualquier otra cosa (el CMS sabe qué tipo de salida se debe mostrar al usuario gracias al parámetro format de la URL).

En nuestro ejemplo utilizaremos una vista para la única entidad con la que vamos a trabajar, aunque hay personas que prefieren tener una vista por cada página que vayamos a utilizar en el componente.

Crearemos, por lo tanto, una carpeta ‘mensaje’ en views, y un archivo view.html.php en mensaje. El archivo view.html.php contendrá, como dijimos, una clase que extiende JView, y cuyo nombre estará compuesto por el nombre del componente, la palabra View, y el nombre de la vista (el nombre de la entidad). Como vamos a seguir las convenciones de nombres habituales, la vista tendrá asociado el modelo correspondiente, y sólo tenemos que llamar a $this->get('Mensaje') para que se busque y ejecute el método getMensaje en el modelo, y obtener de esta forma el mensaje a mostrar. Una vez hecho esto basta asignar este valor para que esté disponible para la plantilla.

<?php
defined('_JEXEC') or die('Restricted access');

jimport('joomla.application.component.view');

class EjemploViewMensaje extends JView {
  function display($tpl=null) {
    $mensaje =& $this->get('Mensaje');
    $this->assign('mensaje', $mensaje);

    parent::display();
  }
}

Sigamos con la plantilla. En el mismo directorio en que se encuentra view.html.php crearemos una nueva carpeta tmpl para contener las plantillas o templates. Como sólo necesitaremos una plantilla, vamos a llamar a este archivo default.php, que es la plantilla que se carga por defecto de no indicarse otra cosa. Este archivo sólo tiene que hacer una cosa, y es mostrar el mensaje que se ha asignado en la clase de la vista.

<h1 style="text-align:center;"><?php echo $this->mensaje; ?></h1>

Por último veamos el modelo. Crearemos una nueva carpeta models en el directorio del componente, con un archivo mensaje.php que contendrá una clase cuyo nombre estará formado por el nombre del componente, la palabra ‘Model‘ y el nombre de la entidad. En este ejemplo sólo utilizamos un método getMensaje para obtener un mensaje aleatorio de la base de datos.

<?php
defined('_JEXEC') or die('Restricted access');
jimport('joomla.application.component.model');

class EjemploModelMensaje extends JModel {
  function getMensaje() {
    $db =& JFactory::getDBO();
    $query = 'SELECT mensaje FROM #__mensajes ORDER BY RAND() LIMIT 1';
    $db->setQuery($query);
    return $db->loadResult();
  }
}

Con esto ya tendríamos preparado nuestro componente. Sólo resta comprimir los archivos que lo componen e instalarlo desde Extensiones -> Instalar/Desinstalar. Para ver el resultado, tendremos que introducir en el navegador la URL http://servidor.com/index.php?option=com_ejemplo

Complicando el componente

Como puede que el ejemplo anterior os haya sabido a poco, vamos a añadir también la posibilidad de que los usuarios puedan introducir sus propios mensajes, para afianzar conceptos.

Lo primero que tenemos que hacer es editar el controlador, y crear un par de nuevos métodos que traten las nuevas tareas ‘anyadir‘, que mostará un formulario con el que introducir el mensaje, y ‘anyadido‘, que intentará guardar el mensaje y mostrará un texto u otro dependiendo del resultado.

<?php
defined('_JEXEC') or die('Restricted access');

jimport('joomla.application.component.controller');

class EjemploControllerMensaje extends JController {
  function display() {
    JRequest::setVar('view', 'mensaje');
    parent::display();
  }

  function anyadir() {
    $vista = $this->getView('mensaje', 'html');

    $vista->anyadir('anyadir');
  }

  function anyadido() {
    $mensaje = JRequest::getVar('mensaje');
    $modelo = $this->getModel('mensaje');

    if($modelo->anyadirMensaje($mensaje))
      $this->setRedirect('index.php?option=com_ejemplo', 'Mensaje añadido con éxito');
    else
      $this->setRedirect('index.php?option=com_ejemplo', 'Se produjo un error al guardar el mensaje', 'error');
  }
}

Lo único destacable respecto de la versión anterior es que ahora necesitamos obtener una instancia de la vista, con el método getView(vista, formato) del controlador, para poder ejecutar un método distinto de display en la vista. Otra alternativa habría sido tener una vista distinta por página.

Un apunte interesante es que con JRequest::get('post') podemos obtener todos los datos de una petición POST, de forma que podríamos haber hecho algo así para guardar todos los datos de un formulario en la base de datos usando JTable:

$persona =& JTable::getInstance('persona', 'Table');
if ($persona->save(JRequest::get('post'))
  $mensaje = 'Guardado';
else
  $mensaje = 'Error: ', $empleado->getError();  

$this->setRedirect('index.php?option=com_componente', $mensaje);

La nueva versión de la vista, con el nuevo método anyadir, tendrá el siguiente aspecto:

<?php
defined('_JEXEC') or die('Restricted access');

jimport('joomla.application.component.view');

class EjemploViewMensaje extends JView {
  function display($tpl=null) {
    $mensaje =& $this->get('Mensaje');
    $this->assign('mensaje', $mensaje);

    parent::display();
  }

  function anyadir($tpl) {
    parent::display($tpl);
  }
}

Como vemos lo único que hace es mostrar la plantilla que indicó el controlador como parámetro. En este caso no necesitamos ningún dato del modelo, por lo que no se utiliza assign ni assignRef.

La nueva plantilla, default_anyadir.php, también es muy sencilla. Sólo muestra el formulario que el usuario utilizará para añadir el mensaje.

<form action="index.php" method="post">
  <input type="text" id="mensaje" name="mensaje"/>

  <input type="hidden" name="option" value="com_ejemplo" />
  <input type="hidden" name="task" value="anyadido" />

  <input type="submit" value="Registrar mensaje"/>
</form>

Fíjate en que hacemos uso de un par de campos ocultos para establecer el valor del parámetro option y el parámetro task, y que la petición va a ser tratada, como siempre, por index.php

Por último sólo nos queda ver la nueva versión del modelo, con el método anyadirMensaje que guardará el mensaje introducido por el usuario

<?php
defined('_JEXEC') or die('Restricted access');
jimport('joomla.application.component.model');

class EjemploModelMensaje extends JModel {
  function getMensaje() {
    $db =& JFactory::getDBO();
    $query = 'SELECT mensaje FROM #__mensajes ORDER BY RAND() LIMIT 1';
    $db->setQuery($query);
    return $db->loadResult();
  }

  function anyadirMensaje($mensaje) {
    $db =& JFactory::getDBO();
    $query = "INSERT INTO #__mensajes(mensaje) VALUES('{$mensaje}')";
    $db->setQuery($query);
    $db->query();

    if ($db->getErrorNum())
      return false;

      return true;
  }
}

Desinstalamos la versión anterior del componente, comprimimos los archivos, e instalamos la nueva versión desde Extensiones -> Instalar/Desinstalar. Y listo, hemos terminado de crear nuestro primer componente. En artículos posteriores veremos cómo añadir una interfaz de administración a nuestro componente.

• El modelo, que hace referencia a los datos que maneja la aplicación y las reglas de negocio que operan sobre ellos y que se traducen en Struts 2 en las acciones.
• La vista, encargada de generar la interfaz con la que la aplicación interacciona con el usuario. En Struts 2 equivale a los resultados.
• El controlador, que comunica la vista y el modelo respondiendo a eventos generados por el usuario en la vista, invocando cambios en el modelo, y devolviendo a la vista la información del modelo necesaria para que pueda generar la respuesta adecuada para el usuario. El controlador se implementa en Struts 2 mediante el filtro FilterDispatcher

Por supuesto, podríamos utilizar JSP y servlets para crear una aplicación utilizando el patrón MVC: en una aplicación con JSP y servlets clásica se suelen utilizar páginas JSP para la vista, un servlet como controlador (patrón front controller) y POJOs (Plain Old Java Objects) para el modelo. El modelo, a su vez, suele estar dividido en dos subcapas siguiendo el patrón DAO (Data Access Object).

Sin embargo no tiene sentido reinventar la rueda cuando podemos recurrir a un framework, como Struts 2, para que se encargue de obtener y transformar los parámetros de las peticiones del cliente, validar los datos, buscar qué acción se debe realizar en el modelo según la petición, buscar la página a mostrar al usuario según la respuesta del modelo, proporcionar los datos del modelo a la vista, ocuparse de la internacionalización, etc.

Veamos cómo crear un pequeño “Hola mundo” con Struts 2. O mejor aún: un hola algo.

Como IDE utlizaremos Eclipse. También necesitaremos un servidor de aplicaciones o un contenedor web, como Tomcat. Para ver cómo integrar tu servidor en Eclipse puedes consultar la entrada Eclipse y Tomcat, adaptando los pasos necesarios en caso de utilizar un servidor distinto.

Por supuesto también necesitaremos descargar Struts 2 desde su página web. En principio basta con descargar las librerías que componen Struts 2 y sus dependencias (Essential Dependencies Only) aunque también os puede interesar descargar la versión completa (Full Distribution) que incluye además la documentación, el código fuente, y distintas aplicaciones de ejemplo.

En todo caso una vez hemos descargado Struts 2, Eclipse y Tomcat ya está todo listo para comenzar a trabajar.

Abrimos Eclipse y nos dirigimos a File -> New -> Dynamic Web Project para crear un nuevo proyecto para web dinámica. En Project name introducimos el nombre que queramos utilizar para el proyecto, por ejemplo, hola. Pulsamos Finish.

Copiamos las librerías básicas a la carpeta WebContent\WEB-INF\lib. Estas son commons-fileupload, commons-logging, freemarker, ognl, struts2-core y xwork. Hacemos clic con el botón derecho sobre el proyecto, y seleccionamos Refresh para que Eclipse las vea.

Editamos el descriptor de despliegue (web.xml) para añadir el filtro que sirve a Struts 2 a modo de punto de entrada a la aplicación: FilterDispatcher. Hacemos doble clic sobre “Deployment Descriptor: hola” y sustituimos el contenido por el siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="WebApp_ID" version="2.5">
    <display-name>hola</display-name>

    <welcome-file-list>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

    <filter>
        <filter-name>struts</filter-name>
        <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>struts</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>

Como vemos lo único que estamos haciendo es indicar al contenedor web (Tomcat en este caso) que toda petición, tenga esta la URL que tenga, debe pasar por el filtro FilterDispatcher. FilterDispatcher es en realidad el controlador de nuestra aplicación; nosotros sólo tendremos que ocuparnos de la vista y el modelo, llamados resultados y acciones en la terminología de Struts 2.

Ahora vamos a crear la página de inicio de nuestra aplicación. Como en el descriptor de despliegue hemos indicado que index.jsp es uno de los “archivos de bienvenida” (welcome-file), cuando en la URL no se especifique el archivo a mostrar dentro del directorio se mostrará por defecto index.jsp; de esta forma tanto http://localhost:8080/hola/index.jsp como http://localhost:8080/hola/ mostrarán nuestra nueva página.

Hacemos clic con el botón derecho sobre WebContent y seleccionamos New -> JSP, en File name escribimos index.jsp y pulsamos Finish. El contenido de la página será el siguiente:

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

<html>
<body>
<s:form action="Hola">
<s:textfield name="nombre" label="Nombre"/>
<s:submit/>
</s:form>
</body>
</html>

Como vemos se utiliza la directiva taglib de JSP para indicar al contenedor que queremos usar la librería de etiquetas struts-tags, para las que se usará el prefijo “s”. Los nombres de las etiquetas de struts-tags que utilizamos son bastante descriptivos: estamos creando un formulario (<s:form></s:form>) con un campo de texto (<s:textfield/>) y un botón de enviar (<s:submit/>), que mandará los datos a la acción Hola (campo action del formulario).

Veamos ahora el código de la acción Hola. Las acciones en Struts 2 son clases Java que suelen implementar la interfaz Action o extender la clase ActionSupport (suelen, porque no es obligatorio). Creamosla haciendo clic con el botón derecho sobre Java Resources:src y seleccionando New -> Class; en Name, introducimos Hola y pulsamos Finish. Al crear el WAR de la aplicación el archivo .class acabará en WebContent/WEB-INF/classes. El código de la acción es el siguiente:

import com.opensymphony.xwork2.ActionSupport;

@SuppressWarnings("serial")
public class Hola extends ActionSupport {
    private String nombre;

    public String getNombre() {
        return nombre;
    }

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

    public String execute() {
        System.out.println(nombre);
        return SUCCESS;
    }
}

El código a ejecutar por nuestra acción está contenido en un método execute(). Como vemos la funcionalidad es bastante pobre, una simple excusa para utilizar una acción, ya que podríamos haber prescindido totalmente de ella. Sin embargo este código tan sencillo, que imprime en la consola el nombre que el usuario introdujo en el formulario, pone de manifiesto algo bastante interesante y es que no aparece por ningún lado un objeto HttpServletRequest ni similar del que obtener el valor del parámetro nombre del formulario, luego, ¿de dónde sale la propiedad nombre?

Lo cierto es que Struts 2 (o más bien el interceptor param de Struts 2) nos tiene preparada una sorpresa, y es que basta con crear getters y setters con los nombres de los campos de los formularios para que estos se rellenen auto mágicamente, incluso aunque las propiedades no sean cadenas y sea necesaria una sencilla conversión. Este es el trabajo del interceptor param, como hemos dicho.

Los interceptores son unos de los elementos más importantes de Struts 2. Se trata de objetos que ejecutan código antes y después de una cierta acción, de forma que podamos añadir nueva funcionalidad no relacionada directamente con el modelo de forma modular. Tenemos interceptores para logging, para validación, para capturar excepciones, etc.

Como vemos el método execute devuelve un string indicando el resultado de la acción. En este caso se devuelve SUCCESS, que es una constante proveniente de la clase que extendemos, ActionSupport, y cuyo valor es “success”. ¿Y de qué sirve esto? Pues para que Struts 2 sepa a qué página redirigir, según el mapping que definimos en el archivo de configuración de Struts 2 struts.xml.

Vamos a crear este archivo. Hacemos clic con el botón derecho sobre Java Resources:src, seleccionamos New -> XML, pulsamos Next y seleccionamos como nombre struts.xml y como directorio de destino src. Este archivo acabará en WebContent/WEB-INF/classes al crear el WAR de la aplicación. Su contenido debe ser el siguiente:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd">

<struts>
    <package name="mi-paquete" extends="struts-default">
        <action name="Hola" class="Hola">
            <result name="success">/hola.jsp</result>
        </action>
    </package>
</struts>

En este caso lo que estamos haciendo es indicar al framework que queremos que se ejecute el código de la clase Hola cuando llegue una petición a Hola.action, y que se muestre la página hola.jsp como resultado cuando el valor devuelto sea “success”.

Vamos a ver por último el código de hola.jsp. Hacemos clic con el botón derecho sobre WebContent y seleccionamos New -> JSP; en File name escribimos hola.jsp y pulsamos Finish. El contenido del archivo es el siguiente:

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

<html>
<body>
Hola <s:property value="nombre"/>
</body>
</html>

En esta página lo único que hacemos es utilizar la etiqueta <s:property/> para mostrar la propiedad nombre de la acción, que se toma de una pila de valores llamada ValueStack.

Solo resta probar el código de nuestra aplicación. Arrastramos el proyecto sobre nuestra instancia de Tomcat en la pestaña Servers, e iniciamos el servidor haciendo clic con el botón derecho sobre él y seleccionando Start. Si abrimos la URL http://localhost:8080/hola/ en nuestro navegador y todo funciona correctamente, deberíamos ver algo como esto:

Los usuarios de verdad nunca saben lo que quieren, pero saben que tu programa no lo ofrece.

Los usuarios de verdad son capaces de encontrar la única combinación de valores que puede hacer que el sistema se caiga por días.

Los usuarios de verdad saben tu número de teléfono.

Los usuarios de verdad nunca usan la función de ayuda.

Los usuarios de verdad odian a los programadores de verdad.

Los usuarios de verdad no ayudan a definir los requisitos. Si estos tipos de los ordenadores son tan listos, deberían ser capaces de adivinar lo que queremos.

Los usuarios de verdad prueban todos los botones de la aplicación. Y vuelven a probarlos otra vez para ver si hacen algo distinto y maravilloso.

Los usuarios de verdad escriben preguntas estúpidas en los foros y esperan respuesta.