Ewt et Rap¶

Ce chapitre s'adresse aux personnes qui sont familières avec Rap. Il présente les principaux éléments qui différencient Ewt de Rap et décrit les concepts propres à Ewt qui peuvent être pièges pour une personne habituée à Rap.

Généralités¶

Il convient de préciser d'entrée que Ewt et Rap sont différents à bien des égards, et ne sont pas compatibles entre eux. Cela signifie qu'une application Ewt ne peut pas tourner sur Rap, de même qu'une application Rap ne peut pas tourner sur Ewt. Cela vient des concepts mis en place dans les deux moteurs qui ne sont pas équivalents. D'autre part certains concepts sont propres à l'un ou l'autre des moteurs. Enfin, Ewt est beaucoup plus jeune que Rap et certains éléments n'y sont tout simplement pas encore implémentés, voire ne le seront jamais (car trop spécifiques ou pas applicables sur Ewt).

À titre d'exemple, prenons le cas de l'upload de fichier. Dans Rap, les uploads se font via un servlet dédié (RAPv4VUE.RAP_GenUpld). Le moteur génère alors un autoeval (afterUpload) qui permet à l'application d'exécuter un traitement après upload du fichier. Cette mécanique ne fait pas sens sur Ewt car les données binaires et les données textuelles sont traitées simultanément et via le même servlet: les deux types de données peuvent être transmis à Ewt au sein d'un même formulaire multipart.

Certaines mécaniques de Rap existent également dans Ewt sous une forme différente. Par exemple la notification doc-save dans Ewt joue à la fois le rôle de l'afterPageSave et du onModification de Rap.

D'autres particularités de Rap tels que la table DtaTbl00, le format des noms de champ (R0, R1000, etc.), les secucodes, etc. n'existent pas dans Ewt ou sont mis en œuvre très différemment.

La suite de ce chapitre revient sur un grand nombre d'éléments qui différencient Ewt de Rap.

Code source¶

Le code source de Ewt est très différent de celui de Rap. La structure des classes, l'implémentation de la logique de gestion des requêtes, l'organisation des fonctions de scripts, etc. ont été écrites de zéro pour Ewt.

À l'heure où ces lignes sont rédigées, l'état du code est le suivant:

Lignes	Rap	Ewt
Lignes de code (total)	158'705	104'300
Lignes de code source	114'143	68'143
Lignes de commentaires	23'563	24'541
Classes (nombre)	197	417

Structure d'application¶

Rap s'appuie sur une description métier (fichier descript.rap). Ce fichier décrit la structure de données d'une application. Il est possible de concevoir une application sans modèle, mais ce n'est pas le cadre standard d'une application Rap. Le fichier en lui-même reste obligatoire sous peine de voir apparaître un message du style description missing.

Une application Ewt quant à elle n'a pas forcément besoin d'une description, ni même d'une base de données ou de feuilles de styles. Une application Ewt peut être constituée uniquement d'un fichier de configuration (qui déclare les notifications à envoyer) et de scripts de traitement (qui traitent les requêtes et y répondent). Ce type d'application peut par exemple faire office de service web, de proxy, etc.

Descript, dossier, pages S et page M¶

La structure de la descript d'une application Ewt diffère de celle d'une application Rap. Ewt s'appuie sur les notions de modèle, de groupe et de champ, que l'on peut plus ou moins mettre en relation avec les notions de modèle, page et champ de Rap. Le fichier de documentation descript présente la descript de manière plus détaillée.

Les groupes

Attention, un groupe sur Ewt n'a rien à voir avec un groupe sur Rap. La notion de "groupe" dans Ewt est plus proche de la notion de "page" de Rap dans la mesure où les groupes Ewt peuvent être single ou multi (dans Rap, les pages peuvent être de type S ou M).
Toutefois l'analogie s'arrête là, car le groupe sous Ewt n'aborde pas la question d'affichage comme le fait la page sur Rap via l'attribut style. En fait on peut considérer que la notion de "page" de Rap est le cumul des notions de "groupe" et de "vue" dans Ewt. La notion de "vue" est présentée plus bas dans ce document.

Par ailleurs, la descript de Rap englobe à la fois les aspects de structure (description des modèles, des pages, des champs, etc.) et les aspects de stockage (table et colonne de destination). Dans Ewt, ces deux aspects sont distincts : un fichier descript.xml se charge de décrire la structure logique alors qu'un fichier schema.xml décrit la structure physique de la base de données. Cela concerne autant les tables de données que les tables d'infrastructure.

Dossier¶

Rap et Ewt gèrent tous deux des dossiers. Toutefois il y a des différences au niveau de leur structure, de la façon de les identifier et de les mettre à jour.

Rap s'appuie sur une table DtaTbl00 dans laquelle sont inventoriés tous les dossiers de l'application. Par convention, l'identifiant de dossier est enregistré dans un champ R0.

Sur Ewt il n'existe pas de table centrale analogue à DtaTbl00. Il n'existe pas non plus de convention concernant le champ réservé à l'identifiant de
dossier. Cela signifie qu'au niveau de la descript, on indiquera pour chaque modèle le nom du champ qui porte le rôle d'identifiant (le développeur est libre de conserver le nom R0 s'il le désire) et dans quelle table cet identifiant est stocké (pour autant que l'application utilise une base de données).

Sur Ewt, les dossiers doivent impérativement être identifiés au moyen de leur identifiant ET de leur nom de modèle. En effet, il est possible que des dossiers de modèles différents aient un même identifiant. C'est particulièrement vrai lorsque l'on utilise des identifiants de type int.

Cela vient du fait que Ewt s'appuie sur une structure volontairement proche de la structure des données en base de données. La notion de tuple est d'ailleurs très importante sur Ewt: pour rappel un tuple correspond plus ou moins à une ligne dans une table de la base de données et possédant une primary key. Un dossier Ewt n'est donc rien d'autre qu'un tuple, éventuellement complété par d'autres tuples liés.

L'identifiant d'un tuple n'est pas unique dans l'absolu, tout comme une clé primaire n'est pas unique dans l'absolu: il est tout à fait possible que deux tables distinctes possèdent toutes deux une ligne portant un clé primaire équivalente. Sur Ewt un dossier doit donc être identifié au moyen de son modèle et de son identifiant (de la même façon qu'une ligne de data doit être identifiée par le nom de sa table et de sa primary key au niveau de la base de données).

Notons au passage que par défaut Ewt délègue la création des identifiants de tuples (et donc de dossiers) au SGBD. Le format d'identifiant par défaut est l'entier (type int). Il est toutefois possible d'opter pour d'autres formats tels que le bigint ou l'uuid si le SGBD le supporte. Ewt autorise également le format snowflake, mais ce dernier n'est pas généré par le SGBD.

Pages S et pages M¶

Le concept champ S ou M existe dans Ewt, mais pas de la même façon que dans Rap. En premier lieu, la notion de page est volontairement absente de Ewt car elle a une connotation trop orientée "affichage". Ewt cherche à rester proche des données et préfère la notion de groupe. Le groupe est un ensemble de champs, de la même façon qu'une table est un ensemble de colonnes. Un groupe Ewt correspond donc à une page de Rap en tant que conteneur, mais l'analogie s'arrête là car les autres notions associées à la page de Rap ne se retrouvent pas forcément au niveau du groupe dans Ewt. Par exemple, une page dans Rap peut contenir des champs issus de différentes tables, mais ce n'est pas permis sur Ewt.

Continuons avec la façon de distinguer les types de pages. Sur Rap, la distinction entre une page S et une page M se fait au moyen du style (premier caractère du nom de la feuille de style). Sur Ewt, la distinction se fait au moyen d'un attribut type qui peut prendre les valeurs single ou multi. La notion de page d'alias sur Ewt est quant à elle gérée au moyen de vues. Pour faire simple, une vue est une organisation de groupes qui s'affiche au moyen d'un style, de la même façon qu'une page d'alias est une organisation de pages qui s'affichent au moyen d'une feuille de style.

Dans Rap, chaque dossier possède habituellement une page S. Cette dernière déclare notamment les champs de base (R0, R999997 et R999999). De la même manière, Ewt part du principe que tout dossier contient au moins un tuple principal. L'identifiant de ce tuple principal permet d'identifier le dossier: ainsi un dossier Ewt est donc identifié au moyen de son modèle et de l'identifiant de son tuple principal. Ewt ne prévoit pas de noms pré-définis équivalents aux champs R0, R999997 et R999999. Les champs servant à l'enregistrement de l'identifiant et du statut doivent être déclarés dans le fichier descript.xml. Ewt ne prévoit pas de champ pour enregistrer le modèle étant donné que le modèle est nécessaire à l'identification du dossier (voir chapitre précédent.

La descript permet bien d'indiquer si un groupe est de type single ou multi, mais ceci mis à part, les champs mono ou multi-valués se présentent tous de la même façon : ils appartiennent à un tuple qui possède un identifiant unique au sein de leur table en base de données (= primary key). En conséquence, on ne retrouvera jamais une ligne multi d'un dossier portant le même identifiant qu'une ligne multi d'un autre dossier du même modèle.

Voyons ce que cela implique. Une page M de Rap doit contenir un champ qui reprend le R0 du dossier et un second champ qui est un identifiant de ligne unique au sein du dossier. En l'absence de tel champ, Rap s'appuie sur les valeurs entières ou texte du tuple.

Sur Ewt, on retrouve également un identifiant de dossier (ou plus exactement une référence à l'identifiant du tuple principal du dossier) et un identifiant de tuple qui tient le rôle de l'identifiant de ligne. La grande différence ici est que cet identifiant de ligne est obligatoire et il est unique sur toute la table, car il s'agit de l'identifiant de tuple de la ligne multi. Cet identifiant est donc suffisant pour identifier une ligne de groupe multi. Ewt n'implémente donc pas d'identification de ligne basée sur les valeurs entières ou texte comme le fait Rap.

Champs de formulaire¶

Dans Ewt, les champs single ou multi peuvent tous être représentés au moyen d'une notation commune (on l'appellera contexte) contenant le nom de modèle, l'identifiant du tuple principal (= numéro de dossier), le nom de groupe (= page), l'identifiant de tuple et le nom de champ.

Le contexte ainsi défini peut être exprimé selon forme suivante:

model[3].group[2].abc

Ici model désigne le nom du modèle de dossier, la valeur 3 est l'identifiant de dossier, group désigne le nom du groupe, 2 désigne l'id de tuple et abc est le nom du champ. Cette notation de contexte joue un grand rôle dans Ewt car elle est réutilisée à de nombreux endroits: au niveau des champs de formulaire HTML, au niveau des scripts, au niveau de la descript, etc.

Ainsi, un champ HTML qui représente un champ de dossier peut être défini de la manière suivante, qu'il s'agisse d'un champ "S" ou d'un champ "M" :

<input type="text"
       name="EWT:DATA-model[3].group[2].abc"
       value="ma valeur"/>

Remarque concernant la sécurité

Il ne serait pas prudent de réutiliser la notation de contexte ci-dessus dans un champ de formulaire HTML. En effet, un champ dans lequel le contexte apparaît en clair comme ci-dessus serait trop facilement corruptible.

Dans les faits, chaque champ HTML est représenté au niveau du formulaire HTML par un contexte exprimé sous la forme d'un hash. Dans le cas de notre champ, on aurait donc:

<input type="text"
       name="EWT:DATA-3ed048d41e274cbea72704a6792e52f4"
       value="ma valeur"/>

Ewt se charge de maintenir au sein de la session une table de correspondance entre les contextes et leur représentation en hash. Ces derniers sont en outre régénérés à chaque session (voir paragraphe ci-dessous concernant les sessions).

Le document 11 - script revient sur la notion de contexte. Il décrit un outre différentes manières d'exprimer le contexte (notation raccourcie, contexte implicite, notation "sharp", etc.)

Sessions¶

L'une des différences majeures entre Ewt et Rap est l'utilisation d'une session cliente. Une session client est automatiquement créée à la première requête envoyée par un client à Ewt. La session a une durée de vie ainsi qu'une durée d'inactivité définies (voir propriétés sessionTTL et sessionEOL de la config).

La session enregistre différents paramètres relatifs à l'activité du client: dossier(s) ouvert(s), objets véhiculés entre les requêtes, table de correspondances entre hash et contextes, etc.

La session joue également un rôle de sécurité. Elle permet de vérifier que les données reçues via une requête sont cohérentes avec ce qui avait été livré lors de la réponse précédente. Par exemple, si Ewt génère un arbre de sortie dans lequel il indique qu'un champ est en lecture seule, il ne s'attend pas à recevoir de valeur pour ce champ. Une erreur est générée si ce cas de figure se présente. La session joue également un rôle pour les performances: elle permet de stocker des données en mémoire entre les différentes requêtes, ce qui évite les échanges coûteux avec la base de données.

Il est important de garder à l'esprit cette notion de session lors du développement d'une application. En particulier, il faut être conscient que lorsqu'on ouvre un dossier, Ewt charge ce dossier en mémoire et le conserve jusqu'à sa fermeture ou jusqu'à la fin de la session. Cela peut être source d'incompréhension, en particulier lorsqu'on a l'habitude de travailler sur des applications Rap. Ewt encourage le développeur à effectuer les traitements au niveau de la session plutôt qu'au niveau de la base de données. Prenons un exemple pour illustrer cela. Le script ci-dessous effectue une mise à jour de champs en DB au moyen d'une requête SQL (ici au moyen d'un prepared statements):

$sql.update(`update ListeArticle
             set ( idVenteEchange,
                   idVendeur, Password,
                   Nom, Prenom,
                   Adresse, Localite,
                   EMail, Telephone ) =
                 ( select ?,
                          idVendeur, ?,
                          Nom, Prenom,
                          Adresse, Localite,
                          EMail, Telephone
                   from Vendeur
                   where idVendeur=? )
             where idListeArticle=?`::T,
            [ refVenteEchange, secret, currdoc, newdoc ] );

Cette opération met à jour les champs directement au niveau de la base de données. Si l'update porte sur un dossier actuellement ouvert par l'utilisateur, cela crée une désynchronisation entre les informations stockées au niveau de la session et celles stockées au niveau de la base de données. En outre la requête ci-dessus ne tient pas compte du type de lock qui peut exister sur le tuple modifié.

Dans le cas présent, il importe donc de forcer un reload des données de la session à partir des valeurs de la base de données au moyen de la fonction $data.reload("listeArticle[${newdoc}]") (ici "listeArticle[${newdoc}]" définit le contexte de notre dossier en notation raccourcie).

Gestion de droits¶

La gestion de droits change radicalement de Rap et s'appuie sur des policies. Le concept de policies s'appuie sur les notions d'identity policy (politique basée sur les identités) et de resource policy (politique basée sur les ressources) mises en place dans l'IAM d'AWS.

Très brièvement, une policy est un fichier XML décrivant une ou plusieurs règles de sécurité qui concernent une ou plusieurs identités, ou qui s'appliquent à une ou plusieurs ressources.

Les policies offrent différents avantages:

elles permettent de regrouper toutes les règles de sécurité à un même endroit
elles sont faciles à évaluer par le moteur, ainsi elles permettent très rapidement de savoir si un utilisateur a le droit d'effectuer telle ou telle action, de modifier un champ, d'effectuer un changement d'état, etc.
elles permettent une gestion des droits au moyen de règles statiques, de requêtes SQL, de script, etc.

Le document policy présente les aspects de sécurité plus en détail.

États¶

Le concept d'état dans Ewt est actuellement assez basique et fera certainement l'objet d'améliorations à l'avenir. On notera quelques différences avec Rap.

Ewt ne gère pas un seul fichier de description d'états, mais plusieurs fichiers de descriptions de modèles d'états. Cela permet de décrire différents cycles de vie de dossier. Chaque modèle de dossier, pour autant qu'il souhaite implémenter une gestion d'états, indiquera quel modèle d'états il souhaite mettre en œuvre. Il devra aussi déclarer dans quel champ la valeur d'état devra être enregistrée (dans Ewt, il n'y a pas de champ pré-défini pour enregistrer l'état).

Dans Ewt, la gestion d'états se concentre principalement sur les transitions d'états. Ainsi, on effectuera un changement d'état en indiquant quelle transition doit être réalisée à partir de l'état courant. À noter que l'action setState autorise également le changement d'état explicite.

Tous les aspects de sécurité qui peuvent découler de l'état d'un dossier (verrouillage de champs, autorisation d'exécuter une action, etc.) est déléguée aux policies. Chaque policy peut spécifier si une transition est autorisée ou refusée.

Le document statemodel décrit le modèle d'états de Ewt.

Lock de dossiers¶

Rap implémente un système de lock dit "pessimiste" : pour prévenir tout risque de conflit, il appose un lock sur le dossier à l'ouverture d'un
dossier en écriture puis libère ce lock à la fermeture du dossier.

Ewt implémente également ce système de lock, mais il ne s'agit pas du mode par défaut. De base, une application Ewt utilise un lock "optimiste". Dans ce cas, le moteur n'appose pas de lock au moment de l'ouverture, mais vérifie qu'il n'y a pas eu de modification de valeur au moment de l'enregistrement. On parle de lock "optimiste" car le moteur s'attend a priori à ce qu'il n'y ait pas de conflit. L'utilisateur n'est invité à traiter le conflit que cela est nécessaire.

Il est possible de spécifier le type de lock à utiliser pour chaque modèle.

Typage¶

Rap s'appuie principalement sur des données au format String: les identifiants, les dates, les variables RET, les retours de fonctions RET, etc. sont toutes stockées en tant que String, que ce soit au niveau de la base de données ou de la représentation en mémoire.

Ewt utilise des données typées (ou pseudo-typées dans certains cas). Ainsi, les dates, les heures et les horodates sont stockées en base de données comme de vraies dates, heures ou timestamps lorsque le SGBD le supporte. Le langage de script utilise également le typage de valeurs. Il supporte les types suivants: array, map, date, time, timestamp, file, function, object, method, null et value (qui englobe les types string, number (entier ou décimal) et boolean en fonction de la valeur). La documentation 11 - script revient sur ces types.

Sous Ewt, la représentation textuelle de certains types de données peut varier de celle utilisée dans Rap. Par exemple, les dates sont représentées au format standardisé iso-8601 étendu yyyy-mm-dd sous Ewt alors que Rap utilise le format iso-8601 basique yyyymmdd.

Stockage de binaires¶

La gestion des données binaires varie entre Ewt et Rap à différents niveaux.

Upload: L'upload de fichiers sur Rap se fait au moyen d'un servlet spécifique. Sur Ewt, l'upload d'un fichier se fait via le même servlet que les autres données de dossiers.
Nom de fichier: Rap effectue un encodage des valeurs binaires stockées dans des champs de dossier pour y préfixer le nom de fichier. Ewt n'effectue pas d'encodage de la sorte. Pour enregistrer le nom de fichier, mais également la taille et le mimetype, Ewt s'appuie sur des champs de métadonnées. Il s'agit de champs associés à un champ principal. Le document 04 - descript revient sur ce concept.
Formats: Ewt permet de stocker les binaires en tant que tableaux de bytes (comme Rap), mais également en tant que référence d'objet lorsque le SGBD le supporte. Voir PostgreSQL et les blobs

Nom d'application¶

Une application Ewt n'a pas réellement de nom. Le fichier de config config.xml possède bien une entrée applicationName, mais celle-ci est purement décorative. Le moteur ne fait que de reprendre la valeur au niveau de l'arbre de sortie, pour permettre à l'interface d'afficher un nom. La valeur indiquée dans cette entrée ne joue aucun rôle métier. En réalité, on accède à une application Ewt en précisant dans l'URL le nom du dossier dans lequel l'application est déployée.

Ainsi, aucun fichier de configuration de Ewt ne fait référence à un nom d'application. Cela offre différents avantages: un même fichier peut être repris dans une autre application sans nécessiter aucun changement. De plus, il est possible de faire fonctionner en parallèle plusieurs fois une même application sans que ces différentes instances n'entrent en conflit.

Styles¶

Dans Rap, les feuilles de style XSL et les ressources (images, fichiers css, javascript, etc.) sont présents dans un même répertoire (éventuellement dans des sous-répertoires). À l'exécution, les styles et les ressources doivent être présents au niveau du dossier de déploiement du serveur d'application (typiquement dans le WAR).

Sur Ewt, les styles et les ressources sont gérés différemment. Ewt part du principe que les styles (les fichiers XSL) sont des éléments qui font partie de l'application, au même titre que la descript, le fichier de config et ou les fichiers de scripts. Ils ne doivent pas être exposés. En revanche, les ressources (fichiers css, javascript, images, icones, etc.) sont des éléments qui doivent remonter jusqu'au client (le navigateur utilisé par l'utilisateur) et doivent être exposés, et donc déployés dans le WAR.

Les fichiers XSL et les ressources ne sont donc pas mélangés au niveau des fichiers de l'application (on les place dans des répertoires séparés). Comme mentionné ci-dessus, seules les ressources sont déployées dans le WAR à l'initialisation de l'application ou au reset. Elles peuvent même être enregistrées dans le projet sous la forme de ZIP : le moteur se charge de dézipper automatiquement les ressources (il faut pour cela que l'archive ZIP soit accompagnée d'un fichier homonyme portant l'extension .dounzip).

Les feuilles de styles quant à elles ne sont pas recopiées dans le WAR. Elles sont utilisées depuis le dossier de l'application directement.

Les fichiers XSL utilisés par des scripts (par exemple un XSL utilisé pour créer un document PDF) peuvent se trouver dans un autre répertoire de l'application.

Sur Rap les styles sont référencés directement: par exemple l'identifiant "S1" référence la feuille de style "S1.xsl". Ewt ajoute une couche d'abstraction et ne permet pas le référencement direct. Ainsi, une feuille de style doit être déclarée au niveau de la configuration et est identifiée au moyen d'un nom au sein de l'application. L'application ne peut pas référencer un fichier XSL directement : celui-ci doit être référencé au moyen d'un nom de style déclaré dans le config.

Langage de script¶

Le langage de script de Ewt joue le rôle du langage RET de Rap, c'est-à-dire un langage permettant de décrire des calculs, des processus, des tâches, etc. La syntaxe de la version Ewt s'apparente quant à elle au REX, mais se distingue de celui-ci sur certains aspects:

Le langage script est utilisable nativement dans Ewt, sans nécessité de compilation en un sous-langage (le RET dans le cas de Rap)
Les scripts sont pré-chargés par Ewt et pré-compilés au chargement de l'application par le moteur. Les éventuelles erreurs de syntaxes sont donc identifiées immédiatement au démarrage de l'application.
Sans indication d'encoding, les fichiers de script sont traités en utf-8 par défaut. Il est possible de déclarer un encoding au moyen d'une annotation.
L'extension est .ewts (ou .script) pour les scripts et .ewtsub (ou .subscript) pour les dépendances. En réalité les dépendances ont exactement la même forme que les scripts eux-mêmes, on utilisera une extension différente (.ewtsub ou .subscript) par convention pour faciliter l'identification des dépendances et éviter que le loader de script ne les charge comme des scripts)

Au niveau de la syntaxe, on peut relever les différences suivantes:

Les variables ont une portée locale (appelée "scope"), comme c'est le cas sur la plupart des languages (mais pas RET/REX, où les variables sont toutes globales)
Les instructions return, switch, break, ainsi que des boucles for ou while sont implémentées de la même façon qu'en java. En particulier, le return met fin immédiatement à l'évaluation d'une fonction, le break stoppe immédiatement les itérations d'une boucle et le continue saute immédiatement à l'itération suivante.
Il est possible de mettre fin immédiatement à l'exécution d'un script au moyen de l'instruction exit.
Le langage de script supporte la gestion d'exceptions via les mots-clés try, catch, throw et finally
Le langage de script est typé : il supporte les types number, string, date, time, timestamp, file, array, map, ainsi que les objets java (mais ces derniers ne sont utilisables que comme référence, ils ne peuvent pas être modifiés depuis un script)
Le langage supporte nativement les notations de représentation de tableaux (p.ex [ 1, 2 ]) et de maps (ou dictionnaire, p.ex { x : 1, y : 2 })
Le langage implémente nativement les opérateurs arithmétiques +, -, *, / et % (modulo). Cela signifie que ces opérateurs sont calculés par le processeur chargé d'évaluer le script et non par une fonction "ADD", "SUB", etc. qui serait définie au niveau d'une librairie.
Le langage est capable de gérer les valeurs infinies (en positif et négatif), les valeurs NaN ainsi que le zéro négatif.
Les valeurs booléennes sont, en interne, associées aux valeurs 0 (false) et 1 (true). Au niveau du langage de script, on utilisera toutefois exclusivement les mots clés false et true et non 0 ou 1 pour que le moteur de script sache s'il doit traiter une valeur en tant que booléen ou en tant qu'entier.
Les erreurs d'exécution de script retournent une information sur la position où l'erreur s'est produite dans le script
Les scripts sont génériques : ils ne contiennent pas de référence à une application en particulier.
Le moteur intègre un debugger compatible DAP (Debug Adapter Procotol), ce qui signifie qu'un script Ewt peut être débuggué directement depuis un outil compatible, tel que VS Code.
Le langage de script d'Ewt introduit un nouveau délimiteur de chaînes de caractères: le caractère ` peut être utilisé en plus de " et '. Les valeurs échappées \n, \r, \t, etc. sont interprétées comme dans en java.

Internationalisation¶

L'internationalisation (le multi-linguisme) est géré au moyen de bundles de ressources et la locale est interprétée en fonction du navigateur plutôt qu'en fonction du serveur. En clair: on s'appuie sur la locale du browser pour déterminer comment gérer la langue, les formatages de valeurs/dates, etc.

Servlets¶

Ewt fournit un nombre réduit d'endpoints. La table ci-dessous donne les correspondances entre les endpoints par défaut de Rap et de Ewt.

Endpoint Rap	Endpoint Ewt	Remarque
`monitor`		Certaines fonctions d'administration sont prises en charge par l'action `admin`, appelable via l'endpoint `web`
`ping`
`file`	`data`	L'endpoint `data` est en cours de développement mais permet déjà le téléchargement de données blob en provenance de la base de données.¹
`upload`	`web`	L'upload de fichier se fait au moyen d'un formulaire multipart à envoyer sur l'endpoint `web`
`uploadEx`	`web`	Idem ci-dessus
`uploadSub`	`web`	Idem ci-dessus
`image`	`data`
`print`	`web`
`rest`	`rest`
`select`		Il n'existe pas de servlet dans Ewt qui remplisse le même rôle que `select`, mais la fonctionnalité peut être réalisée au moyen d'un script, via les endpoints `web` ou `rest`.
`services`	`soap`
`goRAP`	`web`
`webdav`		Non pris en charge dans la version actuelle de Ewt
	`websocket`

Correspondances Ewt <-> Rap¶

La suite de ce chapitre est une sorte de FAQ sur la manière de transposer une fonctionnalité de Rap vers Ewt.

Variables d'output - véhiculer une valeur depuis un script vers l'arbre de sortie¶

Sur Rap, on utilise une variable d'output pour le faire.

Sur Ewt, on peut utiliser une variable transient ou persistent, ou créer un objet de session, voire un objet de thread.

Imprimer un PDF¶

Rap fournit diverses fonctions pour imprimer un PDF : l'impression est possible au moyen de la fonction doPrint, ou en RET au moyen des méthodes PRINTDOC et PRINTDOCNOPAGE.

Ewt ne fournit qu'une seule manière d'imprimer un PDF, il s'agit de la méthode $pdf.generate.

Sur Rap, il est d'usage d'utiliser l'endpoint file pour récupérer un fichier généré dans le dossier temporaire: l'application crée un fichier dans le dossier temporaire (un PDF, un document Word, un zip, etc.) et force la page web à relancer une requête au serveur via file pour entraîner un téléchargement du fichier en question.

Ce mode opératoir ne s'applique pas dans le cas d'Ewt: le fichier généré par une application est immédiatement retourné dans la réponse. Il n'est donc pas nécessaire de forcer un second appel au serveur pour le récupérer. ↩