ADF, el modelo I

Cómo ADF Implementa el modelo es fácil de comprender para un programador de forms. Digamos que tienes que decirle al sistema con qué tablas vas a trabajar. Luego crearíamos “un bloque” por cada “formulario” distinto que queramos hacer. Si los “formularios” que utilizan el “bloque” tienen el mismo comportamiento respecto a los registros (son el mismo conjunto, están ordenados según los mismos criterios, tienen los mismos campos, etc) entonces podemos aprovecharlos. Es como si en forms pudiésemos hacer por un lado los formularios y por otro los bloques de datos.

Cómo ADF Implementa el modelo es fácil de comprender para un programador de forms. Digamos que tienes que decirle al sistema con qué tablas vas a trabajar. Luego crearíamos “un bloque” por cada “formulario” distinto que queramos hacer. Si los “formularios” que utilizan el “bloque” tienen el mismo comportamiento respecto a los registros (son el mismo conjunto, están ordenados según los mismos criterios, tienen los mismos campos, etc) entonces podemos aprovecharlos. Es como si en forms pudiésemos hacer por un lado los formularios y por otro los bloques de datos.

Para las tablas se crean unas envolturas que se denominan objetos entidad (Entity Object). Como ya dije, el objetivo de estos objetos es definir cómo se hacen las operaciones DDL sobre la tabla, cuáles son los labels, hints y validaciones de formato. Se definene de forma unitaria y son válidas para cualquier lugar de la aplicación donde se desee operar sobre la tabla. Sin embargo, estos objetos de entidad no se pueden utilizar directamente en las pantallas. Para hacer los formularios utilizaremos objetos de vista, el pseudoequivalente a un bloque. Hay dos subtipos de objeto de vista, los de modificación, que van necesariamente ligados a un objeto de entidad y los de solo consulta, que van por libre. Para unos y otros podemos definir labels, hints y validaciones de formato que sobrescriban las del objeto de entidad. Así si en un determinado “bloque” queremos que un campo tenga un label particular, se lo podemos fijar en su objeto de vista.

Las vistas de tablas relacionadas por claves agenas tiene objetos de relación. Y esto es también muy parecido a cómo se enlazan bloques en forms. De todas formas las crea el asistente solo.

¿Cómo podemos decirle a ADF nuestra forma particular de insertar, actualizar, borrar, consultar, etc?. Pues hay que seleccionar el objeto de entidad cuyo comportamiento queremos sobrescribir y hacer doble click sobre él en el navegador de aplicaciones. En la ventana que nos sale debemos seleccionar en el arbolillo de la izquierda donde pone “java”.
Veremos que se muestran estas opciones:

Opciones java del objeto entidad
Si marcamos “Data manipulation Methods” nos creará este código en el fichero <Nombre entidad>Impl.java:

/** 
   * 
   *  Custom DML update/insert/delete logic here. 
   */ 
  protected void doDML(int operation, TransactionEvent e) 
  { 
    super.doDML(operation, e); 
  }

Pues nosotros podemos hacer cualquier cosa antes del doDML o después, o incluso quitar el doDML y hacer otra cosa.Si marcamos “Validation method” crea igualmente en el mismo fichero un procedimiento que podemos programar para que se realicen las validaciones que queramos. Sería un equivalente a un when-validate-record:

  /** 
   * 
   *  Add Entity validation code in this method. 
   */ 
  protected void validateEntity() 
  { 
    super.validateEntity(); 
  }

Es fácil imaginar ya qué hacen los checks “Create method” y “Remove method”. Son, como ya habréis adivinado, los equivalentes a key-crerec y key-delrec.

Anuncios