Faq

Ce document tente de répondre à quelques questions qui peuvent apparaître au cours du développement d'une application Ewt.

Ewt peut-il faire tourner une application Rap ?

Non. Sur certains aspects, le fonctionnement de Ewt est assez éloigné de celui de RAP. Prenons l'exemple de l'upload de fichier. Sous RAP, les uploads doivent se faire soit via une servlet upload (ou ses dérivés), soit via la servlet rest. Dans le cas de la servlet upload, RAP déclenche l'évaluation d'un auto-eval afterUpload dans lequel l'application effectue des traitements spécifiques.

Ewt gère les uploads différemment : la ressource binaire est traitée directement depuis le formulaire de champs via la sevlet web. Ewt ne déclenche pas d'événement particulier suite à l'upload d'un binaire.

Ce changement de fonctionnement entraîne une structure et une mécanique de fonctionnement assez différente dans les deux cas. Cela ne s'applique pas qu'à l'upload, mais également à de nombreux autres aspects (scripts, gestion des status, recherche, etc.)

Lorsque j'upload un fichier dans un champ, le nom de ce fichier apparaît

dans le champ, mais disparaît du champ à la prochaine ouverture du dossier

L'enregistrement du nom de fichier doit se faire à l'aide de metadonnées associées au champ. En l'absence de métadonnée file:name, le nom de fichier n'est pas conservé que durant le temps de vie du cache de session. Il est ensuite perdu pour les ouvertures suivantes du dossier car il ne peut pas être conservé en base de données. Si le nom du fichier, sa taille et/ou son mime-type doivent être conservés, il faut alors rattacher des champs de métadonnée au champ dans lequel est stocké ledit fichier.

Mon dossier contient un champ binaire, mais je ne retrouve pas le

fichier dans le temp lorsque j'ouvre le dossier.

Ewt ne recharge pas systématiquement en local les données binaires liées à un dossier. Pour des raisons de performances, les données binaires ne sont chargées que lorsque cela est nécessaire, c'est-à-dire lorsque le client le demande explicitement.

Par conséquent, lorsque l'on charge un dossier, les données binaires ne sont pas reprises de la base de données. Par contre les éventuelles metadonnées associées à ces données binaires le sont.

Le moteur chargera les données binaires lorsque l'utilisateur cherchera à les récupérer, soit en direct via la servlet /data, soit via un script.

La page HTML n'est pas complète bien que le navigateur ait terminé le

rafraîchissement de la page

Ce problème peut être lié à l'utilisation de caractères dits "surrogate". Ce genre de caractères est utilisé par exemple lorsque l'on insère des emojis dans un texte. Les caractères surrogate sont en réalité constitués de plusieurs caractères.

Le parser SAX de java peut rencontre un problème lorsqu'il traite du xml qui contient de tels caractères. Le parser découpe le xml en morceaux de 1024 bytes. Il se peut qu'une paire de caractère surrogates soit alors séparée entre deux morceaux, ce qui provoque une erreur silentieuse. Une trace de ce style devrait cependant s'afficher dans le log:

org.xml.sax.SAXException: java.io.IOException: Invalid UTF-16 surrogate detected: d83e ?

Il ne s'agit donc pas d'un bug de l'application ou du moteur, mais un bug du parseur utilisé par java. Une solution pourrait être d'utiliser un autre parseur. Le bug disparaît si les caractères surrogates ne se cituent pas exactement à un multuple de 1024. Il suffit donc d'ajouter du contenu à l'arbre XML pour forcer les caractères surrogates à se retrouver à une autre position.