Tabellen

Het eerste record is verschenen in de database! Maar we zien het niet, en het moet hersteld worden. Om dit te doen heb je de Table component (een tabel die de nodige gegevens weergeeft). Onmiddellijk na het toevoegen zal het u vragen om te beslissen welke gegevens erin komen en een model en eindpunt te selecteren.

Tabel instellingen

De aangemaakte tabel moet onmiddellijk worden uitgegeven volgens uw wensen. Beperk bijvoorbeeld het aantal records op één pagina (de tabel kan zeer lang zijn en uit meerdere pagina's bestaan), verwijder velden die niet van belang zijn of stel het gewenste veld in voor uitvoer uit verwante tabellen.

Tegelijkertijd onthouden we dat de loutere toevoeging van een onderdeel nog niet betekent dat het volledig klaar is voor het werk. U moet passende bedrijfsprocessen creëren. Voor tabellen wordt veel automatisch aangemaakt, maar als onderdeel van de opleiding zullen we alles vanaf nul aanmaken om het materiaal beter te assimileren.

Tabel triggers

Er zijn drie triggers van het grootste belang in tabellen - onDataUpdate, onShow, en onFilter. Laten we beginnen met onShow en definiëren wat er moet gebeuren wanneer de tabel op het scherm wordt getoond. Hiervoor zijn drie blokken nodig:

1) Table Update Properties. Stel de gewenste eigenschappen van de tabel in. Hier kun je bijvoorbeeld het aantal records op een pagina beperken (stel parameter de Records per page = 10) en ook laten zien dat de pagina in de gegevenslaadmodus staat (Loading = true)

2) Server request GET /country/. Om de gegevens te laten verschijnen, moeten ze ergens naartoe worden gebracht. En om dit te doen, doet u een verzoek aan de database voor het overeenkomstige eindpunt. Let tegelijkertijd op het aantal invoerparameters van dit eindpunt. Ze bieden meer flexibiliteit in de query en halen alleen de gegevens op die echt nodig zijn.
In ons geval stellen we _limit = 10 omdat het aantal ingangen per pagina 10 is, en het geen zin heeft er meer te laden. Bovendien zullen we de juiste uitvoervolgorde maken, alles sorteren op naam (_sort_by = name), en ook de sorteervolgorde instellen. De parameter _sort_order parameter kan de waarde ASC (van het woord Ascending, voor direct sorteren, van de kleinste waarde naar de grootste) of DESC (Descending, omgekeerde volgorde). Directe alfabetische sortering is voor ons prima, dus _sort_order = ASC.

De parameter _with parameter verdient speciale aandacht. Als we de query zonder deze parameter uitvoeren, krijgen we alleen gegevens over landen. Maar het landenmodel is gerelateerd aan steden, en hoewel deze gegevens niet tot de gevraagde tabel behoren, willen we ze toch zien. Om dit te doen, stelt u _with = citys en krijgen we onmiddellijk gegevens over welke steden zich in dit land bevinden.

3) Table Update Data. De gegevens zijn ontvangen, maar moeten worden overgebracht naar een tabel om op het scherm te worden getoond. Daartoe geven we alle informatie (data) ontvangen in het vorige blok, evenals het totale aantal records (count - Total Records), om te begrijpen hoeveel pagina's er in de tabel moeten komen.

De volgende trigger is onDataUpdate. De gegevens in de tabel kunnen worden bijgewerkt als gevolg van verschillende bedrijfsprocessen. En wanneer dit gebeurt, is het het beste om één keer te specificeren wat er moet gebeuren en niet in elk bedrijfsproces dezelfde blokken te plaatsen. In ons geval is het correct om het Table Update Properties blok opnieuw te gebruiken, maar deze keer om de laadmodus (Loading = false), die eerder was ingesteld, en te laten zien dat de tabel klaar is om te werken.

De laatste trigger die we nodig hebben is onFilter. Deze bepaalt wat er moet gebeuren op het moment van overgang naar andere pagina's van de tabel. Hiervoor heeft het de _offset parameter, die in overeenstemming met het paginanummer aangeeft welke offset nodig is bij het laden van gegevens.

Bijvoorbeeld, als er in ons geval op elke pagina 10 gegevens staan, dan zal de derde pagina gegevens van 21 tot 30 nodig hebben. Deze gegevens worden verkregen uit _offset en kunnen worden doorgegeven aan het Server request GET /country/ blok. Anders zal het bedrijfsproces volledig samenvallen met het proces op de TableOnShow trigger. In dergelijke situaties zou het redelijk zijn om twee verschillende triggers hetzelfde bedrijfsproces te laten starten.

Maar in ons geval ligt het belangrijke verschil in de _offset parameter. Als u alles laat zoals in de schermafbeelding hieronder, dan zal het proces starten volgens de onShow trigger, maar zal het stoppen bij het Server request GET /country/ blok omdat het de _offset waarde (die wordt doorgegeven door een andere trigger).

Deze situatie wordt het best opgelost met behulp van variabelen. Laten we een specifiek voorbeeld bekijken. We hebben een variabele van het type Integer nodig om de _offset waarde op te slaan. Daarom gebruiken we één Integer blok om deze variabele te declareren, maar twee verschillende Set Variable blokken om de waarde ervan te schrijven, elk geassocieerd met een andere trigger.

Volgens de Table onShow trigger hebben we geen offset nodig. _offset = 0, dus stellen we Value = 0 in het Set Variable blok.

Wanneer de Table onFilter trigger wordt gestart, ontvangen we al de _offset waarde en willen we die gebruiken, dus geven we de _offset waarde van de trigger als Value aan het Set Variable blok.

In de volgende stappen verschillen de bedrijfsprocessen van triggers niet van elkaar, dus worden twee bedrijfsprocessen gecombineerd tot één, elk met zijn eigen waarde van de integer variabele voor de _offset parameter.