a Freelance Web Developer

El equipo de Constela estamos muy animados trabajando en una aplicación para Internet a la que llamamos “El Tronco”. El Tronco es un experimento de desarrollo de software social. Es una implementación completa de todas las funcionalidades básicas que una aplicación basada en comunidades debe tener.

Ahora mismo nos encontramos en el frágil, delicado y emocionante momento en el que necesitamos a un pequeño núcleo de gente voluntariosa que desee hacernos de betatester.

La función de betatester es muy sencilla. Se trata de entrar en la aplicación y usarla, usarla y usarla, y, cada vez que algo no os funcione bien: nos lo comunicáis, cada vez que veáis algo mejorable: nos lo comunicáis, cada vez que no entendéis algo: nos lo comunicáis, cada vez que os surja una sugerencia: nos lo comunicáis.

La labor del betatester debe resultarle divertida y/o interesante al que la realiza así que no te sientas obligado/a a participar en esta convocatoria si estas tareas no te van a resultar, a tu manera, gratificadoras, ya sea por satisfacer ese cosquilleo de curiosidad o por que te gusta la idea, o por lo que sea.

Hemos creado una especie de versión de nuestra aplicación para meterla en la habitación de pruebas y os la ofrecemos a todas aquellas personas que nos quieran hacer de betatester.

Esta versión de la aplicación la queremos centrar en una temática: “las películas que nos gustan”, una especie de foro social con espacio para que te conviertas en crítico de cine amateur.

La aplicación la tenéis disponible aquí: micine.constela.es.

En esta primera fase de pruebas necesitamos que cada persona que se registre nos lo informe, o ya seremos nosotros/as quienes intenten ponerse en contacto con ella. Es muy necesario tener un núcleo de gente pequeño para no atosigar a la aplicación en esta fase tan embrionaria.

Para empezar con tu labor de betatester debes acceder a la aplicación: micine.constela.es y comenzar a navegar por ella. Seguramente al principio no le encuentres mucho sentido a nada e incluso esas sensaciones de desamparo y dudas también nos gustaría que nos las comentases.

Una vez que ya te has dado una vuelta por la aplicación quizás quieras registrarte y tener tu propio perfil y empezar a introducir comentarios en otros perfiles o incluso atreverte a subir tu propia crítica de película.

Tienes que ser paciente con la aplicación pero a la vez exigente, no debes desanimarte porque algo no ha funcionado bien pero sí tienes que expresarte e informarnos. Tampoco te sientas obligado/a a informarnos de todo lo que surja si eso va a hacerte desfallecer, quizás quieras navegar por la aplicación haciendo caso omiso de todos los errores y sugerencias y esperar a otro momento para empezar a informar.

Una cosa importante a tener en cuenta es que al ser una aplicación en estado de desarrollo no podemos ofrecer ningún tipo de seguridad de que no haya pérdida de datos ni de contenidos, si te vas a sentir mal porque llegas un día y algo de lo que escribiste ha desaparecido mejor no te arriesgues a hacernos de betatester. Aún así intentaremos crear copias de seguridad diarias de los contenidos.

No te esfuerces en extremo en que los contenidos que generes sean de muy buena calidad, lo importante ahora es usar la aplicación. Como ya he dicho antes: cualquier fallo en el sistema puede provocar la pérdida total de contenidos.

Por favor: siéntete libre de hacernos cualquier pregunta o proposición. Recuerda: la Internet 2.0 la haces tú.

Actualizado 14 de Agosto

Hemos creado un grupo en google groups para promover las conversaciones entre los desarrolladores y el grupo de betatester, siéntete libre de solicitarnos una subscripción.

El Grupo El Tronco.

Puedes solicitarnos una suscripción poniendo un comentario en este post o directamente en la página del Grupo El Tronco, o registrándote en la aplicación de pruebas: Registro en MiCine.

Struts tiene pegas, tiene grandes virtudes que hace que sigamos amándolo y respetándolo… hasta que Spring nos separe, pero tiene grandes pequeñas pegas.

Una de ellas es que cuando ‘un caso de uso’ requiere de uno o varios parámetros para iniciar la secuencia siempre se esperan como parámetros de la petición al estilo:

http://miaplicacion.com/peticion.do?parametro=valor

Mismamente el detalle de un registro o de un objeto cuya id se la pasamos por parámetro de la petición:

http://miaplicacion.com/detalle.do?id=1

Entonces nuestro Action recibe la petición y automáticamente carga el ActionForm asociado a partir de los parámetros, en este caso ‘id’.

Pero ¿qué pasa si quiero invocar a este ‘caso de uso’ desde otro Action al estilo?:

<forward name="exito" path="/detalle.do" />

Pues que no hay manera de pasarle el parámetro id a ese Action y el ActionForm no se cargará.

La solución más rápido es hacer que el Action sea ambidiestro y sea capaz de recibir valores tanto desde parámetros como desde un atributo de la ‘Request’ de tal manera que el Action origen que invoca a este Action destino cargue el valor que le quiere pasar en un atributo de la ‘Request’.

Esta solución tiene dos problemas:

* Se genera un montón de código basura en el inicio del Action para proporcionarle la capacidad de recoger valores desde las dos fuentes.

* No aprovechamos la funcionalidad de Struts para gestionar la auto-carga de valores.

* No se puede validar en formulario pues si enviamos los datos en los atributos de la Request el formulario ni se entera.

Entonces debemos buscar una solución más sólida, ágil y completamente reutilizable.

El RequestForm

Se trata de un ActionForm con la cualidad de buscar entre la Request actual atributos que coincidan con alguna de sus propiedades. Si el ActionForm encuentra el atributo con el mismo nombre que una de sus propiedades y también tiene un método ’set’ que recibe un objeto del mismo tipo que el valor contenido en el atributo de la Request entonces lo invoca y así sucesivamente hasta que el ActionForm se autorrellena.

Toda esta funcionalidad está encerrada en un método del RequestForm, pero este método no se invoca automáticamente así que hay que invocarlo a mano y hay que buscar un buen momento para hacerlo. Si miramos la secuencia con que Struts invoca a los métodos del ActionForm vemos que el mejor momento para invocar la carga de propiedades desde la Request es:

* Justo después del reset(). Los valores cargados desde la Request serán machacados con los valores que se encuentren entre los parámetros de la petición.

* Justo antes del validate(). Los valores cargados desde los parámetros de la petición serán sobrescritos por los valores encontrados en la Request.

Este es el ActionForm que se precarga rebuscando en la Request:

import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

import javax.servlet.http.HttpServletRequest;

import org.apache.log4j.Logger;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;

import com.constela.tronco.util.StringUtilities;
import com.us3.util.Util;

/**
 * <p>
 * </p>
 *
 * @internal_author fguillen@constelanetworks.com
 * @date 25/07/2007
 *
 */
public class RequestForm extends ActionForm {

	/**
	 * <p>
	 * This override for reset method invokes to chargeFromRequest
	 * this is the best place to invoke this method.
	 * </p>
	 * @date: 25/07/2007
	 * @author: fguillen@constelanetworks.com
	 *
	 * @param arg0
	 * @param arg1
	 */
	@Override
	public void reset(
		ActionMapping mapping,
		HttpServletRequest request
	) {

		super.reset( mapping, request );

		try {

			this.chargeFromRequest( request );

		}	catch ( Exception e ) {
			throw new Error( e );
		}

	}

	/**
	 * <p>
	 * Method that allows to the ActionForm to
	 * charge its fields from the Request's attributes
	 * </p>
	 *
	 * <p>
	 * The method will look for the fields on the ActionForm
	 * and will look for attributes on Request with the same name
	 * and will look for 'set' method on the ActionForm. If there exist
	 * both Request's attribute and 'set' method the 'set' method is invoked
	 * with the Request's attribute's value.
	 * </p>
	 *
	 * @date: 25/07/2007
	 * @author: fguillen@constelanetworks.com
	 *
	 * @param request
	 * @throws IllegalArgumentException
	 * @throws IllegalAccessException
	 * @throws InvocationTargetException
	 */
	public void chargeFromRequest(
		HttpServletRequest request
	) throws IllegalArgumentException, IllegalAccessException, InvocationTargetException{

		//
		// the fields of the ActionForm
		//
		Class c = this.getClass();
		Field[] fields = c.getDeclaredFields();

		//
		// walk throw the array of fields looking
		// for attributes on request with same name
		//
		for (int i = 0; i < fields.length; i++) {
			Field field = fields[i];

			String fieldName = field.getName();
			Object attributeValue =
				request.getAttribute( fieldName );			

			//
			// if attributeValue is not null
			// and the ActionForm has a set method
			// try to asign value to a field
			//
			if( attributeValue != null ){
				//
				// has it a public set method?
				//
				String methodSet =
					"set" +
					StringUtilities.capitalizeWord( fieldName );

				Method method = null;
				try{
					method =
						c.getDeclaredMethod(
							methodSet,
							new Class[] { attributeValue.getClass() }
						);
				} catch ( Exception e ) {
					// the method does not exists
				}

				if( method != null ){
					method.invoke(
						this,
						new Object[] { attributeValue }
					);
				}
			}
		}
	}
}

Entonces ahora, cada vez que queramos que un ActionForm sea capaz de precargarse desde la ‘Request’ debemos heredar de nuestro RequestForm y no directamente de ActionForm. Hay que acordarse que si sobrescribimos el método reset() en nuestra implementación hay que hacer una llamada a super.reset() al finalizar nuestras sentencias de reseteo.