ORDA – Construtor e evento tocado – Comportamento detalhado através de uma rede

Neste post anterior do blogue, descobriu que as entidades ORDA podem agora ter um constructorpermitindo que a instanciação de entidades siga uma abordagem orientada a objetos completa.

E isso não é tudo – outro post do blog apresentou o primeiro evento de dados ORDA em uma série completa: o eventotouched .

Quer saber exatamente QUANDO e ONDE o evento constructor e o eventotouched são acionados enquanto as ações se movem para frente e para trás entre um aplicativo cliente e o servidor? Este blogpost é para você.

Continue lendo para saber todos os detalhes e explorar uma demonstração ao vivo!

Se você ainda não explorou o evento constructors e o eventotouched , não espere – leia os artigos do blogue mencionados acima. Eles explicam como a implementação deve ser feita.

HDI_ORDA_Events_Details

antes de começar

Esses dois recursos fazem parte da camada de abstração ORDA abrangente, poderosa e otimizada. Para refrescar a sua memória, pode ler este blogpost e este.

Com as classes de modelo de dados ORDA, os dados são tratados através de entidades, que são instâncias das classes Entity definidas na sua Estrutura.

O ORDA pode ser utilizado em vários tipos de aplicações:

• uma aplicação Cliente/Servidor (C/S)
• uma aplicação Qodly
• uma aplicação que consome a API REST
• uma aplicação que utilize um datastore remoto

Onde?

A tabela abaixo resume ONDE o evento constructor e touched são executados:

Onde é executado	C/S (1)	Página Qodly (2) API REST (3) Armazenamento de dados remoto (4)
O construtor	Cliente	Servidor
O evento tocado	Se palavra-chave local: cliente senão: servidor	Servidor

(1): O projeto é implementado em uma instância de servidor 4D, e clientes 4D remotos acessam-no através de uma conexão de rede. Operações de dados podem ser executadas tanto no cliente quanto no servidor.

(2): O projeto é implementado em uma instância de servidor 4D, e clientes web interagem com ele através de um navegador web. Uma aplicação Qodly consome a API REST do projeto.

(3): Qualquer aplicação externa pode consumir a API REST de sua aplicação 4D usando pedidos REST padrão.

(4): Uma aplicação 4D pode se conectar a um ou mais datastores remotos, permitindo acesso a múltiplas fontes de dados. Nesse caso, ORDA é usado para lidar com operações de dados remotos.

Quando?

O resto desse blogpost foca em QUANDO o evento constructor e o eventotouched são executados.

Por motivos de otimização e desempenho, o evento constructor não é necessariamente executado imediatamente quando uma nova entidade é instanciada. O mesmo acontece com o eventotouched . Não é necessariamente executado imediatamente quando um atributo é atualizado.

Vamos analisar as especificidades de cada tipo de aplicativo.

aplicativo autônomo

Numa aplicação autónoma, o projeto é armazenado no seu disco local. Não é necessária qualquer ligação de rede para aceder aos dados, pelo que todas as operações de dados são executadas localmente e instantaneamente.

Tudo é simples: Os eventos constructor e o eventotouched são acionados imediatamente quando uma nova entidade é instanciada ou quando um valor de atributo é alterado.

API de repouso

Este caso é simples: uma vez que todas as acções nas entidades são executadas através de pedidos REST ao servidor, tanto o evento constructor e o eventotouched são acionados no servidor assim que o pedido é executado.

aplicação cliente servidor

o construtor

Se uma nova entidade for instanciada no cliente, então o evento constructor é executado no cliente.

Isto significa que os valores iniciais atribuídos aos atributos são imediatamente visíveis para o cliente. Mais tarde, quando uma função que envolve essa entidade é chamada(por exemplo, uma função que recebe a entidade como parâmetro), o servidor recebe a entidade com seus atributos inicializados no cliente (1).

A função pode ser uma da API ORDA ou uma função do modelo de dados ORDA.

(1) Lembre-se de que as funções ORDA são sempre executadas no servidor.

o evento tocado

Por defeito, o evento touched é executado no servidor, mas a palavra-chave local permite-lhe executá-lo no cliente.

Sem a palavra-chave local:

Neste exemplo, a função apply() é uma função fictícia, apenas para tornar visíveis no servidor as actualizações efectuadas na entidade no cliente.

Com a palavra-chave local:

qodly app

Ambos os eventos constructor e o eventotouched são executados no servidor – assim que o servidor toma conhecimento de uma nova entidade instanciada ou de um atributo alterado.

Quando renderizada, uma página Qodly corre no navegador web, mas sempre que uma ação requer lógica do lado do servidor, os pedidos são enviados via REST API para o servidor 4D.

O construtor

Se instanciar uma nova entidade usando a ação padrão Create:

isso ocorre localmente no front end. Então o construtor não é executado imediatamente. Ele é executado quando o servidor detecta a nova entidade instanciada.

Neste exemplo, a função apply() é uma função fictícia, apenas para tornar visíveis no servidor as actualizações feitas na entidade no cliente.

Observação:

Se o front end instanciar uma nova entidade com a ação padrão Criar e definir um valor para um atributo utilizado no construtor, esse valor não será substituído pelo construtor quando este for executado no servidor.

Por outro lado, se a entidade for instanciada através de uma função do lado do servidor, o construtor é executado imediatamente no servidor. A fonte Qodly devolvida (entidade) incluirá os atributos inicializados pelo construtor.

O evento tocado

O eventotouched é acionado no servidor assim que o servidor detecta um valor de atributo alterado.

Neste exemplo, a função apply() é uma função fictícia, apenas para tornar visíveis no servidor as actualizações feitas na entidade no cliente.

utilizando um datastore remoto

Isto funciona de forma muito semelhante a uma aplicação Qodly, uma vez que a utilização de um datastore remoto desencadeiapedidos internamente utilizando a API REST. Se uma nova entidade é instanciada naaplicação 4D local, o constructor é executado quando o servidor fica ciente disso.

O mesmo acontece com o eventotouched – Se uma entidade é actualizada naaplicação 4D local, corre assim que o servidor detecta uma mudança nos atributos da entidade.

exemplo #1

Um constructor é implementado na classe ProductsEntity.

Class extends Entity

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

Este código é executado:

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

exemplo #2

Um eventotouched e uma função apply() são implementados na classe ProductsEntity:

Class extends Entity

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

exposed Function apply() : cs.ProductsEntity
	return This

Este código é executado:

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

Jogue com o HDI anexado para experimentar estes exemplos ao vivo!