je ne sais pas s’il s’agit d’un defect ou d’un problème de saisie du texte mais lorsque des valeurs de liste ou des textes statiques contiennent des caractères spéciaux (caractères accentués, ‘&’, etc.) le diff du module XML les contenant détecte des différences alors qu’il n’y en a a priori pas :
tsl_simplehelp
--- Master
+++ Target
@@ -1,1 +1,1 @@
-<p>(Champ réservé à la DJ)</p>
+<p>(Champ réservé à la DJ)</p>
Nous obtenons ce comportement en utilisant la fonction “Comparer” de l’objet module en passant en entrée un export XML (inline docs=true).
Dans l’exemple fournir il y a bien une différence: dans un cas on a des caractères accentués et dans l’autre les HTML entities correspondants à ces caractères accentués. Il n’y a donc pas d’anomalie ici, je me suis donc permis de requalifier le post en “Support”.
On va donc essayer de comprendre ce qui est à l’origine de cette différence. Est-ce que vous comparez des modules extraits sur des versions différentes du socle ? Est-ce que vos XMLs sont issus d’instances différentes sur lesquelles le paramétrage a été réalisé/importé de manière différente etc.
Bonjour David,
Quelle réactivité!
J’avais bien repéré la différence liée aux XML entities.
En effet,
la valeur dans la base de données est bien exprimée sans utiliser les XML entities (donc pas de différence “à la base”)
les codes XML fournis en entrée du module de comparaison sont issus de la fonction moduleexport inlinedocs=true (pour le nouveau code à livrer) et de la fonction interne d’export appelée par la fonction “Comparer” (je fais l’hypothèse qu’il s’agit aussi de moduleexport inlinedocs=true);
il s’agit d’une comparaison de conf entre notre environnement de DEV actuellement en P20 et notre environnement de RE7 actuellement en P19
Je comprends de ton post précédent que ce comportement ne sera plus observé si nous passons en revue tous ces textes pour les ré-enregistrer/ré-encoder :) … Merci!
En tout cas ce n’est pas l’export XML qui substitue les caractères accentués par les HTML entities. Donc je pense que le paramétrage et/ou la version du composant de saisie HTML a peut être changé entre P19 et P20 et/ou que des gens ont consultés puis enrégistré certaines traductions sur l’un ou l’autre des environnements ou dans le genre.
La P21 est en release candidate, cela signifie qu’on attend un feedback de la part des personnes qui s’en servent avant de la passer en release officielle.
Un point d’attention: Si vous avez, par exemple, des objets externes codés en Rhino et conçus pour la UI legacy qui utilisent des composants “bas niveau” de cette UI legacy (qu’ils ne devraient normalement pas utiliser) vous devez désormais les importer explicitement, cf. la release note 4.0.P21:
Removed legacy UI components (e.g. ObjectList ) from default packages imported in Rhino scripts (if you use some of them you should add an explicit package import statement importPackage(Packages.com.simplicite.webapp) or an individual class import statement (e.g. importClass(Packages.com.simplicite.webapp.ObjectList )
Merci pour ton alerte. Nous serons vigilants là-dessus.
Concernant l’encodage des caractères : J’ai revérifié ce qu’il en était entre nos environnements et effectivement, les valeurs traduites initialisées avant de passer en P20 en DEV ne sont pas encodées (ce qui est le cas en RE7 et OPE) et seules les nouvelles valeurs ou valeurs modifiées depuis que nous sommes en P20 en DEV présentent ce comportement de “fake diff”. Le problème sera donc résolu en réalignant l’ensemble de nos env en P21 puis en passant en revue l’ensemble des traductions correspondantes pour ré-encoder les valeurs.
