Tabelas

O primeiro registo apareceu na base de dados! Mas não o vemos, e precisa de ser corrigido. Para o fazer, é necessário o Table componente (uma tabela que exibirá os dados necessários). Imediatamente após a adição, pedir-lhe-á que decida quais os dados que estarão no mesmo e seleccione um modelo e um ponto final.

Definições da tabela

A tabela criada deve ser imediatamente emitida de acordo com as suas exigências. Por exemplo, limite o número de registos numa página (a tabela pode ser muito longa e com várias páginas), bem como remova os campos que não interessam ou crie o campo desejado para saída das tabelas relacionadas.

Ao mesmo tempo, lembramos que a simples adição de qualquer componente ainda não significa a sua completa prontidão para o trabalho. É necessário criar processos empresariais adequados. Para as tabelas, muito é criado automaticamente, mas como parte da formação, vamos criar tudo do zero para melhor assimilar o material.

A tabela desencadeia

Há três estímulos de maior interesse nas tabelas - onDataUpdate, onShowe onFilter. Vamos começar com onShow e definir o que deve acontecer quando a tabela é mostrada no ecrã. Para tal, serão necessários três blocos:

1) Table Update Properties. Definir as propriedades desejadas da tabela. Por exemplo, aqui pode limitar o número de registos numa página (definir o parâmetro Records per page = 10) e também mostrar que a página está em modo de carregamento de dados (Loading = true)

2) Server request GET /country/. Para que os dados apareçam, eles precisam de ser levados para algum lugar. E para isso, fazer um pedido à base de dados para o ponto final correspondente. Ao mesmo tempo, preste atenção ao número de parâmetros de entrada deste parâmetro. Eles proporcionam mais flexibilidade na consulta e obtêm apenas os dados que são realmente necessários.
No nosso caso, iremos definir _limit = 10 porque o número de entradas por página é 10, e não vale a pena carregar mais. Além disso, faremos a ordem de saída correcta, ordenaremos tudo pelo nome (_sort_by = name), e também estabelecer a ordem de classificação. O _sort_order o parâmetro pode assumir o valor ASC (da palavra Ascending, para selecção directa, do valor mais pequeno ao maior) ou DESC (Descending, ordem inversa). A ordenação alfabética directa é boa para nós, por isso _sort_order = ASC.

O _with merece uma atenção especial. Executando a consulta sem ela, só poderíamos obter dados sobre países. Mas o modelo de país está relacionado com as cidades, e embora estes dados não pertençam à tabela solicitada, continuamos a querer vê-los. Para o fazer, definir _with = citys e obter imediatamente dados sobre quais são as cidades deste país.

3) Table Update Data. Os dados são recebidos, mas precisam de ser transferidos para uma tabela a ser exibida no ecrã. Para o efeito, passamos toda a informação (data) recebidos no bloco anterior, bem como o número total de registos (count - Total Records), a fim de compreender quantas páginas devem estar na tabela.

O próximo gatilho é onDataUpdate. Os dados da tabela podem ser actualizados em resultado de vários processos empresariais. E quando isto acontece, é melhor especificar uma vez o que deve acontecer e não colocar os mesmos blocos em cada processo de negócio. No nosso caso, será correcto utilizar a tabela de Table Update Properties bloquear novamente, mas desta vez para remover o modo de carregamento (Loading = false), que foi colocado anteriormente, e mostrar que a mesa está pronta a funcionar.

O último gatilho de que precisamos é onFilter. Define o que deve acontecer no momento da transição para outras páginas da tabela. Para o fazer, tem o _offset que, de acordo com o número de página, indica o offset necessário ao carregar os dados.

Por exemplo, se, no nosso caso, houver 10 entradas em cada página, então a terceira página necessitará de entradas de 21 a 30. Estes dados serão obtidos a partir de _offset e pode ser passado para o Server request GET /country/ bloco. Caso contrário, o processo empresarial irá coincidir completamente com o processo no bloco TableOnShow gatilho. Em tais situações, seria razoável que dois gatilhos diferentes lançassem o mesmo processo comercial.

Mas, no nosso caso, a diferença importante reside no _offset parâmetro. Se deixar tudo como na imagem de ecrã abaixo, então o processo começará de acordo com o parâmetro onShow gatilho, mas irá parar no Server request GET /country/ bloco, uma vez que não consegue obter o _offset valor (é passado de outro gatilho).

Esta situação é melhor resolvida utilizando variáveis. Vejamos um exemplo específico. Precisamos de uma variável do tipo Integer para salvar _offset valor. Por conseguinte, utilizamos um Integer bloco para declarar esta variável, mas duas variáveis diferentes Set Variable blocos para escrever o seu valor, cada um associado a um gatilho diferente.

De acordo com o Table onShow não precisamos de qualquer compensação, os dados na tabela são mostrados desde o início e _offset = 0por isso estabelecemos Value = 0 no Set Variable bloco.

Quando o Table onFilter gatilho é lançado, já recebemos o _offset valor e quer usá-lo para que passemos o _offset valor do gatilho como Value para a Set Variable bloco.

Nos passos seguintes, os processos empresariais de desencadeadores não diferem entre si, pelo que dois processos empresariais são combinados num só, cada um com o seu próprio valor da variável inteira para o _offset parâmetro.