Objetivos:• Explicar los efectos de la unidad de validación sobre un Forms.
• Ver los controles de Validación:
--Usando las propiedades de los Objetos.
--Usando Triggers.
--Usando componentes de Java.
--Usando las propiedades de los Objetos.
--Usando Triggers.
--Usando componentes de Java.
• Explicar como Forms le da seguimiento al estatus de validación .
• Controlar cuando ocurre la validación.
______________________________________________________________________________________
Proceso de Validación.
Niveles de Validación.
Forms realiza procesos de validación en varios niveles para garantizar que los registros y los valores individuales sigan las reglas apropiadas. Si la validación falla, el control pasa de nuevo al nivel en cuestión, de modo que el usuario puede realizar correcciones. La validación ocurre a:
• Nivel de Item: Forms registra el estado para cada Item con el fin de determinar si es actualmente válido. Si un Item ha sido cambiado y aún no se ha marcado como válido, entonces Forms primero realiza verificaciones de validación estándar para garantizar que el valor se ajuste a las propiedades del Item. Estas comprobaciones se llevan a cabo antes de disparar cualquier Trigger When-Validate-Item que haya definido. Las verificaciones estándar incluyen las siguientes:
--Formato de Máscara (Format Mask).
--Requerido (Required); si es así, entonces ¿Es el Item nulo?.
--Tipo de datos.
--Rango (valor permitido más bajo-más alto).
--Validar de la lista (ver más adelante en esta publicación).
• Nivel de Registro: después de dejar un registro, Forms comprueba si el registro es válido. De lo contrario, se verifica el estado de cada Item del registro, luego, se activa el Trigger When-Validate-Record (si está presente). Cuando el registro pasa estas comprobaciones, se establece como válido.
• Nivel de Bloque y Form: a nivel de Bloque o Form, todos los registros por debajo de ese nivel son validados. Por ejemplo, si confirma (guarda) cambios en el Form, todos los registros son validados, a menos que haya suprimido esta acción.
¿Cuándo ocurre la Validación?
Forms lleva a cabo la validación bajo las siguientes condiciones:
• Se presiona la tecla [Enter] o se ejecuta el built-in ENTER. El propósito del built-in ENTER es forzar la validación inmediatamente.
Nota: La acción ENTER no está necesariamente asignada a la tecla que está etiquetada físicamente como Enter.
• El usuario o un Trigger navega fuera de la unidad de validación. Esto incluye cuando se confirman los cambios. La unidad de validación predeterminada es el Item, pero también puede configurarse para el Registro (Record), Bloque o Form.
______________________________________________________________________________________
Uso de las Propiedades de Objetos para Controlar la Validación.
Puede controlar cuándo y cómo se produce la validación en un Form, incluso sin el uso de Triggers. Esto es posible estableciendo propiedades para el Form y para Items individuales dentro de él.
La Unidad de Validación (Validation Unit).
La unidad de validación define la cantidad máxima de datos que un usuario puede ingresar en el Form antes de que se inicie la validación. La unidad de validación es una propiedad del módulo Form, y se puede configurar en la Paleta de propiedades con los siguientes valores:
• Default.
• Item.
• Record.
• Block.
• Form.
La configuración predeterminada es Item.
En la práctica, una unidad de validación de nivel Item significa que Forms valida los cambios cuando un usuario cambia el valor de un Item y luego navega fuera. De esta forma, las comprobaciones de validación estándar y la activación del Trigger When-Validate-Item de ese Item se pueden hacer de inmediato. Como resultado, los usuarios son conscientes de la falla tan pronto como intentan abandonar el artículo.
En las unidades de validación más altas (nivel Record, Block o Form), las comprobaciones anteriores se posponen hasta que la navegación se desplace de esa unidad. Todos los items y registros pendientes se validan juntos, incluido los Triggers When-Validate-Item y When-Validate-Record.
Es recomendable establecer una unidad de validación por encima del nivel Item en una de las siguientes condiciones:
• La validación involucra referencias de bases de datos, y desea posponer el tráfico hasta que el usuario haya completado un registro (nivel de Record).
• La aplicación se ejecuta en Internet y desea mejorar el rendimiento al reducir los viajes al servidor de aplicaciones.
Usando LOVs para Validación
Cuando adjunta un LOV a un Text Item configurando la propiedad List of Values, puede opcionalmente usar el contenido del LOV para validar los datos ingresados en dicho Item.
Propiedad Validar de la Lista (Validate from List).
Para ello, establezca la propiedad Validate from List en Sí (Yes). Al momento de validación, Forms usa automáticamente el valor del Item como una cadena de búsqueda que no distingue entre mayúsculas ni minúsculas en el contenido del LOV. A continuación, se producen los siguientes eventos, según las circunstancias:
--Si el valor en el Item coincide con uno de los valores en la primera columna del LOV, la validación se realiza correctamente, el LOV no se muestra y el procesamiento continúa normalmente.
--Si el valor del Item hace que se encuentre un solo registro en el LOV, pero es un valor parcial del valor LOV, se devuelve el valor completo de la columna LOV al Text Item (siempre que el Text Item se defina como el Item de retorno del LOV) ) El Item luego pasa esta fase de validación.
--Si el valor del Item hace que se encuentren varios registros en el LOV, Forms muestra el LOV y utiliza el valor del Text Item como criterio de búsqueda para reducir automáticamente la lista, de modo que el usuario debe elegir.
--Si no se encuentra una coincidencia, entonces el contenido LOV completo se muestra al usuario.
Nota: asegúrese de que los LOVs que cree para fines de validación tengan la columna de validación definida primero, con un ancho de visualización mayor que 0. También debe definir el Item de Retorno (Return Item) para la columna LOV como el Item que se está validando.
Por razones de rendimiento, no use la propiedad LOV para Validar LOVs grandes.
______________________________________________________________________________________
Controlar la Validación Mediante el uso de Triggers.
Hay Triggers que disparan debido al proceso de validación, en estos es posible agregar acciones personalizadas. También hay algunos built-ins a los que puede invocar desde Triggers que afectan la validación.
Trigger When-Validate-Item.
Este Trigger se activa después de la validación estándar del Item, si dicho Trigger falla el foco de entrada se mantiene en el Item, lo cual obliga al usuario a introducir un valor valido.
Ejemplo:
IF :ORDERS.order_date > SYSDATE THEN
MESSAGE('Order Date is later than today!');
RAISE form_trigger_failure;
END IF;
/*El Trigger When-Validate-Item en :ORDERS.Order_Date, que se muestra arriba, garantiza que la Fecha del pedido no sea posterior a la fecha actual.*/
Trigger When-Validate-Record.
Este Trigger se activa después de la validación estándar del registro, cada vez que el usuario deja el registro en estado NEW o CHANGED. Una vez que Forms ya ha verificado que los Item Requeridos para el registro son válidos, puede usar este Trigger para realizar comprobaciones adicionales que pueden involucrar más de uno de los Items del mismo registro, en el orden en que se ingresaron.
Nota: When-Validate-Record debe definirse a nivel de Bloque o Form.
Ejemplo:
El Trigger When-Validate-Record en el bloque ORDER_ITEMS advierte al usuario cuando una línea de pedido para una nueva orden de crédito hace que se exceda el límite de crédito del cliente.
DECLARE
cred_limit number;
n number;
BEGIN
-- Order status of 4 is new credit order
IF :orders.order_status = 4 THEN
SELECT credit_limit INTO cred_limit FROM customers
WHERE customer_id = :orders.customer_id;
IF :control.total > cred_limit THEN
n := show_alert('credit_limit_alert');
END IF;
END IF;
END;
Nota: Si desea evitar que el usuario salga del Item cuando la validación falla, puede generar una excepción para el Trigger falle:
RAISE form_trigger_failure;
En el ejemplo anterior, incluiría este código inmediatamente después de mostrar la alerta.
Ejemplo: Validar la entrada del usuario.
Con frecuencia es necesario llenar un Item en especifico a partir del valor contenido en otro Item diferente, por ejemplo llenar el Item customer_name a partir del valor contenido en customer_id (se usa el customer_id para así traer el customer_name). Mientras se completa el Item customer_id, si el usuario ingresa un valor inválido, el proceso de extracción del customer_name no encontrará una fila que coincida, y la sentencia SELECT causará una excepción. El éxito o el fracaso de la consulta pueden, por lo tanto, usarse para validar la entrada del usuario.
Las excepciones que pueden ocurrir cuando una fila individual no es retornada desde un SELECT son:
• NO_DATA_FOUND: no se devuelven filas en la consulta.
• TOO_MANY_ROWS: se devuelve más de una fila en la consulta.
El siguiente Trigger When-Validate-Item del Item customer_id es el ejemplo antes mencionado; En él, se trata de extraer el nombre que corresponde a la identificación del cliente ingresada por el usuario para luego asignarlo al Item customer_name.
SELECT cust_first_name ||' '|| cust_last_name
INTO :ORDERS.customer_name
FROM clientes
WHERE customer_id =: ORDERS.customer_id;
Si el Item Customer_ID contiene un valor que no se encuentra en la tabla, se genera la excepción NO_DATA_FOUND y el Trigger fallará porque no existe un controlador de excepciones para evitar que la excepción se propague.
Nota: Un Trigger When-Validate-Item fallido impide que el cursor (focus) deje el Item en cuestión.
Cuando ocurre una excepción no controlada, como se indicó anteriormente, el usuario recibe el mensaje:
FRM-40735: <trigger type> trigger raised unhandled exception <exception>
______________________________________________________________________________________
Validación Client-Side.
Es una práctica común procesar la entrada a un Item usando un Trigger When-Validate-Item. Debe tener en cuenta que el Trigger en sí se procesa en los Servicios de Forms (Forms Services). Incluso la validación que se produce con una máscara de formato en un Item implica un viaje al nivel medio (middle tier). En el primer ejemplo de la imagen anterior, la verificación del tipo de dato del Item Quantity se realiza cuando el operador presiona [Enter] para enviar la info al Servidor Forms, en este escenario el error FRM-50016 es retornado.
Puede también considerar el uso de Pluggable Java Components (PJCs) para reemplazar la funcionalidad predeterminada de los Items. Al hacer esto, la validación de los Items, como la fecha o los valores máximos o mínimos, está contenida dentro del mismo Item. Esta técnica abre oportunidades para realizar validaciones más compleja, le permite hacer validaciones específicas de la aplicación como el formateo automático de la entrada, como números de teléfono con formato (XXX) XXX-XXXX. Incluso un formato numérico simple es realizado al instante, sin permitir que se ingresen pulsaciones de teclas alfabéticas en el Item numérico.
Esta validación se realiza en el lado cliente (Client-Side) sin la necesidad de realizar un viaje de ida y vuelta en la red, mejorando así el rendimiento. En el segundo ejemplo, KeyFilter PJC no permite que el operador ingrese un carácter alfabético en el Item Quantity. El único mensaje que se muestra en la línea de mensaje es el Item's Hint (Sugerencia).
Los Pluggable Java Components (PJCs) son similares a los JavaBeans, y de hecho, los dos términos se usan indistintamente. Aunque ambos son componentes de Java que puede usar en un Forms, existen las siguientes diferencias entre ellos:
Los JavaBeans se implementan en un Item Bean Area, mientras que los PJC se implementan en un Item cualquier de Forms, Eje: Text Item o Check Box.
Los PJC siempre deben tener la clase de implementación especificada en la Paleta de propiedades, mientras que los JavaBeans pueden registrarse en el tiempo de ejecución con el paquete FBean.
Implementando los PJC.
Para implementar un PJC debe establecer la propiedad Clase de Implementación (Implementation Class) del Item con la clase del PJC. También puede usar el built-in SET_CUSTOM_PROPERTY para establecer las propiedades del PJC que restringen la entrada y/o validan el Item. En tiempo de ejecución, Forms busca la clase Java contenida en el nivel medio o en los archivos con la ruta especificada en la clase de implementación. Si abre keyfilter.jar en WinZip, encontrará que su ruta es oracle\forms\demos.
La implementación del PJC es igual a la de un JavaBean, este último discutido en esta publicación:
Puede ubicar el archivo de clase Java:
• En el servidor de nivel medio, ya sea en la estructura de directorios a la que hace referencia el parámetro CODEBASE del applet de Forms o en el CLASSPATH del servidor. De forma predeterminada CODEBASE es el subdirectorio forms90\java de ORACLE_HOME.
• Si usa JInitiator, en un archivo JAR en el directorio CODEBASE del servidor de nivel medio, e incluido en el parámetro ARCHIVE para que el archivo JAR se descargue y almacene en caché en el cliente. Por ejemplo: archive_jini=f90all_jinit.jar, keyfilter.jar
(Los parámetros CODEBASE y ARCHIVE se establecen en el archivo formsweb.cfg).
______________________________________________________________________________________
Estatus de Validación.
Cuando Forms deja un objeto, por lo general valida cualquier cambio que se haya realizado en el contenido del mismo. Para determinar si se debe realizar la validación, Forms realiza un seguimiento del estatus de validación de los Items y Registros (Records).
Estatus de Validación para Items.
Estatus de Validación para Registros.
______________________________________________________________________________________
Uso de Built-ins para controlar la Validación.
Puede usar los siguientes built-ins en Triggers para afectar la validación.
• CLEAR_BLOCK, CLEAR_FORM y EXIT_FORM
El primer parámetro de estos built-ins, COMMIT_MODE, controla la acción a tomar cuando hay cambios no aplicados ya sea que se limpie el bloque (CLEAR_BLOCK), el Forms (CLEAR_FORM) o cuando se abandona Forms (EXIT_FORM). Cuando el parámetro se establece en NO_VALIDATE, los cambios no se validan ni se aplican (de manera predeterminada, se solicita al usuario la acción a tomar).
• Propiedad ITEM_IS_VALID.
Puedes usar los built-ins GET_ITEM_PROPERTY y SET_ITEM_PROPERTY con el parámetro ITEM_IS_VALID para obtener o establecer el estado de validación de un artículo. No puede obtener y configurar directamente el estado de validación de un registro. Sin embargo, puede obtener o establecer el estado de validación de todos los elementos en un registro.
• ENTER
El built-in ENTER realiza la misma acción que la tecla [Enter]. Es decir, fuerza la validación de datos en la unidad de validación actual.
Forms realiza procesos de validación en varios niveles para garantizar que los registros y los valores individuales sigan las reglas apropiadas. Si la validación falla, el control pasa de nuevo al nivel en cuestión, de modo que el usuario puede realizar correcciones. La validación ocurre a:
• Nivel de Item: Forms registra el estado para cada Item con el fin de determinar si es actualmente válido. Si un Item ha sido cambiado y aún no se ha marcado como válido, entonces Forms primero realiza verificaciones de validación estándar para garantizar que el valor se ajuste a las propiedades del Item. Estas comprobaciones se llevan a cabo antes de disparar cualquier Trigger When-Validate-Item que haya definido. Las verificaciones estándar incluyen las siguientes:
--Formato de Máscara (Format Mask).
--Requerido (Required); si es así, entonces ¿Es el Item nulo?.
--Tipo de datos.
--Rango (valor permitido más bajo-más alto).
--Validar de la lista (ver más adelante en esta publicación).
• Nivel de Registro: después de dejar un registro, Forms comprueba si el registro es válido. De lo contrario, se verifica el estado de cada Item del registro, luego, se activa el Trigger When-Validate-Record (si está presente). Cuando el registro pasa estas comprobaciones, se establece como válido.
• Nivel de Bloque y Form: a nivel de Bloque o Form, todos los registros por debajo de ese nivel son validados. Por ejemplo, si confirma (guarda) cambios en el Form, todos los registros son validados, a menos que haya suprimido esta acción.
¿Cuándo ocurre la Validación?
Forms lleva a cabo la validación bajo las siguientes condiciones:
• Se presiona la tecla [Enter] o se ejecuta el built-in ENTER. El propósito del built-in ENTER es forzar la validación inmediatamente.
Nota: La acción ENTER no está necesariamente asignada a la tecla que está etiquetada físicamente como Enter.
• El usuario o un Trigger navega fuera de la unidad de validación. Esto incluye cuando se confirman los cambios. La unidad de validación predeterminada es el Item, pero también puede configurarse para el Registro (Record), Bloque o Form.
______________________________________________________________________________________
Uso de las Propiedades de Objetos para Controlar la Validación.
Puede controlar cuándo y cómo se produce la validación en un Form, incluso sin el uso de Triggers. Esto es posible estableciendo propiedades para el Form y para Items individuales dentro de él.
La Unidad de Validación (Validation Unit).
La unidad de validación define la cantidad máxima de datos que un usuario puede ingresar en el Form antes de que se inicie la validación. La unidad de validación es una propiedad del módulo Form, y se puede configurar en la Paleta de propiedades con los siguientes valores:
• Default.
• Item.
• Record.
• Block.
• Form.
La configuración predeterminada es Item.
En la práctica, una unidad de validación de nivel Item significa que Forms valida los cambios cuando un usuario cambia el valor de un Item y luego navega fuera. De esta forma, las comprobaciones de validación estándar y la activación del Trigger When-Validate-Item de ese Item se pueden hacer de inmediato. Como resultado, los usuarios son conscientes de la falla tan pronto como intentan abandonar el artículo.
En las unidades de validación más altas (nivel Record, Block o Form), las comprobaciones anteriores se posponen hasta que la navegación se desplace de esa unidad. Todos los items y registros pendientes se validan juntos, incluido los Triggers When-Validate-Item y When-Validate-Record.
Es recomendable establecer una unidad de validación por encima del nivel Item en una de las siguientes condiciones:
• La validación involucra referencias de bases de datos, y desea posponer el tráfico hasta que el usuario haya completado un registro (nivel de Record).
• La aplicación se ejecuta en Internet y desea mejorar el rendimiento al reducir los viajes al servidor de aplicaciones.
Usando LOVs para Validación
Propiedad Validar de la Lista (Validate from List).
Para ello, establezca la propiedad Validate from List en Sí (Yes). Al momento de validación, Forms usa automáticamente el valor del Item como una cadena de búsqueda que no distingue entre mayúsculas ni minúsculas en el contenido del LOV. A continuación, se producen los siguientes eventos, según las circunstancias:
--Si el valor en el Item coincide con uno de los valores en la primera columna del LOV, la validación se realiza correctamente, el LOV no se muestra y el procesamiento continúa normalmente.
--Si el valor del Item hace que se encuentre un solo registro en el LOV, pero es un valor parcial del valor LOV, se devuelve el valor completo de la columna LOV al Text Item (siempre que el Text Item se defina como el Item de retorno del LOV) ) El Item luego pasa esta fase de validación.
--Si el valor del Item hace que se encuentren varios registros en el LOV, Forms muestra el LOV y utiliza el valor del Text Item como criterio de búsqueda para reducir automáticamente la lista, de modo que el usuario debe elegir.
--Si no se encuentra una coincidencia, entonces el contenido LOV completo se muestra al usuario.
Nota: asegúrese de que los LOVs que cree para fines de validación tengan la columna de validación definida primero, con un ancho de visualización mayor que 0. También debe definir el Item de Retorno (Return Item) para la columna LOV como el Item que se está validando.
Por razones de rendimiento, no use la propiedad LOV para Validar LOVs grandes.
______________________________________________________________________________________
Controlar la Validación Mediante el uso de Triggers.
Hay Triggers que disparan debido al proceso de validación, en estos es posible agregar acciones personalizadas. También hay algunos built-ins a los que puede invocar desde Triggers que afectan la validación.
Trigger When-Validate-Item.
Este Trigger se activa después de la validación estándar del Item, si dicho Trigger falla el foco de entrada se mantiene en el Item, lo cual obliga al usuario a introducir un valor valido.
Ejemplo:
IF :ORDERS.order_date > SYSDATE THEN
MESSAGE('Order Date is later than today!');
RAISE form_trigger_failure;
END IF;
/*El Trigger When-Validate-Item en :ORDERS.Order_Date, que se muestra arriba, garantiza que la Fecha del pedido no sea posterior a la fecha actual.*/
Trigger When-Validate-Record.
Este Trigger se activa después de la validación estándar del registro, cada vez que el usuario deja el registro en estado NEW o CHANGED. Una vez que Forms ya ha verificado que los Item Requeridos para el registro son válidos, puede usar este Trigger para realizar comprobaciones adicionales que pueden involucrar más de uno de los Items del mismo registro, en el orden en que se ingresaron.
Nota: When-Validate-Record debe definirse a nivel de Bloque o Form.
Ejemplo:
El Trigger When-Validate-Record en el bloque ORDER_ITEMS advierte al usuario cuando una línea de pedido para una nueva orden de crédito hace que se exceda el límite de crédito del cliente.
DECLARE
cred_limit number;
n number;
BEGIN
-- Order status of 4 is new credit order
IF :orders.order_status = 4 THEN
SELECT credit_limit INTO cred_limit FROM customers
WHERE customer_id = :orders.customer_id;
IF :control.total > cred_limit THEN
n := show_alert('credit_limit_alert');
END IF;
END IF;
END;
Nota: Si desea evitar que el usuario salga del Item cuando la validación falla, puede generar una excepción para el Trigger falle:
RAISE form_trigger_failure;
En el ejemplo anterior, incluiría este código inmediatamente después de mostrar la alerta.
Ejemplo: Validar la entrada del usuario.
Con frecuencia es necesario llenar un Item en especifico a partir del valor contenido en otro Item diferente, por ejemplo llenar el Item customer_name a partir del valor contenido en customer_id (se usa el customer_id para así traer el customer_name). Mientras se completa el Item customer_id, si el usuario ingresa un valor inválido, el proceso de extracción del customer_name no encontrará una fila que coincida, y la sentencia SELECT causará una excepción. El éxito o el fracaso de la consulta pueden, por lo tanto, usarse para validar la entrada del usuario.
Las excepciones que pueden ocurrir cuando una fila individual no es retornada desde un SELECT son:
• NO_DATA_FOUND: no se devuelven filas en la consulta.
• TOO_MANY_ROWS: se devuelve más de una fila en la consulta.
El siguiente Trigger When-Validate-Item del Item customer_id es el ejemplo antes mencionado; En él, se trata de extraer el nombre que corresponde a la identificación del cliente ingresada por el usuario para luego asignarlo al Item customer_name.
SELECT cust_first_name ||' '|| cust_last_name
INTO :ORDERS.customer_name
FROM clientes
WHERE customer_id =: ORDERS.customer_id;
Si el Item Customer_ID contiene un valor que no se encuentra en la tabla, se genera la excepción NO_DATA_FOUND y el Trigger fallará porque no existe un controlador de excepciones para evitar que la excepción se propague.
Nota: Un Trigger When-Validate-Item fallido impide que el cursor (focus) deje el Item en cuestión.
Cuando ocurre una excepción no controlada, como se indicó anteriormente, el usuario recibe el mensaje:
FRM-40735: <trigger type> trigger raised unhandled exception <exception>
______________________________________________________________________________________
Validación Client-Side.
Puede también considerar el uso de Pluggable Java Components (PJCs) para reemplazar la funcionalidad predeterminada de los Items. Al hacer esto, la validación de los Items, como la fecha o los valores máximos o mínimos, está contenida dentro del mismo Item. Esta técnica abre oportunidades para realizar validaciones más compleja, le permite hacer validaciones específicas de la aplicación como el formateo automático de la entrada, como números de teléfono con formato (XXX) XXX-XXXX. Incluso un formato numérico simple es realizado al instante, sin permitir que se ingresen pulsaciones de teclas alfabéticas en el Item numérico.
Esta validación se realiza en el lado cliente (Client-Side) sin la necesidad de realizar un viaje de ida y vuelta en la red, mejorando así el rendimiento. En el segundo ejemplo, KeyFilter PJC no permite que el operador ingrese un carácter alfabético en el Item Quantity. El único mensaje que se muestra en la línea de mensaje es el Item's Hint (Sugerencia).
Los Pluggable Java Components (PJCs) son similares a los JavaBeans, y de hecho, los dos términos se usan indistintamente. Aunque ambos son componentes de Java que puede usar en un Forms, existen las siguientes diferencias entre ellos:
Los JavaBeans se implementan en un Item Bean Area, mientras que los PJC se implementan en un Item cualquier de Forms, Eje: Text Item o Check Box.
Los PJC siempre deben tener la clase de implementación especificada en la Paleta de propiedades, mientras que los JavaBeans pueden registrarse en el tiempo de ejecución con el paquete FBean.
Implementando los PJC.
Para implementar un PJC debe establecer la propiedad Clase de Implementación (Implementation Class) del Item con la clase del PJC. También puede usar el built-in SET_CUSTOM_PROPERTY para establecer las propiedades del PJC que restringen la entrada y/o validan el Item. En tiempo de ejecución, Forms busca la clase Java contenida en el nivel medio o en los archivos con la ruta especificada en la clase de implementación. Si abre keyfilter.jar en WinZip, encontrará que su ruta es oracle\forms\demos.
La implementación del PJC es igual a la de un JavaBean, este último discutido en esta publicación:
Agregando Funcionalidad a los Items.
Puede ubicar el archivo de clase Java:
• En el servidor de nivel medio, ya sea en la estructura de directorios a la que hace referencia el parámetro CODEBASE del applet de Forms o en el CLASSPATH del servidor. De forma predeterminada CODEBASE es el subdirectorio forms90\java de ORACLE_HOME.
• Si usa JInitiator, en un archivo JAR en el directorio CODEBASE del servidor de nivel medio, e incluido en el parámetro ARCHIVE para que el archivo JAR se descargue y almacene en caché en el cliente. Por ejemplo: archive_jini=f90all_jinit.jar, keyfilter.jar
(Los parámetros CODEBASE y ARCHIVE se establecen en el archivo formsweb.cfg).
______________________________________________________________________________________
Estatus de Validación.
Cuando Forms deja un objeto, por lo general valida cualquier cambio que se haya realizado en el contenido del mismo. Para determinar si se debe realizar la validación, Forms realiza un seguimiento del estatus de validación de los Items y Registros (Records).
Estatus de Validación para Items.
Estatus |
Definición |
NEW
|
Cuando se crea un registro, Forms marca cada Item en ese registro como nuevo (NEW). Esto es cierto incluso si el Item se rellena con las propiedades Copy Value from Item o Initial Value o con el Trigger WHEN-CREATE-RECORD.
|
CHANGED
|
El Item es marcado CHANGED bajo las siguiente condiciones:
|
VALID
|
El Item es marcado VALID bajo las siguiente condiciones:
|
Estatus de Validación para Registros.
Estatus | Definición |
NEW
|
Cuando se crea un registro, Forms marca cada Item en ese registro como nuevo (NEW). Esto es cierto incluso si algún Item del registro se rellena con las propiedades Copy Value from Item o Initial Value o con el Trigger WHEN-CREATE-RECORD.
|
CHANGED
|
Cuando un Item es marcado como CHANGED. El registro inmediatamente es marcado como CHANGED.
|
VALID
|
El Registro es marcado VALID bajo las siguiente condiciones:
|
Uso de Built-ins para controlar la Validación.
Puede usar los siguientes built-ins en Triggers para afectar la validación.
• CLEAR_BLOCK, CLEAR_FORM y EXIT_FORM
El primer parámetro de estos built-ins, COMMIT_MODE, controla la acción a tomar cuando hay cambios no aplicados ya sea que se limpie el bloque (CLEAR_BLOCK), el Forms (CLEAR_FORM) o cuando se abandona Forms (EXIT_FORM). Cuando el parámetro se establece en NO_VALIDATE, los cambios no se validan ni se aplican (de manera predeterminada, se solicita al usuario la acción a tomar).
• Propiedad ITEM_IS_VALID.
Puedes usar los built-ins GET_ITEM_PROPERTY y SET_ITEM_PROPERTY con el parámetro ITEM_IS_VALID para obtener o establecer el estado de validación de un artículo. No puede obtener y configurar directamente el estado de validación de un registro. Sin embargo, puede obtener o establecer el estado de validación de todos los elementos en un registro.
• ENTER
El built-in ENTER realiza la misma acción que la tecla [Enter]. Es decir, fuerza la validación de datos en la unidad de validación actual.
• SET_FORM_PROPERTY
Puede usar esto para inhabilitar la validación de Forms. Por ejemplo, supongamos que está probando un Forms y necesita eludir la validación normal. Establezca la propiedad VALIDATION en PROPERTY_FALSE para este propósito:
SET_FORM_PROPERTY ('form_name', VALIDATION, PROPERTY_FALSE);
También puede usar este built-in para cambiar la unidad de validación:
SET_FORM_PROPERTY ('form_name', VALIDATION_UNIT, scope);
• VALIDATE
VALIDATE (scope) obliga a Forms a ejecutar inmediatamente el proceso de validación para el alcance (scope) indicado.
Nota: Valores validos para el parámetro scope: DEFAULT_SCOPE, BLOCK_SCOPE, RECORD_SCOPE y ITEM_SCOPE.
______________________________________________________________________________________
Resumen.
En esta publicación, debes haber aprendido que:
• La unidad de validación especifica que cantidad de datos que se ingresan antes de que ocurra la validación.
• Puede controlar la validación usando:
--Propiedades objetos: Validation Unit (Forms); Validate from List (Item)
--Triggers: When-Validate-Item (Nivel item); When-Validate-Record (Nivel block).
--Pluggable Java Components para validaciones client-side.
• La validación se produce en varios niveles: Item, Record, Block y Form.
• La validación ocurre cuando:
--Se presiona la tecla [Enter] o se ejecuta el built-in ENTER.
--El control sale de la unidad de validación debido a la navegación o debido a un Commit.
• La validación estándar ocurre antes de la validación de Trigger.
• La unidad de validación por defecto es nivel Item.
• El Trigger WHEN-VALIDATE-"object" complementa la validación estándar.
• Forms rastrea el Estatus de Validación de Items y Registros, los cuales son NEW, CHANGED o VALID.
• Puede usar Built-ins para controlar cuándo ocurre la validación:
--CLEAR_BLOCK
--CLEAR_FORM
--EXIT_FORM
--ENTER
--ITEM_IS_VALID
--VALIDATE
• Puede usar Built-ins para controlar cuándo ocurre la validación:
--CLEAR_BLOCK
--CLEAR_FORM
--EXIT_FORM
--ENTER
--ITEM_IS_VALID
--VALIDATE
______________________________________________________________________________________
Fuente: Oracle Forms Developer 10g: Build Internet Applications.
Fuente: Oracle Forms Developer 10g: Build Internet Applications.
