Tableaux

Le premier enregistrement est apparu dans la base de données ! Mais on ne le voit pas, et il faut le corriger. Pour ce faire, vous avez besoin du composant Table (une table qui affichera les données nécessaires). Dès son ajout, il vous demandera de décider des données qu'il contiendra et de sélectionner un modèle et un endpoint.

Paramétrage du tableau

La table créée doit immédiatement être éditée en fonction de vos besoins. Par exemple, limitez le nombre d'enregistrements sur une page (la table peut être très longue et comporter plusieurs pages), supprimez les champs sans intérêt ou configurez le champ souhaité pour la sortie de tables connexes.

En même temps, nous nous rappelons que le simple ajout d'un composant ne signifie pas encore qu'il est totalement prêt à fonctionner. Vous devez créer des processus de gestion appropriés. Pour les tables, beaucoup de choses sont créées automatiquement, mais dans le cadre de la formation, nous allons tout créer à partir de zéro pour mieux assimiler le matériel.

Déclencheurs de table

Il y a trois déclencheurs de plus grand intérêt dans les tables - . onDataUpdate, onShow, et onFilter. Commençons par onShow et définissons ce qui doit se passer lorsque le tableau est affiché à l'écran. Cela nécessitera trois blocs :

1) Table Update Properties. Définissez les propriétés souhaitées de la table. Par exemple, vous pouvez ici limiter le nombre d'enregistrements sur une page (paramétrer l'option Records per page = 10) et également montrer que la page est en mode de chargement de données (Loading = true)

2) Server request GET /country/. Pour que les données apparaissent, il faut qu'elles soient prises quelque part. Et pour ce faire, faites une demande à la base de données pour le point de terminaison correspondant. En même temps, faites attention au nombre de paramètres d'entrée de ce point final. Ils offrent plus de flexibilité dans la requête et permettent d'obtenir uniquement les données qui sont réellement nécessaires.
Dans notre cas, nous allons définir _limit = 10 car le nombre d'entrées par page est de 10, et il est inutile d'en charger plus. En outre, nous allons faire l'ordre de sortie correct, tout trier par nom (_sort_by = name), et également définir l'ordre de tri. Le paramètre _sort_order peut prendre la valeur ASC (du mot Ascending, pour un tri direct, de la plus petite valeur à la plus grande) ou DESC (Descending, ordre inverse). Le tri alphabétique direct nous convient, donc _sort_order = ASC.

Le paramètre _with mérite une attention particulière. En exécutant la requête sans lui, nous ne pouvions obtenir que des données sur les pays. Mais le modèle de pays est lié aux villes, et bien que ces données n'appartiennent pas à la table demandée, nous voulons quand même les voir. Pour ce faire, définissez _with = citys et nous obtenons immédiatement les données sur les villes de ce pays.

3) Table Update Data. Les données sont reçues, mais elles doivent être transférées dans une table pour être affichées à l'écran. Pour ce faire, nous passons toutes les informations (data) reçues dans le bloc précédent, ainsi que le nombre total d'enregistrements (count - Total Records), afin de comprendre combien de pages doit contenir le tableau.

Le déclencheur suivant est onDataUpdate. Les données de la table peuvent être mises à jour à la suite de divers processus opérationnels. Et lorsque cela se produit, il est préférable de spécifier une fois ce qui doit se passer et de ne pas mettre les mêmes blocs dans chaque processus métier. Dans notre cas, il sera correct d'utiliser à nouveau le bloc Table Update Properties mais cette fois pour supprimer le mode de chargement (Loading = false), qui a été défini précédemment, et montrer que la table est prête à fonctionner.

Le dernier trigger dont nous avons besoin est onFilter. Il définit ce qui doit se passer au moment de la transition vers d'autres pages du tableau. Pour ce faire, il dispose du paramètre _offset qui, en fonction du numéro de page, indique quel décalage est nécessaire lors du chargement des données.

Par exemple, si, dans notre cas, il y a 10 entrées sur chaque page, alors la troisième page aura besoin des entrées de 21 à 30. Ces données seront obtenues à partir de _offset et peuvent être transmises au bloc Server request GET /country/ bloc. Sinon, le processus métier coïncidera complètement avec le processus du TableOnShow déclencheur. Dans de telles situations, il serait raisonnable d'avoir deux déclencheurs différents qui lancent le même processus métier.

Mais dans notre cas, la différence importante réside dans le paramètre _offset paramètre. Si vous laissez tout comme dans la capture d'écran ci-dessous, alors le processus démarrera en fonction du déclencheur onShow mais il s'arrêtera au bloc Server request GET /country/ puisqu'il ne peut pas obtenir la valeur _offset (elle est transmise par un autre trigger).

Cette situation est mieux résolue en utilisant des variables. Prenons un exemple concret. Nous avons besoin d'une variable de type Integer pour enregistrer une _offset valeur. Par conséquent, nous utilisons un bloc Integer pour déclarer cette variable, mais deux blocs différents Set Variable blocs différents pour écrire sa valeur, chacun associé à un trigger différent.

Selon le Table onShow nous n'avons pas besoin de décalage, les données du tableau sont affichées depuis le tout début et _offset = 0donc nous mettons Value = 0 dans le bloc Set Variable dans le bloc

Lorsque le Table onFilter est lancé, nous avons déjà reçu la valeur _offset et nous voulons l'utiliser. _offset du déclencheur en tant que Value au bloc Set Variable bloc.

Dans les étapes suivantes, les processus de gestion des déclencheurs ne diffèrent pas les uns des autres, donc deux processus de gestion sont combinés en un seul, chacun avec sa propre valeur de la variable entière pour le paramètre _offset paramètre.