En estas apareció Swing para solucionar estos “problemas”. ¿La clave? Utiliza Java 2D para invocar subrutinas de bajo nivel en vez de utilizar el módulo de interfaz de usuario de alto nivel del S.O. Es decir, el elemento es el mismo en cualquier plataforma.

Entrar en todos los detalles de una interfaz gráfica nos daría para escribir un libro. Es por eso que sólo quiero hacer una pequeña introducción a los aspectos básicos de la misma.

Tres elementos son los que podemos considerar como fundamentales:

• Componentes: elementos gráficos tales como botones, cuadros desplegables, cuadros de texto, etc.
• Contenedores: elementos que contienen otros componentes o contenedores, por ejemplo JPanel o JFrame.
• Layouts: diseño aplicable a los contenedores, es la forma de distribuir los componentes dentro del contenedor.

La diferencia entre contenedores y componentes es clara, unos contienen a otros. Pero… ¿que es eso del layout? Como su propio nombre indica es un diseño que se aplica a los contenedores. Es decir, nos echa una mano a la hora de colocar los componentes en los contenedores. Por ejemplo, si tenemos el diseño BorderLayout el contenedor se divide en cinco zonas (como se puede ver en la siguiente imagen):

De esta forma podemos indicar fácilmente que un botón u otro contenedor se incluya en la parte sur del contenedor principal. Existen varios tipos de layouts, y también existe la posibilidad de establecer a null el layout de un contenedor e indicar la posición donde colocar el componente.

Una implementación básica de una ventana podría ser un JFrame, que tiene un JPanel con un BorderLayout y este un JButton en el sur.

//Creamos el marco
 JFrame jFrame = new JFrame();

 //Creamos el panel principal
 JPanel jPanel = new JPanel();

 //Establecemos el layout del panel
 jPanel.setLayout(new BorderLayout());

 //Creamos un botón y lo añadimos al panel en el sur
 JButton jButton = new JButton("Aceptar");        
 jPanel.add(jButton,BorderLayout.SOUTH);

 //Establecemos el panel principal del marco
 jFrame.setContentPane(jPanel);

 //Cambiamos el tamaño y lo hacemos visible
 jFrame.setSize(200, 200);
 jFrame.setVisible(true);

Si se ejecuta el código anterior se obtiene el siguiente resultado:

Podemos encontrar una similitud entre los elementos que componen la ventana y un cuadro. El JFrame sería el marco, el JPanel sería el lienzo y el layout, con el resto de componentes, sería el dibujo en sí.

Aquí dejo la primera creación , tiene dos partes por la limitación de espacio en YouTube. ¿Críticas? Todas,  pero sobretodo la falta de calidad en la imagen. No me preocupa mucho en estos dos vídeos ya que están muy comentados y no es muy difícil seguirlos pero… no hay excusa. El próximo irá mejor.

Parte 1: http://www.youtube.com/watch?v=qMvALOI6G7Y

Parte 2: http://www.youtube.com/watch?v=Kwh_VpNZ2-E

También dejo el código fuente de la clase creada. De esta forma podéis verlo ya que en el vídeo queda borroso.  HolaMundo

Por ejemplo, en el formulario principal podemos tener un campo de texto para introducir el DNI y mostrar en el formulario detalle el listado de productos comprados por esa persona.

¿Y como se hace esto en Java? Muy sencillo. Creamos una serie de elementos gráficos que harán las veces de formulario principal (JTextField, JComboBox, etc.) e incluimos debajo de este una tabla donde aparecerán los distintos registros asociados a la búsqueda.

Como no podía ser de otro modo la clase que implementa en Java la tabla es JTable. Mucho hay escrito sobre el manejo de la misma (por ejemplo, aquí, aquí o aquí) por lo que sólo me voy a centrar en cómo “rellenarla” con datos.

Si le has echado un vistazo a los enlaces anteriores habrás visto que asociado al concepto de Tabla está el de Modelo de tabla (del inglés Table Model). Resumiendo, un modelo no es más que una manera de simplificar el acceso a contenido tabular (la típica tabla de datos). De esta manera la tabla queda independiente de la forma en la que se guardan los datos. Como se puede observar en la siguiente imagen JTable no tiene ni idea de la clase que implementa la interfaz TableModel. Lo único que le interesa es que alguien le proporcione los datos, y para ello invoca los métodos de la interfaz que estarán implementados en alguna de las subclases.

¿Qué vamos a hacer nosotros? Pues muy fácil, crear una subclase de DefaultTableModel y sobreescribir los métodos necesarios para que devuelva los datos que nosotros tenemos guardados en un ArrayList. La JTable invocará los métodos que necesite para mostrar los datos pero no se ejecutará la implementación de DefaultTableModel si no el código que nosotros hemos realizado. La estructura de clases quedará de la siguiente forma:

Para que el ejemplo quede un poco más “interesante” he creado una interfaz gráfica donde se muestra un JComboBox con un listado de clientes; de tal forma que al seleccionar uno de ellos se muestren las ventas realizadas por él. Para guardar el listado de ventas de cada cliente se ha utilizado una tabla hash donde cada entrada (identificada por el DNI) contiene un ArrayList con objetos de la clase Venta.

Una vez que sabemos donde guardar el listado de ventas de un cliente ya sólo nos queda mostrarlo en la tabla. Como se ha comentado anteriormente lo único que tenemos que hacer es sobreescribir una serie de métodos de DefaultTableModel en MiTableModel. Veamos cuales:

getColumnCount: nos devuelve el número de columnas del modelo. Ya que el listado de columnas está definido en el array nombreColumnas en la VentanaPrincipal, sólo tendremos que obtener el tamaño de este.

getColumnName(int column): nos devuelve el nombre de una columna. Para obtenerlo sólo tenemos que recuperar del array nombreColumnas el valor de la posición indicada por parámetro ‘column’.

getRowCount: devuelve el número de filas del modelo,  que en este caso se corresponden con el listado de ventas del cliente. Dicho listado se encuentra en la tabla hash listadoVentasCliente en la VentanaPrincipal.

getValueAt(int row, int column): devuelve el valor para una celda en concreto identificada por su fila y columna. La primera es la posición row dentro del listado de ventas del cliente y la segunda es el valor de uno de los atributos del objeto Venta.

isCellEditable: devuelve false siempre. Esto hace que la celda no sea editable.

El código comentado de la clase MiTableModel se encuentra dentro del proyecto Eclipse que os dejo en Rellenar Tabla.

La estructura de clases ha quedado de la siguiente forma.

He utilizado la versión 1.6 de Java.

Pero… si la declaración del método addItem nos indica que podemos pasar por parámetro un objeto de la clase Object (o una subclase de esta, como String), ¿por qué no pasar un objeto de una clase creada por nosotros y, de esta forma, utilizar un JComboBox de forma similar a un Vector, como una colección de objetos?

Por ejemplo, pensemos que tenemos una aplicación que gestiona productos de cualquier tipo y queremos que al seleccionar un producto obtengamos los datos de dicho producto para mostrarlos por pantalla. Lo interesante sería guardar los objetos de la clase Producto dentro de combo y seleccionar el deseado.

La forma de actuar es sencilla… añadir los objetos de Producto en el combo.

Producto producto = new Producto(parámetros);

JComboBox jcb = new JComboBox();

jcb.addItem(producto);

y, cuando lo necesitemos, recuperar el producto seleccionado

Producto productoSeleccionado = (Producto) jcb.getSelectedItem();

Hasta aquí todo correcto pero… al cargar el listado de objetos en el combo vemos que el titulo mostrado es similar a este: ‘paquete1.paquete2.Producto@idDelObjeto’. Y surge la duda: ¿podemos cambiar el texto mostrado? Evidentemente la respuesta es sí. Lo único que hay que hacer es sobreescribir en la clase Producto el método toString de Object. Recordemos que esta clase es de la que heredan de manera implícita todas las clases en Java. Por tanto, sólo tendremos que añadir este método en Producto:

public String toString(){

return “nuevo texto”;

}

clave1 = valor1

clave2 = valor2

….

Veámos como podemos acceder fácilmente a cada uno de esos valores.

(Supongo que ya tenemos creado en Eclipse un proyecto Java)

1. Creamos en la raíz del proyecto el fichero de propiedades “ficheroPropiedades.properties”.
2. Rellenamos este con los valores que se desee, por ejemplo nombre=Miguel Ángel Guillén.
3. Creamos una nueva clase FicheroPropiedades dentro del paquete ucam.clase4
4. Dentro del método “main” destacamos el siguiente código

//Nombre del fichero que contiene las propiedades.

String nombreFichero = “ficheroPropiedades.properties”;

//Objeto de la clase Properties donde se carga el listado de propiedades que hay en el fichero de propiedades.

Properties prop = new Properties();

//Se cargan las propiedades en el objeto ‘prop’. Como el método ‘load’ espera un objeto de una clase que herede de  InputStream utilizamos FileInputStream. De esta forma se puede leer del fichero ya que FileInputStream se encarga de ello.

prop.load(new FileInputStream(nombreFichero));

//Recuperamos el valor de la propiedad ‘nombre’ y lo mostramos por la salida estándar.

System.out.println(“Propiedad: “+prop.getProperty(“nombre”));

Al ejecutar este código se mostrará por pantalla el texto “Miguel Ángel Guillén”, que es el valor de propiedad “nombre”.

Adjunto un zip que incluye el proyecto Eclipse con el código de esta entrada (Workspace Properties).

La respuesta sería no siempre y cuando se hiciera lo propio con otros servicios, por ejemplo los seiscientos y pico consejeros del presidente, los ministerios de desigualdad y política territorial, el sueldo de sus señorías, … y un largo etcétera al que todos podríamos añadir algo.

Desde otro punto de vista, se puede argumentar que el gasto en I+D hay que mantenerlo en tiempos de crisis como caldo de cultivo para salir de ella. Yo me inclino más hacia esta postura, aunque tendría que haber un listado de proyectos subvencionados en el que se incluya el gasto y los resultados obtenidos; así como una dirección de correo electrónico para poder pedirles explicaciones si se han gastado mi dinero en algo ridículo. No está la cosa para ir tirando el dinero.

En fin… que si ZP no se recorta el sueldo y tampoco se quita consejeros lo menos que podría hacer es mantener el gasto en I+D para intentar salir de la crisis con nuevas iniciativas y no sólo pagando reformas de parques y jardines.

El otro día en clase estuvimos hablando sobre los métodos ágiles y, entre ellos, de la programación extrema. Quedó pendiente que los alumnos buscaran información sobre las 12 prácticas que este proceso de desarrollo establece. A petición de ellos pongo el listado pero con la condición de crear otra entrada con las conclusiones obtenidas

Retroalimentación a escala fina

• Desarrollo guiado por pruebas
• Juego Planificación
• On site Customer
• Programación en parejas.

Proceso continuo en lugar de por lotes

• Integración continúa
• Recodificación
• Pequeñas versiones

• Diseño simple
• Metáfora del sistema
• Propiedad colectiva código
• Estándares de codificación

Bienestar del programador

• Semana de 40 horas

Nosotros lo haremos contra una base de datos MySQL. Y para ello necesitaremos el driver que descargaremos de la web de MySQL. Sólo hay que copiar el fichero mysql-connector-java*.jar en el directorio WEB-INF/lib/.

Veamos dos formas diferentes de realizar una conexión. Aunque nos quedaremos con la segunda siempre es bueno conocer otras opciones menos válidas y saber los motivos.

Opción 1: En el servlet Control

1. Creamos un atributo para la conexión
   • private Connection Conexion = null;
2. Creamos un método estático getConexion que devuelva una conexión con la base de datos, creándola si no existe.
3. Sobreescribimos el método destroy para asegurarnos que se cierra la conexión con la base de datos una vez que se destruye el servlet.

Esta opción tiene algunos inconvenientes:

• La conexión puede quedarse abierta hasta que se destruye el servlet. La solución sería cerrarla cada vez que terminamos de hacer una transacción pero esto conlleva abrir y cerrar varias veces en una misma petición si se realizan varias consultas.
• No tenemos control sobre la conexión si se produce una excepción.
• Son las clases que hacen uso de la conexión las encargadas de abrir y cerrar. Esto no es del todo correcto.
• Y el más importante. Estamos utilizando un atributo y un método estáticos y, por tanto, la conexión es compartida por peticiones.

Opción 2: Utilizando un hilo local

Si queremos solucionar el último inconveniente debemos utilizar hilos locales. ¿Como se hace eso? Muy fácil. (Esta página lo explica).

Como en otras ocasiones, os dejo el fichero de la clase (ucam.servlets.Singleton) que hace uso de esta funcionalidad y hago unos comentarios sobre el código.

Lo primero que cabe destacar es que dentro de la propia clase Singleton se ha declarado otra,  ThreadLocalConnection, que hereda de ThreadLocal. ¿Que se consigue con esto? Encapsular un Object (o cualquier subclase de esta) y devolver una instancia distinta dependiendo del ObjectId del objeto que la solicita. Es decir, si la clase ThreadLocalConnection guarda un objeto de la clase Connection, dependiendo del objeto que invoque el método get de la primera, esta devolverá una instancia u otra de la segunda. Y, por tanto, dos conexiones diferentes.

Esto es válido para Tomcat ya que el objeto HttpServletRequest que representa la petición es distinto para cada una de ellas. Así, al hacer get sobre ThreadLocalConnection obtendremos un objeto conexión diferente para cada petición.

Bueno… eso no es del todo cierto ya que Tomcat reutiliza los objetos que representan las peticiones. Es decir, el servidor tiene varias instancias de la clase RequestFacade (que encapsula el objeto HttpServletRequest implementación de ServletRequest) y cuando le llega una petición coge una y la pasa como parámetro al servlet. Nuestro esquema sigue funcionando ya que a Tomcat nunca se le ocurre utilizar el mismo objeto petición para dos peticiones concurrentes. Por lo que al hacer Singleton.getConexion() lo estamos haciendo desde objetos diferentes y ThreadLocal devolverá conexiones distintas.

Es importante utilizar un filtro y así hacer commit o rollback al terminar la petición. Como se reutiliza el objeto petición y, por tanto el objeto conexión, todas las operaciones de peticiones anteriores habrán sido confirmadas o eliminadas. Esto lo mejoraremos más adelante utilizando un pool de conexiones. Este es el código para la clase ucam.filtros.FiltroConexion. Como se puede observar se cierra la conexión si esta fue abierta haciendo previamente commit o rollback.

El segundo punto a destacar es que se ha creado un atributo de la clase ThreadLocalConnection que será utilizado en el método getConexion para recuperar el objeto Connection que encapsula.

El método getConexion devuelve una conexión a la base de datos. Primero comprueba que existe una instancia de ThreadLocalConnection y si no la crea. Una vez que ya disponemos de la instancia lo que hacemos es solicitar, mediante el método get, el objeto de Connection. Que, como ya hemos comentado, será diferente para cada objeto petición. Por ejemplo, al hacer Singleton.getConexion() en un modelo que se está ejecutando desde una petición con id 45 el ThreadLocalConnection devolverá una instancia de Connection. Mientras que para un modelo sobre la instancia con id 12 devolverá otra.

Un punto importante dentro de getConexion es que se comprueba que la conexión no esté cerrada o sea null. Es decir, peticiones anteriores la cerraron. En cuyo caso se guarda la conexión mediante el método set. Al cual se le pasa como parámetro la instancia que devuelve el método initialValue. Este es invocado cada vez que se inicia una nueva instancia del objeto contenido en ThreadLocal.

Utilizar un pool de conexiones

Junto con las dos opciones anteriores se puede utilizar un sistema que gestione las conexiones en vez de crear una nueva cada vez. De tal forma que nuestra aplicación vaya a él, pida una conexión y, si hay alguna disponible, se la sirva.

Con esto se mejora el rendimiento ya que la conexión está disponible y no hay que estar abriendo y cerrándola. Es importante destacar que cuando desde la aplicación invocamos el método close realmente no se cierra si no que vuelve al pool y pasa a estar disponible para otra petición.

¿Como lo vamos a hacer? En Tomcat se utiliza un recurso de tipo fuente de datos (DataSource).

Utilizar un recurso

El código necesario para declarar un recurso es:

<Resource name=”jdbc/miServidor“ auth=”Container“ type=”javax.sql.DataSource“ driverClassName=”org.gjt.mm.mysql.Driver“ url=”jdbc:mysql://localhost:3306/sia“ username=”“ password=”“ maxActive=”20“ maxIdle=”10“ maxWait=”-1“ defaultAutoCommit=”false” removeAbandoned=”true” removeAbandonedTimeout=”20″ />

NOTA: cuidado al copiar y pegar. La codificación de las comillas no es correcta y puede producirse un error al arrancar Tomcat. Si esto sucede borrar y volver a poner todas las comillas dobles.

De entre todos los parámetros caben destacar:

• maxActive: El número máximo de conexiones activas que puede haber en el pool. Si se supera no se sirven más peticiones hasta que se libere alguna de las ocupadas.
• maxIdle: El número máximo de conexiones que estarán esperando a ser asignadas. Deberá de ser menor que el anterior.
• maxWait: El número de milisegundos que se esperará a que la aplicación devuelva la conexión antes de lanzar una excepción.
• removeAbandoned: Activar/Desactivar la funcionalidad para que Tomcat considere automaticamente que una conexión ha sido abandonada.
• removeAbandonedTimeout: El número de segundos que espera el pool para considerar una conexión como abandonada.
  

Y tenemos diferentes sitios donde incluirlo:

• En el server.xml del servidor (no de la aplicación, está en la carpeta /tomcat/conf/) buscar la etiqueta (“context”) donde se declara el contexto de nuestra aplicación e incluirla como una subetiqueta.
• Si está, en el fichero nombreAplicacion.xml que hay en /tomcat/conf/Catalina/localhost/.

Para el primer caso se puede hacer directamente en Eclipse:

1. Botón derecho sobre el nombre del proyecto, Propiedades -> Tomcat
2. En la pestaña General dentro del área de texto “Información Extra” incluimos el texto donde se declara el recurso.
3. Botón Aplicar y OK.
4. Nuevamente botón derecho sobre el nombre del proyecto, Tomcat project -> Update context definition.
5. Copiamos el .jar con el driver de MySQL en el directorio TOMCAT_HOME/lib.

Por eso en la clase Singleton aparece este código:

Context context = new InitialContext();

DataSource dataSource = (DataSource) context.lookup(“java:comp/env/jdbc/miServidor”);

connection = dataSource.getConnection();

siendo “jdbc/miServidor” el texto que hemos puesto al declarar el recurso.

Cuando desde el modelo o en nuestro caso desde el Singleton se haga connection.close() la conexión quedará disponible para futuras peticiones.

Crear el filtro

Para crear un filtro debemos implementar la interfaz javax.servlet.Filter.

1. Creamos el paquete ucam.filtros
2. Añadimos una nueva clase FiltroConexion que implemente la interfaz Filter
   1. Si estamos utilizando Eclipse automáticamente aparecen los métodos init, destroy y doFilter. En el API está toda la información sobre cuando se ejecuta cada uno de ellos.
3. En el método doFilter ponemos:

System.out.println(“Filtrando conexion”);

arg2.doFilter(arg0, arg1);

System.out.println(“Final de la petición”);

La segunda sentencia se pone para que siga la ejecución de la petición. En teoría puedes encadenar distintos filtros.

Configurar web.xml

Ahora hay que “decirle” a nuestra aplicación que filtre todas las peticiones que vayan al servlet Control. Para lo cual añadimos el siguiente código en el web.xml:

<filter>
<filter-name>Filtro</filter-name>
<filter-class>ucam.filtros.FiltroConexion</filter-class>
</filter>

<filter-mapping>
<filter-name>Filtro</filter-name>
<servlet-name>Control</servlet-name>
</filter-mapping>

Ya sólo queda modificar el código del filtro para que realice la funcionalidad deseada.

Existen muchas opciones pero tal vez la más recomendable sea aplicar el patrón Modelo-Vista-Control. ¿Y en que consiste? Pues muy fácil, que todas las peticiones pasen por un único punto, Control, que dependiendo de la acción a realizar ejecutará un modelo u otro. Este modelo redirige la petición hacia la vista (una JSP) correspondiente.

El siguiente diagrama de secuencia representa este escenario.

El navegador hace una petición al Control indicándole por parámetro que acción quiere ejecutar. En el ejemplo es aquella que está identificada con el 43. Con ese identificador el servlet deberá obtener la clase que implementa la acción, crear una instancia y ejecutar el método correspondiente.

Por ejemplo, si nosotros tenemos establecido en la base de datos o en un fichero de propiedades que la acción 43 está implementada por la clase ModeloMostrarClientes. El servlet mediante reflexión creará una instancia de dicho objeto e invocará el método ejecutar:

String clase = (bbdd o fichero propiedades).getClaseParaEsteId(idAccion);
Modelo m = (Modelo) Class.forName(clase).newInstance();
m.ejecutar();

En la primera linea se recupera el nombre de la clase para ese id (ucam.modelos.ModeloMostrarClientes). En la segunda se crea una instancia de la clase que por polimorfismo puede estar ligada a una variable de la clase padre, Modelo. En la última lo que hacemos es invocar el método ejecutar de la clase Modelo pero realmente se está ejecutando en la instancia de la subclase (ModeloMostrarClientes).

¿Que hemos ganado con esto? Independizar el servlet Control de la acción que se ejecuta en cada momento. Si nosotros establecemos que el id 29 se corresponde con ModeloInsertarCliente sólo tendremos que llamar al servlet pero con el parámetro idAccion con dicho valor. Además, si queremos añadir nueva funcionalidad sólo tendremos que heredar de Modelo e implementar el método ejecutar con la funcionalidad deseada.

Ya sólo queda redirigir a la JSP que genera la página. Existen dos opciones: que el método ejecutar reciba como parámetro la petición (HttpServletRequest) para hacer el forward o que devuelva una cadena con la página y que sea el servlet el que haga el forward.