Conseils relatifs à la mondialisation
La section traite de conseils généraux relatifs à la mondialisation spécifiques à HCL Commerce.
Traitement des apostrophes et des caractères spéciaux
Les fichiers de propriétés Java traduits pour certaines langues d'Europe occidentale, telles que le français et l'italien, peuvent contenir certains caractères spéciaux tels que les doubles apostrophes ('') et l'apostrophe unique ('), qui doivent être supprimés lorsqu'ils sont importés dans les pages JSP. Ne pas supprimer ces caractères spéciaux provoquera des erreurs JavaScript et les pages GUI requises ne seront pas affichées.
Suppression des caractères spéciaux dans les fichiers JSP d'outils
L'élément d'interface utilisateur "alert" JavaScript utilise les apostrophes simples et doubles comme éléments de syntaxe et, par conséquent, ces caractères doivent être supprimés avant la transmission d'une chaîne qui les contient à une instruction "alerte".
Si votre JSP contient l'élément de code suivant :
<javascript><javascript>
alert('<%= myResouceBundle.get("alertMessage") %>');
</javascript>
</javascript>
Le code s'arrête si la chaîne "alertMessage" du fichier de propriétés traduit contient des apostrophes simples ou doubles. Un moyen facile de résoudre ce problème est d'utiliser une méthode appelée toJavaScript dans la classe com.ibm.commerce.tools.util.UIUtil :
<%@ page import="com.ibm.commerce.tools.util.*" %>
<javascript>
alert('<%= UIUtil.toJavaScript( (String)
myResouceBundle.get("alertMessage")) %>');
</javascript>
Cette méthode util supprime des caractères spéciaux tels que la barre oblique inversée(\), les guillemets simples ('), les guillemets doubles (") et la fin de ligne (\n).
Dans nouvelle liste dynamique, tous ces caractères spéciaux (c'est-à-dire ', ''') sont gérés par le code interne de la structure d'outils, de sorte que vous n'avez pas besoin de les traiter en appelant UIUtil.toJavascript().
Gestion des apostrophes avec MessageFormat
Lorsque vous utilisez java.text.MessageFormat pour créer des messages pouvant être affichés pour les utilisateurs finaux, les développeurs doivent tenir compte du fait que MessageFormat enlève toutes les apostrophes simples du message.
Si le message a une variable, remplacez les guillemets simples par deux guillemets :
baseMessage = EspUtil.replace(baseMessage, "'", "''");
String formattedMessage;
try {
formattedMessage = MessageFormat.format(baseMessage, args);
} catch (IllegalArgumentException e) { ... }
Où EspUtil.replace() est une méthode qui remplace toutes les occurrences d'une chaîne par une autre dans une chaîne, comme suit :
public final static String replace(String source, String pattern,
String
replacement)
{
if (source == null || pattern == null || replacement == null)
{
return null;
}
int pos = source.indexOf(pattern);
int count = -1;
while (pos != -1 && count != 0)
{
source = source.substring(0, pos) + replacement +
source.substring(pos + pattern.length());
pos = source.indexOf(pattern, pos + replacement.length());
count--;
}
return source;
}
Utilisation de feuilles de style en cascade dépendantes du paramètre régional (CSS)
Chaque langue a besoin de ses propres attributs personnalisables tels que la taille de police, la famille de polices, les images, et ainsi de suite. Pour permettre la personnalisation, la structure d'outils fournit un centre.css distinct pour chaque paramètre régional (par exemple, centre_en_US.css, centre_fr_FR.css, centre_ja_JP.css, etc.). Tous les outils pour lesquels les développeurs doivent utiliser ces fichiers CSS dépendants du paramètre régional pour chaque JSP.
Pour charger le fichier CSS dépendant du paramètre régional :
- Incluez com.ibm.commerce.tools.util.UIUtil
- Ajoutez la balise suivante à votre JSP :
<LINK REL=stylesheet HREF="<%= UIUtil.getCSSFile(locale) %>" TYPE="text/css"> -
Remarque : getCSSFile(local) renvoie le nom du fichier CSS en fonction du paramètre régional et retombe sur center.css si center_locale.css n'existe pas.
Dialogues compatibles avec la langue nationale alert, confirm et prompt.
Les fonctions par défaut alert(), confirm() et prompt() d'un navigateur Web n'utilisent pas le codage UTF-8 pour afficher les messages. Par conséquent, les messages de caractères à deux octets sont corrompus s'ils sont affichés sur un navigateur anglais (ou autre à un octet).
La structure d'outils fournit un nouvel ensemble de dialogues pour rendre ces fonctions nationales compatibles avec la langue. Ces dialogues sont les suivants :
- alertDialog (qui remplace alert)
- promptDialog (qui remplace prompt)
- confirmDialog (qui remplace confirm)
La syntaxe d'utilisation de ces trois dialogues est la même que celle des fonctions JavaScript standard. Voici un exemple de façon d'utiliser chacun de ces trois dialogues :
alertDialog("message");
rval = promptDialog("prompt message"); // will return a string
rval = confirmDialog("confirm message"); // will return a boolean
Validation de champ d'entrée : Validation d'entrée UTF-8
Avec les langues DBCS comme le chinois et le japonais, il y a plusieurs milliers de caractères, bien trop pour les stocker en utilisant seulement 1 ou 2 octets. Par conséquent, la plupart des caractères DBCS traditionnels sont codés à l'aide de trois octets dans UTF-8.
Tous les champs de texte qui mappent aux colonnes de base de données doivent valider le nombre maximal de caractères autorisés à être entrés, en tenant compte du nombre d'octets nécessaires pour stocker chaque caractère dans une base de données UTF-8. Par exemple, si la longueur de la colonne de base de données est de 10, votre code doit rechercher 10 caractères anglais, mais ne permettre qu'environ trois caractères japonais. Pour vérifier la longueur d'entrée, en convertissant en UTF-8, les développeurs d'infrastructures d'outils doivent utiliser la fonction JavaScript suivante (Util.js) :
function isValidUTF8length(UTF8String, maxlength)
Envoyer des paramètres de commande de langue nationale à l'aide de formulaires masqués
Une attention particulière est de mise lors de l'encodage des caractères de langue nationale dans le cadre de l'envoi des paramètres de commande. En raison de l'incapacité d'une chaîne d'URL à coder correctement les caractères nationaux, les paramètres d'URL de langue nationale doivent être envoyés sous forme masquée (à l'aide de la méthode d'envoi "Post"). Lorsqu'un formulaire est envoyé par le navigateur, les données sont codées automatiquement en fonction du paramètre d'encodage actuel du navigateur.
La structure d'outils HCL Commerce fournit le mécanisme suivant pour s'assurer que les paramètres d'URL (NVP) sont envoyés dans un format masqué :
Lorsque vous définissez une URL (si elle peut contenir des caractères à deux octets), utilisez toujours la méthode top.setContent(). N'utilisez pas window.location.replace() ou location.href=myURL. Autre avantage de top.setContent() : il déclenche le ToolsUICenter pour afficher correctement l'indicateur de progression. Appelez la méthode comme suit :
top.setContent( String PanelName, String ViewCommand, Boolean
addToBreadCrumbTrail, String urlParameter);
Exemple :
var urlPara = new Object();
urlPara.XMLFile = "my.xml";
urlPara.Search = "japanese";
top.setContent("My Link", "MyViewCommand", true, urlPara)