Javatadas

MVC(III-bis): Modelos dinamicos de Forms

Continuando con el patrón MVC,Akuma preguntaba, en los comentarios a un post de Al como se creaban los Forms, y como estos se rellenaban dinamicamente.
Aprovechando la temática del post de Al, modelos dinámicos de Objetos, contesto a Akuma apostando por los Modelos Dinámicos de Forms.

Un Form es una clase que representa, en nuestro modelo de clases, al formulario html en el que el usuario ha introducido sus datos. Esta clase se puede implementar de dos formas:

• JavaBeans (aproximación de Structs): De esta forma, las entradas de formulario (campos input) se representan como propiedades del JavaBean. Por tanto, para crear un formulario de login, a partir de una clase abstracta AbstractForm deberiamos crear una subclase tal que así:
  public class LoginForm extends AbstractForm{
  

  private String login;
  private String password;
  private double ejemploConversionDouble;
  

  }
  Seguidamente, estas propiedades se pueden rellenar con un metodo tal que así:
  public void initialize(HttpServletRequest request) throws ConversionException{
  

  try{
  

  ejemploConversionDouble = Double.valueOf(request.getParameter("ejemploConversionDouble")).doubleValue();
  

  }cath(Exception e){
  return new ConversionException("Error en conversion");
  

  }
  }
  Esto en realidad seria mas elaborado y generico, utilizando reflexion para descubrir las propiedades del Bean, y envolviendo el HttpRequest con una clase (Canyamo la llama WorkData) que nos independice de éste (por ejemplo para reutilizar comandos en aplicaciones Swing).


• Formularios Dinámicos (Dynabeans):la idea seria la misma que la de los modelos dinámicos de objetos, defendidos por Al en su último post.
  Creamos un modelo de clases de "metadatos", formado por ejemplo por Form, FormProperty y FormPropertyType. Un FormPropertyType acotaría los tipos de datos que puede manejar un Form, y sería algo así:
  public FormPropertyType{
  {

  private String nombreTipoDato;
  private Class claseTipoDato;
  private Object defaultValue;
  

  }
  Gracias a esto, podemos meter tipos compuestos. Es mas, esta clase tb es de utilidad para crear modelos dinamicos de objetos de persistencia -acotando lo que podemos guardar, y mapeando con el RDBMS que estemos trabajando.
  Un FormProperty sería la combinación de un tipo, un nombre, y una serie de restricciones:
  public class FormProperty{
  

  private String nombreEntradaForm;
  private FormPropertyType tipoDato;
  private Object value;
  private List listaValidaciones;
  

  public boolean validate(){
  boolean solucion = true; int index = 0; while(solucion && index < listaValidaciones.size()){
  

  Chequeo check = (ChequeoIF)listaValidaciones.get(i);
  seguir = check.check();
  index++;
  

  }
  }
  Y un Form estaria formado por un conjunto de FormPropertys guardados en un HashMap, para poder recuperarlos a partir de su nombre. De esta forma, nos podremos crear nuestros Form a partir de un documento XML, y cambiarlos sin tener que recompilar (MISMA IDEA QUE LOS MODELOS DINAMICOS DE OBJETOS)

Los comandos MVC (Acciones, o como lo que queramos llamar) reciben estas instancias de Form (cada vez que llega una peticion, el Controller recupera un Form, y devuelve un form.clone() para evitar que interaccionen los de unos usuarios con otros) y de estas toman sus datos de entrada.
Ojo!! Al hacer Form cloneable, debe ser un clone() duro (SIN COPIAR LOS PUNTEROS) lo que implica hacer clone() con todas las FormProperty.
Todo esto es dicho por encima, considerando solo los conceptos.
Luego se añaden complicaciones tales como vincular los Form con los formularios html (p.e, chequeos que no se pasan, el formulario html debe recordar los valores introducidos por el usuario), etc. etc.

(2003-09-01 10:51:42.0) Permalink Comentarios [7]