In questo precedente post del blog, si è scoperto che le entità ORDA possono ora avere un elemento di tipo constructorpermettendo all’istanziazione delle entità di seguire un approccio completamente orientato agli oggetti.
E non è tutto: un altro post del blog ha introdotto il primo evento di dati ORDA di una serie completa: l’eventotouched .
Volete sapere esattamente QUANDO e DOVE vengono attivati gli eventi constructor e l’eventotouched vengono attivati mentre le azioni si muovono avanti e indietro tra un’applicazione client e il server? Questo blogpost fa al caso vostro.
Continuate a leggere per conoscere tutti i dettagli ed esplorare una demo dal vivo!
Se non avete ancora esplorato gli eventi constructors e l’eventotouched , non aspettate: leggete i blogpost menzionati sopra. Essi spiegano come dovrebbe essere realizzata l’implementazione.
prima di iniziare
Queste due funzioni fanno parte del livello di astrazione ORDA completo, potente e ottimizzato. Per rinfrescare la memoria, potete leggere questo blogpost e questo.
Con le classi del modello di dati ORDA, i dati vengono gestiti attraverso le entità, che sono istanze delle classi Entity definite nella struttura.
ORDA può essere utilizzato in diversi tipi di applicazioni:
- un’applicazione client/server (C/S)
- un’applicazione Qodly
- un’applicazione che utilizza l’API REST
- un’applicazione che utilizza un datastore remoto
Dove?
La tabella seguente riassume DOVE vengono eseguiti gli eventi constructor e touched vengono eseguiti:
| Dove viene eseguito | C/S (1) | Pagina Qodly (2) API REST (3) Archivio dati remoto (4) |
|---|---|---|
| Il costruttore | Cliente | Server |
| L’evento toccato |
Se parola chiave locale: client |
Server |
(1): Il progetto viene distribuito su un’istanza del server 4D e i client 4D remoti vi accedono tramite una connessione di rete. Le operazioni sui dati possono essere eseguite sia sul client che sul server.
(2): Il progetto viene distribuito su un’istanza del server 4D e i client web interagiscono con esso tramite un browser web. Un’applicazione Qodly consuma l ‘API REST del progetto.
(3): Qualsiasi applicazione esterna può consumare l ‘API REST dell’applicazione 4D utilizzando richieste REST standard.
(4): Un’applicazione 4D può connettersi a uno o più archivi di dati remoti, consentendo l’accesso a più fonti di dati. In questo caso, ORDA viene utilizzato per gestire le operazioni sui dati remoti.
Quando?
Il resto di questo blogpost si concentra su QUANDO l’evento constructor e l’eventotouched vengono eseguiti.
Per ragioni di ottimizzazione e di prestazioni, l’evento constructor non viene necessariamente eseguito immediatamente quando viene istanziata una nuova entità. Lo stesso vale per l’eventotouched . non viene necessariamente eseguito immediatamente quando un attributo viene aggiornato.
Vediamo le specifiche per ogni tipo di applicazione.
applicazione standalone
In un’applicazione standalone, il progetto è memorizzato sul disco locale. Non è necessaria alcuna connessione di rete per accedere ai dati, quindi tutte le operazioni sui dati vengono eseguite localmente e istantaneamente.
Tutto è semplice: L’evento constructor e l’eventotouched vengono attivati immediatamente quando viene istanziata una nuova entità o quando viene modificato il valore di un attributo.
rest api
Questo caso è semplice: poiché tutte le azioni sulle entità vengono eseguite tramite richieste REST al server, sia l’evento constructor e l’eventotouched vengono attivati sul server non appena la richiesta viene eseguita.
applicazione client-server
il costruttore
Se una nuova entità viene istanziata sul client, l’evento constructor viene eseguito sul client.
Ciò significa che i valori iniziali assegnati agli attributi sono immediatamente visibili al client. Successivamente, quando viene richiamata una funzione che coinvolge tale entità(ad esempio, una funzione che riceve l’entità come parametro), il server riceve l’entità con i suoi attributi inizializzati sul client (1).
La funzione può essere una delle API ORDA o una funzione del modello di dati ORDA.
(1) Ricordare che le funzioni ORDA vengono sempre eseguite sul server.
l’evento toccato
Per impostazione predefinita, l’evento touched viene eseguito sul server, ma la parola chiave local consente di eseguirlo sul client.
Senza la parola chiave local:
In questo esempio, la funzione apply() è una funzione fittizia, solo per rendere visibili sul server gli aggiornamenti effettuati sull’entità sul client.
Con la parola chiave local:
qodly app
Sia constructor e l’eventotouched vengono eseguiti sul server, non appena il server viene a conoscenza di una nuova entità istanziata o di un attributo modificato.
Quando viene renderizzata, una pagina Qodly viene eseguita nel browser web, ma ogni volta che un’azione richiede una logica lato server, le richieste vengono inviate tramite API REST al server 4D.
Il costruttore
Se si istanzia una nuova entità utilizzando l’azione standard Create:
questo avviene localmente sul front-end. Quindi il costruttore non viene eseguito immediatamente. Viene eseguito quando il server rileva la nuova entità istanziata.
In questo esempio, la funzione apply() è una funzione fittizia, solo per rendere visibili sul server gli aggiornamenti effettuati sull’entità sul client.
Nota:
Se il front-end istanzia una nuova entità con l’azione standard Create e imposta un valore per un attributo usato nel costruttore, tale valore non sarà sovrascritto dal costruttore quando viene eseguito sul server.
D’altra parte, se l’entità viene istanziata tramite una funzione lato server, il costruttore viene eseguito immediatamente sul server. La sorgente Qodly restituita (entità) includerà gli attributi inizializzati dal costruttore.
L’evento touched
L’eventotouched viene attivato sul server non appena il server rileva un valore di attributo modificato.
In questo esempio, la funzione apply() è una funzione fittizia, solo per rendere visibili sul server gli aggiornamenti effettuati sull’entità sul client.
utilizzare un datastore remoto
Il funzionamento è simile a quello di un’applicazione Qodly, poiché l’uso di un datastore remoto attivainternamente lerichieste tramite l’API REST. Se una nuova entità viene istanziata nell’applicazione 4D locale, l’opzione constructor viene eseguito quando il server ne viene a conoscenza.
Lo stesso vale per l’eventotouched : se un’entità viene aggiornata nell’applicazione 4D locale, viene eseguita non appena il server rileva una modifica negli attributi dell’entità.
esempio #1
Un evento constructor è implementato nella classe ProductsEntity.
Class extends Entity
Class constructor()
This.creationDate:=Current date()
This.comment:="Automatic comment"Questo codice viene eseguito:
var $connect:={hostname: "127.0.0.1"}
var $remote : 4D.DataStoreImplementation
var $product : 4D.Entity
var $status : Object
$remote:=Open datastore($connect; "demo")
// The constructor has not been executed yet
// The creationDate and comment attributes are empty
$product:=$remote.Products.new()
// Here the constructor is run because the save() is done on the server
// The server detects it is a newly instantiated entity
// The creationDate and comment attributes are filled
$status:=$product.save()esempio #2
Un eventotouched e una funzione apply() sono implementati nella classe ProductsEntity:
Class extends Entity
Function event touched comment($event : Object)
This.comment:=Uppercase(This.comment)
exposed Function apply() : cs.ProductsEntity
return ThisQuesto codice viene eseguito:
var $connect:={hostname: "127.0.0.1"}
var $remote : 4D.DataStoreImplementation
var $product : 4D.Entity
$remote:=Open datastore($connect; "demo")
$product:=$remote.Products.all().first()
// The comment attribute is not uppercased
$product.comment:="New comment"
// Because the apply() function is called on the server
// the touched event is triggered
// and the comment attribute is now uppercased
$product:=$product.apply()Giocate con l’HDI allegato per provare questi esempi dal vivo!