ORDA – Constructor und berührtes Ereignis – Detailliertes Verhalten in einem Netzwerk

In diesem Blog-Beitrag haben Sie erfahren, dass ORDA-Entitäten jetzt auch eine constructorhaben können, wodurch die Instanziierung von Entitäten einem vollständig objektorientierten Ansatz folgen kann.

Und das ist noch nicht alles – in einem anderen Blog-Beitrag wurde das erste ORDA-Datenereignis in einer vollständigen Serie vorgestellt: das Ereignistouched .

Sie möchten genau wissen, WANN und WO das constructor und das Ereignistouched ausgelöst werden, während Aktionen zwischen einer Client-Anwendung und dem Server hin- und herlaufen? Dann ist dieser Blogpost genau das Richtige für Sie.

Lesen Sie weiter, um alle Details zu erfahren und eine Live-Demo zu sehen!

Wenn Sie sich noch nicht mit dem constructors und das touched -Ereignis noch nicht erforscht haben, sollten Sie nicht warten – lesen Sie die oben genannten Blogposts. Sie erklären, wie die Implementierung erfolgen sollte.

HDI_ORDA_Ereignisse_Details

bevor Sie beginnen

Diese beiden Funktionen sind Teil der umfassenden, leistungsfähigen und optimierten ORDA-Abstraktionsschicht. Um Ihr Gedächtnis aufzufrischen, können Sie diesen Blogpost und diesen lesen.

Mit ORDA-Datenmodellklassen werden Daten über Entitäten verarbeitet, die Instanzen der in Ihrer Struktur definierten Entitätsklassen sind.

ORDA kann für mehrere Arten von Anwendungen verwendet werden:

eine Client/Server (C/S) Anwendung
eine Qodly-Anwendung
eine Anwendung, die die REST-API nutzt
eine Anwendung, die einen Remote-Datenspeicher verwendet

Wo?

Die folgende Tabelle fasst zusammen, WO die constructor und touched ausgeführt werden:

Wo wird ausgeführt	C/S (1)	Qodly-Seite (2) REST API (3) Entfernter Datenspeicher (4)
Der Konstruktor	Klient	Server
Das berührte Ereignis	Wenn lokales Schlüsselwort: client sonst: Server	Server

(1): Das Projekt wird auf einer 4D Serverinstanz bereitgestellt, und entfernte 4D Clients greifen über eine Netzwerkverbindung darauf zu. Datenoperationen können sowohl auf dem Client als auch auf dem Server ausgeführt werden.

(2): Das Projekt wird auf einer 4D Serverinstanz bereitgestellt, und Web-Clients interagieren über einen Webbrowser mit ihm. Eine Qodly-Anwendung konsumiert die REST-API des Projekts.

(3): Jede externe Anwendung kann die REST API Ihrer 4D Anwendung mit Hilfe von Standard-REST-Anfragen konsumieren.

(4): Eine 4D Anwendung kann eine Verbindung zu einem oder mehreren entfernten Datenspeichern herstellen und so den Zugriff auf mehrere Datenquellen ermöglichen. In diesem Fall wird ORDA verwendet, um Remote-Datenoperationen zu verarbeiten.

Wann?

Der Rest dieses Blogposts konzentriert sich darauf, WANN das constructor und das Ereignistouched ausgeführt werden.

Aus Optimierungs- und Leistungsgründen wird das Ereignis constructor nicht unbedingt sofort ausgeführt, wenn eine neue Entität instanziiert wird. Dasselbe gilt für das Ereignistouched . Wird nicht unbedingt sofort ausgeführt, wenn ein Attribut aktualisiert wird.

Gehen wir nun auf die Besonderheiten der einzelnen App-Typen ein.

Standalone-App

Bei einer eigenständigen Anwendung wird das Projekt auf Ihrer lokalen Festplatte gespeichert. Für den Datenzugriff ist keine Netzwerkverbindung erforderlich, so dass alle Datenoperationen lokal und sofort ausgeführt werden.

Alles ist ganz einfach: Die constructor und das Ereignistouched werden sofort ausgelöst, wenn eine neue Entität instanziiert wird oder wenn sich ein Attributwert ändert.

rest api

Dieser Fall ist einfach: Da alle Aktionen auf Entitäten über REST-Anfragen an den Server ausgeführt werden, werden sowohl constructor und das Ereignistouched werden auf dem Server ausgelöst, sobald die Anfrage ausgeführt wird.

Client-Server-Anwendung

der Konstruktor

Wenn eine neue Entität auf dem Client instanziiert wird, dann wird der constructor auf dem Client ausgeführt.

Das bedeutet, dass die den Attributen zugewiesenen Anfangswerte für den Client sofort sichtbar sind. Wenn später eine Funktion mit dieser Entität aufgerufen wird(z. B. eine Funktion, die die Entität als Parameter erhält), erhält der Server die Entität mit ihren auf dem Client initialisierten Attributen (1).

Die Funktion kann eine der ORDA-API oder eine ORDA-Datenmodellfunktion sein.

(1) Zur Erinnerung: ORDA-Funktionen werden immer auf dem Server ausgeführt.

das berührte Ereignis

Standardmäßig wird das Ereignis „touched“ auf dem Server ausgeführt, aber mit dem Schlüsselwort local können Sie es stattdessen auf dem Client ausführen.

Ohne das Schlüsselwort local:

In diesem Beispiel ist die Funktion apply() eine Dummy-Funktion, die nur dazu dient, die Aktualisierungen, die an der Entität auf dem Client vorgenommen werden, auf dem Server sichtbar zu machen.

Mit dem Schlüsselwort local:

qodly app

Sowohl constructor als auch das Ereignistouched werden auf dem Server ausgeführt – sobald der Server von einer neu instanziierten Entität oder einem geänderten Attribut erfährt.

Wenn eine Qodly Seite gerendert wird, läuft sie im Webbrowser, aber immer wenn eine Aktion serverseitige Logik erfordert, werden Anfragen über die REST API an den 4D Server gesendet.

Der Konstruktor

Wenn Sie eine neue Entität mit der Standardaktion Create:

geschieht dies lokal auf dem Frontend. Der Konstruktor wird also nicht sofort ausgeführt. Er wird ausgeführt, sobald der Server die neu instanziierte Entität erkennt.

In diesem Beispiel ist die Funktion apply() eine Dummy-Funktion, die nur dazu dient, die Aktualisierungen der Entität auf dem Client auf dem Server sichtbar zu machen.

Anmerkung:

Wenn das Frontend eine neue Entität mit der Standardaktion Create instanziiert und einen Wert für ein im Konstruktor verwendetes Attribut setzt, wird dieser Wert vom Konstruktor nicht überschrieben , wenn er auf dem Server ausgeführt wird.

Wird die Entität hingegen über eine serverseitige Funktion instanziiert, wird der Konstruktor sofort auf dem Server ausgeführt. Die zurückgegebene Qodly-Quelle (Entität) wird die vom Konstruktor initialisierten Attribute enthalten.

Das berührte Ereignis

Das touched Ereignis wird auf dem Server ausgelöst, sobald der Server einen geänderten Attributwert feststellt.

In diesem Beispiel ist die Funktion apply() eine Dummy-Funktion, die nur dazu dient, die Aktualisierungen der Entität auf dem Client auf dem Server sichtbar zu machen.

Verwendung eines entfernten Datenspeichers

Dies funktioniert ähnlich wie eine Qodly-Anwendung, da die Verwendung eines entfernten Datenspeichersintern Anfragen über die REST-API auslöst. Wenn eine neue Entität in derlokalen 4D Anwendung instanziiert wird, wird die constructor ausgeführt, wenn der Server davon Kenntnis erhält.

Das Gleiche gilt für das Ereignistouched . Wenn eine Entität in derlokalen 4D Anwendung aktualisiert wird, wird sie ausgeführt , sobald der Server eine Änderung der Attribute der Entität feststellt.

Beispiel #1

Ein constructor ist in der ProductsEntity Klasse implementiert.

Class extends Entity

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

Dieser Code wird ausgeführt:

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

Beispiel #2

Ein touched Ereignis und eine apply() Funktion sind in der ProductsEntity Klasse implementiert:

Class extends Entity

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

exposed Function apply() : cs.ProductsEntity
	return This