Tavoli

Il primo record è apparso nel database! Ma non lo vediamo, e bisogna sistemarlo. Per farlo, è necessario il componente Table (una tabella che mostrerà i dati necessari). Subito dopo l'aggiunta, verrà chiesto di decidere quali dati saranno contenuti e di selezionare un modello e un endpoint.

Impostazioni della tabella

La tabella creata deve essere immediatamente modificata in base alle proprie esigenze. Ad esempio, limitare il numero di record su una pagina (la tabella può essere molto lunga e a più pagine), nonché rimuovere i campi che non interessano o impostare il campo desiderato per l'output da tabelle correlate.

Allo stesso tempo, ricordiamo che la semplice aggiunta di un componente non significa ancora la sua completa disponibilità al lavoro. È necessario creare processi aziendali appropriati. Per le tabelle, molto viene creato automaticamente, ma nell'ambito della formazione creeremo tutto da zero per assimilare meglio il materiale.

Trigger delle tabelle

I trigger di maggiore interesse per le tabelle sono tre: - il modello, il modello e l'endpoint. onDataUpdate, onShow, e onFilter. Iniziamo con onShow e definiamo cosa deve accadere quando la tabella viene visualizzata sullo schermo. Ciò richiederà tre blocchi:

1) Table Update Properties. Impostare le proprietà desiderate della tabella. Ad esempio, qui è possibile limitare il numero di record in una pagina (parametro impostato il parametro Records per page = 10) e mostrare che la pagina è in modalità di caricamento dei dati (Loading = true)

2) Server request GET /country/. Affinché i dati appaiano, devono essere prelevati da qualche parte. A tale scopo, occorre fare una richiesta al database per l'endpoint corrispondente. Allo stesso tempo, prestare attenzione al numero di parametri di input di questo endpoint. Essi garantiscono una maggiore flessibilità nella richiesta e permettono di ottenere solo i dati realmente necessari.
Nel nostro caso, imposteremo _limit = 10 perché il numero di voci per pagina è 10 e non ha senso caricarne altre. Inoltre, si creerà l'ordine di output corretto, ordinando tutto per nome (_sort_by = name) e impostiamo anche l'ordine di ordinamento. Il parametro _sort_order può assumere il valore ASC (dalla parola Ascending, per un ordinamento diretto, dal valore più piccolo al più grande) o DESC (Descending, ordine inverso). L'ordinamento alfabetico diretto va bene per noi, quindi _sort_order = ASC.

Il parametro _with merita un'attenzione particolare. Eseguendo la query senza di esso, potremmo ottenere solo i dati sui paesi. Ma il modello di paese è collegato alle città e, sebbene questi dati non appartengano alla tabella richiesta, vogliamo comunque vederli. Per farlo, impostare _with = citys e si otterranno immediatamente i dati sulle città di questo paese.

3) Table Update Data. I dati sono stati ricevuti, ma devono essere trasferiti in una tabella da visualizzare sullo schermo. Per fare ciò, si passano tutte le informazioni (data) ricevute nel blocco precedente, nonché il numero totale di record (count - Total Records), per capire quante pagine devono essere presenti nella tabella.

Il prossimo trigger è onDataUpdate. I dati della tabella possono essere aggiornati a seguito di vari processi aziendali. Quando ciò accade, è meglio specificare una volta sola cosa deve accadere e non inserire gli stessi blocchi in ogni processo aziendale. Nel nostro caso, sarà corretto utilizzare il blocco Table Update Properties ma questa volta per rimuovere la modalità di caricamento (Loading = false), impostata in precedenza, e mostrare che la tabella è pronta a lavorare.

L'ultimo trigger di cui abbiamo bisogno è onFilter. Definisce cosa deve accadere al momento del passaggio ad altre pagine della tabella. Per farlo, ha il parametro _offset che, in base al numero di pagina, indica l'offset necessario per il caricamento dei dati.

Ad esempio, se nel nostro caso ci sono 10 voci in ogni pagina, allora la terza pagina avrà bisogno delle voci da 21 a 30. Questi dati si ottengono da _offset e possono essere passati al blocco Server request GET /country/ blocco. In caso contrario, il processo aziendale coinciderà completamente con il processo sul TableOnShow trigger. In queste situazioni, sarebbe ragionevole avere due diversi trigger che lanciano lo stesso processo aziendale.

Ma nel nostro caso, la differenza importante sta nel parametro _offset parametro. Se si lascia tutto come nell'immagine sottostante, il processo si avvierà in base al trigger, ma si fermerà al momento dell'avvio del processo. onShow ma si fermerà al blocco Server request GET /country/ poiché non può ottenere il valore _offset (è passato da un altro trigger).

Questa situazione si risolve meglio utilizzando le variabili. Vediamo un esempio specifico. Abbiamo bisogno di una variabile di tipo Integer per salvare il _offset valore. Pertanto, utilizziamo un blocco Integer per dichiarare questa variabile, ma due diversi Set Variable per scrivere il suo valore, ciascuno associato a un diverso trigger.

In base all'attivazione Table onShow non abbiamo bisogno di alcun offset, i dati nella tabella vengono mostrati dall'inizio e _offset = 0quindi impostiamo Value = 0 nel blocco Set Variable .

Quando viene lanciato il Table onFilter viene lanciato, abbiamo già ricevuto il valore _offset e vogliamo utilizzarlo, quindi passeremo il valore _offset del trigger come Value al blocco Set Variable al blocco.

Nei passi successivi, i processi di business dei trigger non differiscono l'uno dall'altro, quindi due processi di business vengono combinati in uno, ciascuno con il proprio valore della variabile intera per il parametro _offset parametro.