Una lista padre es una lista de selección de la que depende otra, llamada lista hija, para filtrar sus valores. Cuando se elige un valor en la lista padre, la lista hija solo muestra los valores que corresponden a esa elección. A ese comportamiento se lo llama filtrado en cascada, y a las listas que funcionan así, listas en cascada.
El ejemplo clásico es provincia según país: al elegir Argentina en el campo de país, el campo de provincia solo ofrece provincias argentinas. Sin la relación entre listas, el usuario vería todas las provincias de todos los países en un mismo desplegable, con el riesgo de elegir una que no corresponde.
En la Tabla 6.1 de la L6, la lista padre figura como una de las partes de una lista. En el caso de AR_ModalidadTrabajo no tiene, porque sus valores no dependen de ninguna otra elección. Pero el caso del curso sí usa listas en cascada en otro lugar: en la clasificación de puesto de Best Run Argentina, la lista AR_Convenio, con Comercio, Bancarios y Fuera de convenio, es la lista padre de AR_CategoriaConvenio. Al elegir Comercio, solo aparecen las categorías de ese convenio. Lo configuramos en la U2 L2, como parte de los campos propios de la clasificación de puesto.
La relación entre listas se define en el Centro de listas de selección, indicando para cada lista hija cuál es su lista padre y, para cada valor de la lista hija, a qué valor de la lista padre pertenece. Pero eso solo no alcanza: los campos que usan las listas también tienen que estar configurados para comportarse en cascada, de modo que el campo hijo tome en cuenta lo que se eligió en el campo padre. Esa configuración se hace en el modelo de datos o en la definición del objeto MDF, según dónde estén los campos.
El orden de carga tiene que respetar la relación. La lista padre se crea antes que la lista hija, y sus valores, antes que los valores de la hija que los referencian. Es la misma lógica de dependencias que recorre toda la secuencia de implementación: cada pieza necesita que exista la pieza de la que depende.
Las listas en cascada mejoran la calidad de los datos, porque reducen las combinaciones posibles a las que tienen sentido. Pero también agregan un punto de falla: si un valor de la lista hija no tiene asignado su valor padre, el filtro no lo alcanza y el valor se ofrece siempre, elija el usuario el valor padre que elija. Ante un desplegable hijo que muestra valores de más, conviene revisar esa asignación antes de buscar otras causas.
Conviene no confundir este filtrado con las asociaciones entre objetos de fundamento, que filtran registros de objetos, como las divisiones según la unidad de negocio, y se ven en la U2 L3.
En el ejercicio de la L6, la última consigna pide explicar la relación entre AR_Convenio y AR_CategoriaConvenio.
