Este es un ejemplo un tanto artificial, pero lo único que pretende es mostrar 2 cosas:
Que se puede recuperar y actualizar la base de datos asociada a los modelos de datos de negocio.
Que es posible dinamizar los formularios.
Lo que tenemos son dos procesos independientes. El primero, CREAR CITAS, elimina datos previos y deja limpio el BDM —vacía la tabla— y, después, mediante un formulario configurado especialmente para ello, insertar nuevos datos y en la cantidad que queramos.
El segundo proceso, VER CITAS, solo pretende mostrar cómo leer el BDM y nutrir un selector en el formulario.
Más adelante entraremos en detalles, pero adelantamos que nuestro BDM será Citas1 que, como atributos propios, mantiene dia (Date-Time) y dni (String). Si partimos de la siguiente situación, la tarea ELIMINAR CITAS vacía la tabla.
A continuación, CREAR CITAS nos proporciona un botón que nos abre una nueva cita. Podemos pulsar ese botón tantas veces como queramos.
Además, también se habilita un botón de borrado en cada fila (aspa sobre fondo rojo), pudiendo eliminar y añadir filas hasta que decidamos pulsar el botón de "enviar".
Tanto si volvemos a consultar el BDM como si examinamos el caso, podremos comprobar que sí, que hemos añadido varias filas desde un único formulario y una única instancia del proceso.
Para el otro proceso, VER CITAS, solo queremos nutrir dinámicamente un widget select desde nuestro BDM. Seleccionemos lo que seleccionemos, el caso mostrará el identificador (persistenceId) de esa selección.
El proceso no tiene ni contrato ni formulario de instanciación.
Citas1
dni STRING
dia DATE-TIME (NO TIME ZONE)
Nombre misCitas
Objeto de Negocio com.company.model.Citas1
"Es múltiple" marcado
La base de este ejemplo es que la variable de negocio puede almacenar múltiples filas de valores (dni, dia). Por eso marcamos la casilla "es múltiple". De hecho, en la descripción de la variable nos aparecerá el siguiente texto:
List<com.company.model.Citas1>
Es decir, vamos a manejar una "lista de citas".
Otro aspecto importante es el valor inicial de la variable de negocio. Recuerda que queremos borrar el contenido actual del BDM Citas1. Para ello, primero debemos recuperar las filas almacenadas en la tabla; esto lo haremos mediante una consulta SQL. Bonita, al definir el BDM, genera automáticamente un conjunto de consultas, solo tenemos que seleccionar la deseada y el programa rellena con los datos necesarios.
La consulta find es la básica que nos proporciona todo el contenido de la tabla. Todas esas filas irán a parar a la variable de negocio misCitas recién instanciada.
Aquí solo definiremos una operación. El argumento de la izquierda es la variable de negocio, misCitas, y la operación "se ha eliminado".
La traducción del operador es un tanto confusa, pero la acción es precisamente la que buscamos. En base al contenido de la variable de negocio que, recordemos, es toda la tabla del BDM, ordenamos eliminar esa información. Pero, claro, la variable de negocio hace que se actualice la tabla: si le añadimos valores, inserta en el BDM; si eliminamos valores, los elimina igualmente del BDM.
Resumiendo, con esa operación estamos ordenando un delete from Citas1 where..., consiguiendo lo que buscábamos, vaciar la tabla.
Una vez vaciado el BDM, queremos crear nuevas filas. En esta tarea necesitamos un contrato con los atributos dni y dia, pero con la casilla múltiple marcada. Queremos introducir por formulario una lista de valores (dni, dia). Fíjate que no hacemos nada especial, marcamos los dos atributos y finalizamos.
Sin embargo, Bonita añade ciertos detalle, como la casilla "múltiple" —lógicamente, puesto que así hemos definido la variable de negocio— y un atributo adicional persistenceId_string. No nos preocupa, forma parte de la configuración automática del programa.
De hecho, realiza más cosas automáticamente, como la operación necesaria para trasvasar los datos desde el formulario hasta la variable de negocio.
Esa operación está asociada a un script Java cuyo contenido será:
def citas1List = []//For each item collected in multiple inputmisCitasInput.each{ //Add Citas1 instance citas1List.add({ currentCitas1Input -> def citas1Var = misCitas.find { it.persistenceId.toString() == currentCitas1Input.persistenceId_string} ?: new com.company.model.Citas1() citas1Var.dni = currentCitas1Input.dni citas1Var.dia = currentCitas1Input.dia return citas1Var }(it))}return citas1ListEste script define un objeto lista que va rellenando, fila a fila, con el contenido de la lista introducida en el formulario, creando en cada iteración una instancia de com.company.model.Citas1, es decir, una fila en esa tabla.
Salvo que queramos hacer algo más sofisticado, al especificar el contrato, Bonita nos ha resuelto todo lo necesario.
No vamos a hacer nada especial con el formulario, Bonita hará el trabajo por nosotros. No obstante, examinaremos con detalle el resultado. Aparte de las personalizaciones simples que podamos hacer, esto es lo que nos encontraremos:
Lo primero que debemos darnos cuenta es de que el contenedor es de tipo "colección". Lo vemos tanto en la esquina superior derecha como en la configuración. Un contenedor se convierte en una colección cuando enlazamos la variable de valor múltiple. Eso permite el comportamiento del formulario que hemos descrito al principio, que aparecerán tantas filas como pidamos.
Precisamente, ese botón de añadir filas nos permite estudiar cómo funciona el formulario.
En la etiqueta encontramos una forma de personalizar nuestros futuros botones:
<span class="glyphicon glyphicon-plus"></span> Add Citas1
La acción que permite ir añadiendo nuevas filas al contenedor es:
Añadir a la colección
Fijáte, al abrir el desplegable, que la otra operación posible es "eliminar", la que utilizará el otro botón.
En "colección" se ha enlazado con la variable del formulario generada automáticamente desde el contrato:
misCitas
Y, por último, el valor a agregar en esa nueva fila es:
{ "persistenceId_string" : "", "dni" : ""}
Recuerda que persistenceId y persistenceId_string no los has generado tú, que son atributos que usa Bonita.
El otro botón es similar, salvo que la acción es eliminar de la colección y el "elemento a eliminar" es $item.
$item —como también $collection— es una variable interna que podemos utilizar. Esta, en concreto, que representa a la fila actual en la que se inserta el botón.
Puedes practicar más con las colecciones con el tutorial de Bonita Repeat a container for a collection of data.
Este proceso no tiene mucho más interés que mostrar una consulta al BDM desde el formulario.
El proceso no tiene ni contrato ni formulario de instanciación.
El BDM es ligeramente diferente al anterior puesto que queremos comprobar el resultado en Portal examinando el caso.
CitaConf
citaId LONG
vnConf -- com.company.model.CitaConf
Se genera al agregar desde datos.
vnConfInput -- COMPLEX
citaId
fElegirCitas
En el formulario creamos la siguiente variable:
Nombre citas
Tipo EXTERNAL API
Valor ../API/bdm/businessData/com.company.model.Citas1?q=find&p=0&c=100
Esta es la llamada al API REST para recuperar datos desde un BDM. Fíjate que especificamos a cuál queremos acceder (com.company.model.Citas1) y, mediante parámetros GET en la URL (?..&..), qué queremos hacer (find), la página (p) y el número máximo de filas por página (c). El parámetro p se utiliza para grandes cantidades de datos que se tratan por páginas —como es habitual en el catálogo de una tienda online—.
En definitiva, estamos haciendo un select * from Citas1, pero el resultado nos llegará en formato JSON.
Convertimos el widget Input que nos ha puesto Bonita en un widget Select.
Y lo configuramos como sigue;
Enlazamos la variable recién creada citas.
Como clave mostrada
persistenceId_string+': '+dni+' -- '+dia
Evidentemente, esto lo puedes personalizar como quieras, se trata del texto que aparecerá en el selector.
Como clave de retorno
persistenceId_string
Este es la versión en texto del identificador único del BDM (clave primaria)
Y, finalmente, como valor
vnConf.citaId
Es decir, dónde se va a almacenar el identificador que elijamos.
Fíjate que, en este proceso, examinar el caso solo nos va devolver algo con apariencia de número, y será el persistenceId de la cita en Citas1. Para entendernos, este es el contenido de una ejecución desde el cliente H2 (botón derecho sobre bom.xml en el explorador de proyectos).
No olvides que el BDM almacena "casos", ejecuciones de un proceso. Por eso la consulta a CITACONF nos devuelve más filas, pero la última es la que se corresponde con la última ejecución, cuando hemos elegido entre las CITAS1 11, 12 Y 13. Obviamente, a ti te saldrán otros valores.