Tablas

¡El primer registro apareció en la base de datos! Pero no lo vemos, y hay que arreglarlo. Para ello, se necesita el componente Table componente (una tabla que mostrará los datos necesarios). Inmediatamente después de añadirlo, le pedirá que decida qué datos habrá en él y que seleccione un modelo y un punto final.

Configuración de la tabla

La tabla creada debe emitirse inmediatamente de acuerdo con sus necesidades. Por ejemplo, limitar el número de registros en una página (la tabla puede ser muy larga y de varias páginas), así como eliminar los campos que no interesan o configurar el campo deseado para la salida de las tablas relacionadas.

Al mismo tiempo, recordamos que la mera adición de cualquier componente no significa todavía su completa preparación para el trabajo. Es necesario crear los procesos de negocio adecuados. En el caso de las tablas, mucho se crea automáticamente, pero como parte de la formación, crearemos todo desde cero para asimilar mejor el material.

Activadores de tablas

Hay tres desencadenantes de mayor interés en las tablas - onDataUpdate, onShow, y onFilter. Empecemos con onShow y definamos lo que debe ocurrir cuando la tabla se muestra en la pantalla. Esto requerirá tres bloques:

1) Table Update Properties. Establezca las propiedades deseadas de la tabla. Por ejemplo, aquí se puede limitar el número de registros en una página (establecer el parámetro Records per page = 10) y también mostrar que la página está en modo de carga de datos (Loading = true)

2) Server request GET /country/. Para que los datos aparezcan, es necesario llevarlos a algún lugar. Y para ello, hacer una petición a la base de datos para el endpoint correspondiente. Al mismo tiempo, prestar atención al número de parámetros de entrada de este punto final. Proporcionan más flexibilidad en la consulta y obtienen sólo los datos que realmente se necesitan.
En nuestro caso, estableceremos _limit = 10 porque el número de entradas por página es de 10, y no tiene sentido cargar más. Además, haremos el orden de salida correcto, ordenaremos todo por nombre (_sort_by = name), y también estableceremos el orden de clasificación. El parámetro _sort_order puede tomar el valor ASC (de la palabra Ascending, para la ordenación directa, del valor más pequeño al más grande) o DESC (Descending, orden inverso). La ordenación directa por orden alfabético está bien para nosotros, así que _sort_order = ASC.

El parámetro _with merece una atención especial. Ejecutando la consulta sin él, sólo podríamos obtener datos sobre países. Pero el modelo de país está relacionado con las ciudades, y aunque estos datos no pertenecen a la tabla solicitada, seguimos queriendo verlos. Para ello, establezcamos _with = citys y obtendremos inmediatamente los datos sobre las ciudades que se encuentran en este país.

3) Table Update Data. Se reciben los datos, pero hay que pasarlos a una tabla para mostrarlos en la pantalla. Para ello, pasamos toda la información (data) recibida en el bloque anterior, así como el número total de registros (count - Total Records), para saber cuántas páginas debe tener la tabla.

El siguiente trigger es onDataUpdate. Los datos de la tabla pueden actualizarse como resultado de diversos procesos de negocio. Y cuando esto sucede, es mejor especificar una vez lo que debe suceder y no poner los mismos bloques en cada proceso de negocio. En nuestro caso, será correcto utilizar el bloque Table Update Properties pero esta vez para eliminar el modo de carga (Loading = false), que se estableció anteriormente, y mostrar que la tabla está lista para trabajar.

El último trigger que necesitamos es onFilter. Define lo que debe ocurrir en el momento de la transición a otras páginas de la tabla. Para ello, cuenta con el parámetro _offset que, de acuerdo con el número de página, indica qué desplazamiento es necesario al cargar los datos.

Por ejemplo, si en nuestro caso hay 10 entradas en cada página, la tercera página necesitará las entradas del 21 al 30. Estos datos se obtendrán de _offset y se pueden pasar al bloque Server request GET /country/ bloque. De lo contrario, el proceso de negocio coincidirá completamente con el proceso del TableOnShow desencadenante. En tales situaciones, sería razonable que dos disparadores diferentes lanzaran el mismo proceso de negocio.

Pero en nuestro caso, la diferencia importante radica en el parámetro _offset parámetro. Si se deja todo como en la captura de pantalla de abajo, entonces el proceso se iniciará según el onShow pero se detendrá en el bloque Server request GET /country/ ya que no puede obtener el valor _offset valor (se pasa desde otro disparador).

Esta situación se resuelve mejor utilizando variables. Veamos un ejemplo concreto. Necesitamos una variable de tipo Integer para guardar _offset valor. Por lo tanto, utilizamos un bloque Integer bloque para declarar esta variable, pero dos bloques diferentes Set Variable para escribir su valor, cada uno asociado a un trigger diferente.

Según el Table onShow trigger, no necesitamos ningún desplazamiento, los datos de la tabla se muestran desde el principio y _offset = 0por lo que establecemos Value = 0 en el bloque Set Variable bloque.

Cuando el Table onFilter trigger se lanza, ya recibimos el _offset valor y queremos utilizarlo, así que pasaremos el _offset valor del disparador como Value al bloque Set Variable bloque.

En los siguientes pasos, los procesos de negocio de los disparadores no se diferencian entre sí, por lo que se combinan dos procesos de negocio en uno, cada uno con su propio valor de la variable entera para el _offset parámetro.