El widget más usado en el software empresarial
Un banco regional con el que trabajamos el año pasado contó las invocaciones de LOV en todo su conjunto de Oracle Forms durante una semana. El número resultó en 11,4 millones. En 238 pantallas y 1.700 usuarios diarios, el LOV se abría aproximadamente una vez cada dos segundos. Ningún otro control se le acercaba.
Esa frecuencia importa. Cuando los LOVs se degradan durante la migración, los usuarios lo notan en una hora. Cuando mejoran, la ganancia de productividad se muestra en el primer día de operación en paralelo.
Qué hace realmente un LOV de Oracle Forms
Un LOV es un picker modal respaldado por un record group. El record group es generalmente una sentencia SELECT, a veces una lista estática, ocasionalmente un cursor programático. Soporta auto-reducción (escribir caracteres para filtrar), mapeo de columnas (la fila seleccionada completa múltiples items) y validación (los valores que no están en el LOV pueden ser rechazados).
El .fmb típico contiene 18 LOVs. Aproximadamente el 60% son búsquedas de una sola columna. El 40% restante hace algo más interesante: parámetros en cascada, filtros dependientes o poblamiento multicolumna.
-- Un record group de LOV representativo
SELECT customer_id, customer_name, credit_limit, region_code
FROM customers
WHERE status = 'A'
AND region_code = :ORDERS.REGION
ORDER BY customer_name;
Esa variable de bind :ORDERS.REGION es la razón por la que las migraciones ingenuas fallan. El LOV no es independiente — está parametrizado sobre el estado vivo del formulario.
El equivalente moderno no es un dropdown
Un <select> HTML nativo maneja quizás el 10% de los casos de LOV. Todo lo demás necesita un componente type-ahead con filtrado del lado del servidor, consultas con debounce, navegación por teclado y la capacidad de poblar múltiples campos vinculados desde una selección. Optamos por un único componente React que acepta un endpoint de búsqueda descrito por OpenAPI y un mapeo de columnas.
La firma del endpoint que generamos para cada LOV luce así:
GET /api/lov/customers?q=acm®ion=EU&limit=25
// Response
{
items: [
{ customer_id: 4821, customer_name: "Acme Industrial",
credit_limit: 250000, region_code: "EU" }
],
total: 1
}
Cada LOV en el .fmb de origen se convierte en un endpoint más una instancia de componente. El SQL del record group se convierte en el cuerpo de la consulta. Las variables de bind se convierten en parámetros de consulta conectados al estado del formulario.
Auto-reducción, debouncing y la regla de los 150ms
Los LOVs de Forms se sienten instantáneos porque se ejecutan contra un cursor local. Los viajes de ida y vuelta por red no lo son. Para igualar la sensación original, el type-ahead debe devolver resultados en menos de 150ms para el caso p95. Logramos ese número generando endpoints de búsqueda indexados directamente desde el SQL del LOV, cacheando la primera página por sesión de usuario y aplicando debounce a la entrada en 80ms.
En 14 despliegues hemos medido tiempos de respuesta medios de LOV entre 38ms y 110ms. Los usuarios reportan que los nuevos pickers se sienten más rápidos que los originales — no porque la red sea más rápida, sino porque el manejo del teclado es mejor.
LOVs en cascada y estado del formulario
El patrón más difícil es la cascada: seleccionar un cliente filtra el LOV de dirección de envío, que filtra el LOV de contacto, que filtra el LOV de producto. En Forms, estas relaciones son implícitas — las variables de bind leen los valores actuales de los campos al momento de apertura. En un stack moderno, las relaciones deben ser explícitas.
Las codificamos en el JSON descriptor como un array dependsOn. El componente vuelve a consultar cuando cualquier dependencia cambia y limpia las selecciones posteriores. El generador produce el cableado automáticamente a partir del análisis original de variables de bind.
Paridad de validación
Los LOVs de Forms pueden ser estrictos (el valor debe existir en la lista) o consultivos (el valor se sugiere pero se permite texto libre). Aproximadamente el 70% de los LOVs que hemos migrado son estrictos. El componente type-ahead aplica esto con una verificación final del lado del servidor al enviar — no solo del lado del cliente — porque el comportamiento original de Forms validaba contra datos en vivo, no contra una lista cacheada.
La conclusión
Los LOVs no son dropdowns. Son pickers parametrizados, en cascada y multicolumna que impulsaron 30 años de UX empresarial. Reemplazarlos bien requiere un componente que entienda el estado del formulario, un endpoint generado desde el SQL original, y presupuestos de latencia medidos en milisegundos. Bien hecho, la migración hace que el widget más usado en la aplicación sea más rápido de lo que era antes.