ORDA – Constructeur et événement touché – Comportement détaillé à travers un réseau

Dans ce précédent billet de blog, vous avez découvert que les entités ORDA peuvent désormais avoir un élément de type constructorce qui permet à l’instanciation des entités de suivre une approche entièrement orientée objet.

Et ce n’est pas tout – un autre article de blog a présenté le premier événement de données ORDA dans une série complète : l’événementtouched .

Vous voulez savoir exactement QUAND et OÙ les événements constructor et l’événementtouched sont déclenchés pendant que les actions vont et viennent entre une application client et le serveur? Cet article de blog est fait pour vous.

Continuez à lire pour connaître tous les détails et découvrir une démonstration en direct !

Si vous n’avez pas encore exploré les événements constructors et l’événementtouched , n’attendez pas – lisez les articles de blog mentionnés ci-dessus. Ils expliquent comment la mise en œuvre doit être effectuée.

HDI_ORDA_Events_Details

avant de commencer

Ces deux fonctionnalités font partie de la couche d’abstraction ORDA complète, puissante et optimisée. Pour vous rafraîchir la mémoire, vous pouvez lire ce billet et celui-ci.

Avec les classes de modèle de données ORDA, les données sont manipulées à travers des entités, qui sont des instances des classes d’entités définies dans votre structure.

ORDA peut être utilisé dans plusieurs types d’applications :

une application Client/Serveur (C/S)
une application Qodly
une application consommant l’API REST
une application utilisant une base de données distante

Où ?

Le tableau ci-dessous résume OÙ les événements constructor et touched sont exécutés :

Où est exécuté	C/S (1)	Page Qodly (2) REST API (3) Remote datastore (4)
Le constructeur	Client	Serveur
L’événement touché	Si mot-clé local: client sinon : serveur	Serveur

(1) : Le projet est déployé sur une instance de serveur 4D et les clients 4D distants y accèdent via une connexion réseau. Les opérations sur les données peuvent être exécutées soit sur le client, soit sur le serveur.

(2) : Le projet est déployé sur une instance de serveur 4D et les clients web interagissent avec lui via un navigateur web. Une application Qodly consomme l’API REST du projet.

(3) : Toute application externe peut consommer l’API REST de votre application 4D en utilisant des requêtes REST standard.

(4) : Une application 4D peut se connecter à un ou plusieurs centres de données distants, permettant ainsi l’accès à plusieurs sources de données. Dans ce cas, ORDA est utilisé pour gérer les opérations sur les données distantes.

Quand ?

Le reste de cet article de blog se concentre sur le moment où l’événement constructor et l’événementtouched sont exécutés.

Pour des raisons d’optimisation et de performance, l’événement constructor n’est pas nécessairement exécutée immédiatement lorsqu’une nouvelle entité est instanciée. Il en va de même pour l’événementtouched . n’est pas nécessairement exécuté immédiatement lorsqu’un attribut est mis à jour.

Voyons maintenant les spécificités de chaque type d’application.

application autonome

Dans une application autonome, le projet est stocké sur votre disque local. Aucune connexion réseau n’est nécessaire pour accéder aux données, de sorte que toutes les opérations sur les données sont effectuées localement et instantanément.

Tout est simple : L’événement constructor et l’événementtouched sont déclenchés immédiatement lorsqu’une nouvelle entité est instanciée ou lorsque la valeur d’un attribut change.

api rest

Ce cas est simple : puisque toutes les actions sur les entités sont effectuées via des requêtes REST au serveur, les événements constructor et l’événementtouched sont déclenchés sur le serveur dès que la requête est exécutée.

client serveur app

le constructeur

Si une nouvelle entité est instanciée sur le client, alors l’événement constructor s’exécute sur le client.

Cela signifie que les valeurs initiales attribuées aux attributs sont immédiatement visibles pour le client. Plus tard, lorsqu’une fonction impliquant cette entité est appelée(par exemple, une fonction qui reçoit l’entité en tant que paramètre), le serveur reçoit l’entité avec ses attributs initialisés sur le client (1).

La fonction peut être une fonction de l’API ORDA ou une fonction du modèle de données ORDA.

(1) Rappelons que les fonctions ORDA sont toujours exécutées sur le serveur.

l’événement touché

Par défaut, l’événement touché est exécuté sur le serveur, mais le mot-clé local vous permet de l’exécuter sur le client.

Sans le mot-clé local :

Dans cet exemple, la fonction apply() est une fonction fictive, destinée à rendre visibles sur le serveur les mises à jour effectuées sur l’entité sur le client.

Avec le mot-clé local :

qodly app

L’événement constructor et l’événementtouched sont exécutés sur le serveur – dès que le serveur a connaissance d’une entité nouvellement instanciée ou d’un attribut modifié.

Lorsqu’elle est rendue, une page Qodly s’exécute dans le navigateur web, mais chaque fois qu’une action nécessite une logique côté serveur, les demandes sont envoyées au serveur 4D par l’intermédiaire de l’API REST.

Le constructeur

Si vous instanciez une nouvelle entité en utilisant l’action standard Create:

cela se produit localement sur le front-end. Le constructeur n’est donc pas exécuté immédiatement. Il s’exécute une fois que le serveur détecte la nouvelle entité instanciée.

Dans cet exemple, la fonction apply() est une fonction fictive, destinée à rendre visibles sur le serveur les mises à jour effectuées sur l’entité sur le client.

Remarque :

Si le front-end instancie une nouvelle entité avec l’action standard Create et définit une valeur pour un attribut utilisé dans le constructeur, cette valeur ne sera pas remplacée par le constructeur lorsqu’il s’exécutera sur le serveur.

En revanche, si l’entité est instanciée par une fonction côté serveur, le constructeur s’exécute immédiatement sur le serveur. La source Qodly renvoyée (entité) comprendra les attributs initialisés par le constructeur.

L’événement touché

L’événementtouched est déclenché sur le serveur dès que celui-ci détecte une valeur d’attribut modifiée.

Dans cet exemple, la fonction apply() est une fonction fictive, juste pour rendre visible sur le serveur les mises à jour effectuées sur l’entité sur le client.

utilisation d’un magasin de données distant

Le fonctionnement est similaire à celui d’une application Qodly, puisque l’utilisation d’un magasin de données distant déclenche desrequêtes en interne à l’aide de l’API REST. Si une nouvelle entité est instanciée dans l’application 4D locale, la commande constructor s’exécute lorsque le serveur en prend connaissance.

Il en va de même pour l’événementtouched – Si une entité est mise à jour dans l’application 4D locale, l’événement est exécuté dès que le serveur détecte un changement dans les attributs de l’entité.

Exemple n° 1

Un constructor est implémenté dans la classe ProductsEntity.

Class extends Entity

Class constructor()
	
	This.creationDate:=Current date()
	This.comment:="Automatic comment"

Ce code est exécuté :

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()

exemple n° 2

Un événementtouched et une fonction apply() sont implémentés dans la classe ProductsEntity :

Class extends Entity

Function event touched comment($event : Object)
	This.comment:=Uppercase(This.comment)

exposed Function apply() : cs.ProductsEntity
	return This