Como en el artículo anterior esbozaré lo que me parece más importante en este post y os dejaré un link a la wiki pública en la que tendréis información de cómo hacerlo en detalle.

Lo más importante se encuentra en el archivo de configuración Web [nombre del servlet]-servlet.xml, dónde el nombre del servlet es es el nombre que le hemos dado al servlet en el archivo Web.xml. El archivo tiene este aspecto:

<bean id="viewNameTranslator" class="org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator"/>
<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix" value="/jsp/"/>
<property name="suffix" value=".jsp"/>
</bean >
<bean id="defaultHandlerMapping" class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"/>
<bean name="/pruebaController.do" class="org.raul.springmvc.web.PruebaController"/>
</beans>

Ya sé que el XML no queda muy bien en el editor, pero menos es nada, la novedad radica en que cuando se hace una transición desde un controller al String que devulve se le concatena por delante /jsp/ y por detrás del String .jsp de tal manera que si ha devuelto el String hello buscará el archivo hello.jsp en el directorio jsp dentro del directorio Web, así no hay que poner a que JSP cada vez y eliminamos la navegación del fichero XML.
Por otro lado, en lo que a los Controllers se refiere sigue habiendo que declararlos en el contexto y en su atributo name especificamos con qué URL van a ser accedidos, pero es un mal menor.

Como lo prometido es deuda os dejo el link al artículo de la wiki:

http://www.programania.net/contextos/doku.php?id=conventions_en_spring_mvc

Al parecer al estar basado EJB 3.0 en annotations reduce considerablemente los ficheros XML a utilizar. No se el tiempo dará la razón pero la verdad es que a mí no me termina de convencer ningún framework Web creía haber visto la luz con JBullet y al ver sus validaciones sufrí una desilusión terrible.

Así pues, tenemos uno más para la colección por si nos aburriamos mientras no salga un framework que despunte sobre los demás por algo claro y tangible me da que todavía no vamos a jubilar a Struts una pena porque ya hace 6 años que salió.

Para los interesados en visitar la la web de JBoss Seam:

http://www.jboss.com/products/seam

El framework propone añadir un método validate() dentro del Model, es decir, lo que en Struts sería el ActionForm y esto se ha demostrado es un error garrafal ya que obliga a mezclar churras con merinas o lo que es lo mismo lógica de presentación y lógica de negocio. En otros frameworks ya se han hecho importantes avances al respecto como en Java Server Faces que incluye unos tags que se incluyen en los JSP o bien da la oportunidad de implementar un validador implementando una interfaz y llamarlo con un tag especial desde el JSP incluso Struts sacó el pluggin Validator al darse cuenta que eso era un error y este framework propone volver a eso, es simplemente descorazonador. Habrá que esperar a la versión 2.0.

Para los que deseen encontrar la poca información al respecto sólo tienen que descargarse el framework y éste trae un pdf en el que esplica por encima las validaciones.

El caballo de batalla de este framework es acabar con los archivos de configuración así pues iré comentando los aspectos más interesantes del framework con trozos de código para que se entienda.

La configuración es similar a la de Struts, una vez añadidas las librerías al classpath de la aplicación y añadidas las líneas de código pertinentes en el archivo web.xml ya estaremos en disposición de poder utilizar el framework. La líneas a añadir en el archivo web.xml son casi identicas a las que había que poner para usar Struts así que los programadores de Java no encontrarán problemas los demás con un simple vistazo a la documentación ya podrán ponerse en marcha.

A diferencia de stuts no tendremos ningún archivo de configuración como podía ser el archivo struts-config.xml. El único archivo de configuración es el archivo jbullet.properties en el que especificaremos en que paquete colocaremos nuestros controllers, nuestros model y nuestros views. El archivo tiene el siguiente aspecto y debe colocarse en el directorio raíz de nuestra aplicación web.

#The controllers’ package
jbullet.controller.package=controller
#The view folder
jbullet.view.package=/WEB-INF/view
#The model package
jbullet.model.package=model
#The resource bundle name
#by default it’s application
#don’t mention .properties extension and any locale
jbullet.resource=application
#The resource reader class
#Should extend org.jbullet.resource.MessageResourceReader class
#By default it’s PropertyMessageResourceReader
jbullet.resource.reader=PropertyMessageResouceReader
#The response no-cache attribute tru=no-cache,false=yes do cache
jbullet.config.cache=true
#The default locate of the application
#The user locale is ignored if this element is specified
jbullet.config.locale=en

Este archivo es mucho más fácil de manterner que los xml a los que se está habituado en el mundo java y no crece de manera exponencial segun va creciendo nuesta aplicación.

JBullet es la implementación de un patrón MVC y por tanto necesitaremos implementar estos tres elementos para poder desarrollar nuestras aplicaciones.

Siguiendo la comparación con Struts los Controllers son lo que en Struts se conocían como Actions, en Struts estas clases extendían la clase Action y en JBullet se considera que un Controller( Convention) es toda clase que se encuentre en el paquete de Controllers (especificado en el archivo jbullet.properties) y acabe en Controller, se aconseja que nuestros controllers extiendan la clase BaseController ya que está clase contiene los objetos Context, Request y Response aunque estos objetos pueden inyectarse como se muestra en el ejemplo y no extender la clase BaseController si eso nos fuera útil.

Ejemplo1 Extendiendo BaseController:

package controller;
import org.jbullet.controller.BaseController;
public class HelloController extends BaseController{

public void index(){

renderText(“Hello World”);

}

public void wow(){

renderText(“Hello from WOW”);

}

}//End Listing 1.1

Ejemplo2 Inyectando

package controller;
import java.io.IOException;
import javax.servlet.http.HttpServletResponse;
import org.jbullet.annotation.Dependency;
import org.jbullet.annotation.DependencyType;
@Dependency({DependencyType.RESPONSE})
public class Hello2Controller {
//The response we need
HttpServletResponse response;
//The setter method called by the dependency injector

public void setResponse(HttpServletResponse response){

this.response=response;

}

//Here goes the handler methods

public void index(){

try{

response.getWriter().print(“Hello World from Hello2″);

response.getWriter().flush();

}catch(IOException ex){

//Do whatever you like with the exception

}

}

public void wow() throws IOException{

response.getWriter().print(“Hello from WOW in Hello2″);

response.getWriter().flush();

}

}//End Listing 2

Una ventaja importante de los controllers de JBullet frente a los Action de Struts son la posibilidad de poner varios métodos para realizar varias acciones desde un mismo controller, es decir , el controllador de aplicaciones tendrá los métodos de listar aplicaciones ,editar ,nueva y borrar aplicación. Esto era difícil con Struts ya que había que pasar un parámetro extra bien en el ActionForm o por la URL y poner un case en el método execute a la vez que se complicaba el archivo struts-config.xml. Con JBullet esto es muy sencillo se puede llamar a un método u otro de la siguiente manera:

http://localhost/QuickStart/controller/Custormer/ para el método index

o http://localhost/QuickStart/controller/Custormer/wow/ para el método wow

Al poner /Customer/ buscará la clase CustomerController en el paquete de controllers y al poner wow buscará dicho método en esa clase si no existieran elevaría una excepción si no se le pone nada por defecto busca el método index.

Se utilizan las annotations de la JDK 1.5 para especificarle al inyector de JBullet que objeto ha de inyetarle a la clase. Si en vez de inyectar el objeto Response se quisiera inyectar un Bean nuestro se tendría que utilizar la directiva @Bean para indicarle al inyector que busque la clase en el paquete de Models.

Para implementar las Views JBullet supone por defecto que se van a realizar utilizando jsps y que estos se encuentran en la ruta especificada en el fichero jbullet.properties.

Se dispone de tags especificos para los jsps como en el caso de Struts y para la navegación entre vistas no hace falta ningún fichero de configuración ya que en el controller al especificarse :

ViewResolver.forwardTo(“register”,request,response);

Jbullet buscará el jsp register.jsp y redirigirá la petición si no lo encuentra elevará una excepción.

Para implementar los Models JBullet utiliza los típicos Beans de siempre que mapean una fila de una tabla de la BD ( los beans de la capa de negocio de nuestra aplicación ) , aquí encontramos una gran diferencia con Struts ya que Struts utilizaba los ActionForms que a priori mezclaban la lógica de Negocio y presentación más tarde se solucionó ese problema permitiendo que se pudiera embeber un bean creado por el usuario dentro del ActionForm pero no dejaba de ser un parche JBullet propone una solución limpia desde el principio.
La internalización de la aplicación está pensada como en struts se dispone de un archivo por cada idioma. El archivo es applicaction_%idioma%.properties de tal manera que cuando cambie el objeto locale se cargue el archivo de idioma que proceda.

Para cada texto en este archivo sólo hay que especificar clave por la que se quiere acceder al texto y el texto en sí.

Por ejemplo en castellano:

aplicación.cabecera=Listado de aplicaciones.

En inglés:

aplicacion.cabecera=Application List.

Las única duda que me genera el framework es que en la documentación nos se comenta nada acerca del soporte de validaciones de los formularios pero en verdad espero que esté pensado como tags a colocar en los JSPs y se hulla de las validaciones tal y como se hacen en Stuts con 2 ficheros de configuración.

Los que quieran indagar más sobre el tema pueden acceder a la documentación oficial en esta url:

https://jbullet-web.dev.java.net/