En esta entrada de blog anterior, descubrió que las entidades ORDA ahora pueden tener un atributo constructor permitiendo que la instanciación de las entidades siga un enfoque completamente orientado a objetos.
Y eso no es todo, otra entrada de blog presentó el primer evento de datos ORDA en una serie completa: el evento touched.
¿Quiere saber exactamente CUÁNDO y DÓNDE se activan los eventos constructor y el evento touched se disparan mientras las acciones van y vienen entre una aplicación cliente y el servidor? Este blog es para usted.
Sigua leyendo para conocer todos los detalles y ver una demostración en directo.
Si aún no ha explorado los eventos constructors y el evento touched, no espere, lea las publicaciones de blog mencionadas anteriormente. En ellos se explica cómo debe realizarse la implementación.
antes de empezar
Estas dos funcionalidades forman parte de la completa, poderosa y optimizada capa de abstracción ORDA. Para refrescar la memoria, puede leer este blog y este otro.
Con las clases del modelo de datos ORDA, los datos se manejan a través de entidades, que son instancias de las clases de entidades definidas en su estructura.
ORDA puede ser utilizado en múltiples tipos de aplicaciones:
- una aplicación Cliente/Servidor (C/S)
- una aplicación Qodly
- una aplicación que consume la API REST
- una aplicación que utiliza un datastore remoto
¿DÓNDE?
La siguiente tabla resume DÓNDE se ejecutan los eventos constructor y touched:
| Dónde se ejecuta | C/S (1) | Página Qodly (2) REST API (3) Almacén de datos remoto (4) |
|---|---|---|
| El constructor | Cliente | Servidor |
| El evento touched |
Si palabra clave local: cliente |
Servidor |
(1): El proyecto se despliega en una instancia del servidor 4D, y los clientes 4D remotos acceden a él a través de una conexión de red. Las operaciones de datos pueden ejecutarse tanto en el cliente como en el servidor.
(2): El proyecto se despliega en una instancia del servidor 4D, y los clientes web interactúan con él a través de un navegador web. Una aplicación Qodly consume la API REST del proyecto.
(3): Cualquier aplicación externa puede consumir la API REST de su aplicación 4D utilizando peticiones REST estándar.
(4): Una aplicación 4D puede conectarse a uno o más datastores remotos, permitiendo el acceso a múltiples fuentes de datos. En este caso, ORDA se utiliza para manejar las operaciones de datos remotos.
¿Cuándo?
El resto de este blog se centra en CUÁNDO se ejecutan los eventos constructor y el evento touched.
Por razones de optimización y rendimiento, el evento constructor no es necesariamente ejecutado inmediatamente cuando una nueva entidad es instanciada. Lo mismo ocurre con el evento touched. no se ejecuta necesariamente de forma inmediata cuando se actualiza un atributo.
Veamos los detalles de cada tipo de aplicación.
aplicación autónoma
En una aplicación autónoma, el proyecto se almacena en el disco local. No se necesita una conexión de red para acceder a los datos, por lo que todas las operaciones con datos se realizan localmente y al instante.
Todo es muy sencillo: los eventos constructor y el evento touched se activan inmediatamente cuando se instancia una nueva entidad o cuando cambia el valor de un atributo.
api rest
Este caso es sencillo: como todas las acciones sobre las entidades se realizan a través de peticiones REST al servidor, tanto el evento constructor y el evento touched se activan en el servidor en cuanto se ejecuta la solicitud.
aplicación cliente servidor
el constructor
Si se instancia una nueva entidad en el cliente, entonces el evento constructor se ejecuta en el cliente.
Esto significa que los valores iniciales asignados a los atributos son inmediatamente visibles para el cliente. Más tarde, cuando se llama a una función que involucra a esa entidad (por ejemplo, una función que recibe la entidad como parámetro), el servidor recibe la entidad con sus atributos inicializados en el cliente (1).
La función puede ser una de la API ORDA o una función del modelo de datos ORDA.
(1) Recuerde que las funciones ORDA siempre se ejecutan en el servidor.
el evento toUCHED
Por defecto, el evento touched se ejecuta en el servidor, pero la palabra clave local le permite ejecutarlo en el cliente en su lugar.
Sin la palabra clave local:
En este ejemplo, la función apply() es una función ficticia, sólo para hacer que las actualizaciones hechas en la entidad en el cliente sean visibles en el servidor.
Con la palabra clave local:
qodly app
El evento constructor como el evento touched se ejecutan en el servidor, tan pronto como el servidor tiene conocimiento de una entidad recién instanciada o de un atributo modificado.
Cuando se renderiza, una página Qodly se ejecuta en el navegador web, pero cuando una acción requiere lógica del lado del servidor, las peticiones se envían a través de la API REST al servidor 4D.
El constructor
Si instanciamos una nueva entidad utilizando la acción estándar Create:
esto ocurre localmente en el front-end. El constructor no se ejecuta inmediatamente. Se ejecuta una vez que el servidor detecta la nueva entidad instanciada.
En este ejemplo, la función apply() es una función ficticia, sólo para hacer visibles en el servidor las actualizaciones realizadas en la entidad en el cliente.
Nota:
Si el front end instancia una nueva entidad con la acción estándar Create y define un valor para un atributo utilizado en el constructor, ese valor no será sobrescrito por el constructor cuando se ejecute en el servidor.
Por otro lado, si la entidad se instancia a través de una función del lado del servidor, el constructor se ejecuta inmediatamente en el servidor. La fuente Qodly devuelta (entidad) incluirá los atributos inicializados por el constructor.
El evento toUCHED
El evento touched se activa en el servidor en cuanto éste detecta un cambio en el valor de un atributo.
En este ejemplo, la función apply() es una función ficticia, sólo para hacer visibles en el servidor las actualizaciones realizadas en la entidad en el cliente.
utilizar un almacén de datos remoto
Esto funciona de forma muy similar a una aplicación Qodly, ya que el uso de un almacén de datos remoto desencadena solicitudes internamente utilizando la API REST. Si una nueva entidad es instanciada en la aplicación 4D local, el comando constructor se ejecuta cuando el servidor tiene conocimiento de ello.
Lo mismo ocurre con el evento touched, si una entidad se actualiza en la aplicación 4D local, se ejecuta tan pronto como el servidor detecta un cambio en los atributos de la entidad.
ejemplo #1
Un constructor es implementado en la clase ProductsEntity.
Class extends Entity
Class constructor()
This.creationDate:=Current date()
This.comment:="Automatic comment"Este código es ejecutado:
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()ejemplo #2
Un evento touched y una función apply() son implementados en la clase ProductsEntity:
Class extends Entity
Function event touched comment($event : Object)
This.comment:=Uppercase(This.comment)
exposed Function apply() : cs.ProductsEntity
return ThisEste código se ejecuta:
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()¡Juega con el IDH adjunto para probar estos ejemplos en vivo!