© Copyright International Business Machines Corporation 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM® Corp.
Les éléments suivants sont dépréciés et leur utilisation n'est donc plus recommandée :
- Données client et les outils associés (tels que la vue Données client)
- Composants Faces Client
<odc:dataGrid>
(grille de données)<odc:webService>
(service Web)<odc:clientData>
<odc:clientBinder>
Les composants
<odc:tree>
(arbre) et<odc:graphDraw>
(graphique) ont été modifiés pour utiliser les données serveur.
Si vous importez une application JSF antérieure à la version 7 sans faire migrer les fichiers JAR JSF et poursuivez son développement dans la version 7, les nouvelles balises propres à cette version ne seront pas incluses dans les fichiers JAR du projet et ne seront donc pas disponibles à l'exécution. Pour cette raison, veillez à faire migrer les fichiers JAR de vos projets antérieurs à la version 7.
La balise
<odc:treeNodeAttr>
du contrôle Tree utilise une valeur différente pour son attribut className, selon que le contrôle est lié à des données SDO ou WDO. Après la migration d'un projet à partir d'un serveur utilisant WDO (tel que WebSphere® Application Server 5.1) vers un serveur utilisant SDO (tel que WebSphere Application Server 6.1), le moyen le plus simple de remédier à cette situation est de supprimer puis de recréer tous les contrôles Tree.
Dans la v6.0, si un composant
<hx:commandExButton>
était assorti du type Submit et comportait à la fois un libellé (label) et une image d'arrière-plan (par exemple,value="submit" image="button.gif"
), seule l'image était rendue ; le libellé ne l'était pas. Ce problème est maintenant corrigé dans la v7.0. Cela signifie que les boutons ayant à la fois un libellé et une image d'arrière-plan seront rendus différemment selon qu'ils sont utilisés dans la v7.0 ou dans la v6.0.De même, si un composant
<hx:commandExButton>
était assorti du typeReset
et comportait une seule image d'arrière-plan (ou une image et un libellé), seule l'image était rendue et le bouton était traité comme un bouton de soumission (son type était ignoré). Ce problème est maintenant corrigé dans la v7.0. Cela signifie que les boutons assortis du typeReset
réinitialiseront la page au lieu de la soumettre.
Les attributs
style
etstyleClass
de la balise<jspPanel>
ne sont plus disponibles. Ils ne sont plus utilisés pour le rendu du composant panneau JSP.Si vous importez une application JSF créée dans une version précédente de ce produit, les balises
<jspPanel>
provoqueront des erreurs. Pour les corriger, supprimer les attributsstyle
etstyleClass
de toutes les balises<jspPanel>
présentes dans le projet en éditant le code source de vos JSP dans la vue Source.
Si vous importez dans votre espace de travail un projet ayant été créé dans une version précédente du produit, il est possible qu'un message d'avertissement s'affiche, signalant que le support Faces a été installé mais qu'aucun environnement d'exécution cible n'a été sélectionné pour le projet. Dans certains cas, ce message d'avertissement est affiché à tort, un environnement d'exécution étant correctement défini une fois le processus de migration terminé. Pour déterminer si un environnement d'exécution est défini, cliquez avec le bouton droit sur le projet concerné, sélectionnez Propriétés et, dans la fenêtre de propriétés, sélectionnez la catégorie Environnements d'exécution cible. Si l'un des serveurs défini est coché, vous n'avez rien d'autre à faire. Sinon, cochez la case de l'un des serveurs listés.
Remarque : La solution palliative décrite ci-après n'est pas nécessaire dans le cas où les modèles de données client sont créés à partir du même noeud Données de page ou de noeud Données de page portant le même nom.
Dans la v7.0, lorsque la page comporte plusieurs modèles de données client créés à partir de la même classe de bean, un second jeu de fichiers ecore et emap est créé à tort pour le second modèle lors de la génération (ou de la regénération). Conformément au guide de migration, lorsque vous faites migrer des projets de données client, les modèles de données client doivent être regénérés. Or, cela peut avoir une incidence néfaste sur les projets migrés dont les pages contiennent plusieurs modèles de données client. Voici un scénario simple :
- Créez deux noeuds Données de page basés sur le bean java.util.Date. Par exemple, maDate1 et maDate2.
- Pour chacun des noeuds Données de page, créez un modèle de données client portant le même nom, dans cet ordre : maDate1 puis maDate2.
Solution : Pour qu'une page puisse fonctionner avec les deux modèles, supprimez les fichiers maDate2.ecore et maDate2.emap du package com.ibm.dynwdo4jsmediators, ainsi que les entrées correspondantes dans le fichier OdysseyBrowserFramework.properties.
Les objets Données client produisent une grande quantité de code JavaScript™ sur les pages. Dans les précédentes éditions du produit, le JavaScript n'était pas encodé. Par conséquent, si vous utilisiez des données client dans plusieurs portlets en utilisant la même source de données de page, le JavaScript produit sur la page était le même pour tous les portlets.
Deux portlets différents semblaient être liés au même objet Données de page (car la deuxième section de JavaScript écrasait la première). Les deux portlets pouvaient alors interagir, puisque tout changement intervenant dans l'un d'eux était représenté dans l'autre.
Ce comportement, qui peut être mis à profit pour faire interagir des portlets, représente toutefois un problème si vous souhaitez placer plusieurs portlets sur une page et que chacun d'eux utilisent des objets Données client fonctionnant indépendamment les uns des autres. En effet, des erreurs JavaScript se produisent lorsque deux portlets sont placés sur la même page et utilisent des objets Données de page avec des sources de données de page différentes. Cela peut aussi empêcher le rendu de l'un des portlets.
Pour corriger ces problèmes et permettre aux portlets utilisant des données client de s'exécuter sur WSRP, les variables du JavaScript de chaque objet Données client doivent être encodées afin d'être spécifiques à chaque portlet. Cela permet aux sections JavaScript des différents objets Données client de fonctionner indépendamment les unes des autres.
Dans la V7.0, toutes les données client sont encodées.
Si toutefois vous souhaitez que plusieurs portlets placés sur une page partagent un même objet Données de page, vous devez mettre à jour le fichier web.xml afin d'y incorporer les paramètres de contexte suivants :
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>false</param-value>
<description></description>
</context-param>En attribuant la valeur false à l'attribut <param-value>, vous annulez l'encodage des objets Données client.
Utilisation du paramètre ENCODE_DATA et son effet sur les composants Graphique et Arbre de données utilisant des données de page
Les composants JSF Graphique et Arbre de données utilisent les données de page en plaçant un objet de données XML sur la page. Les données de page des composants Graphique et Arbre de données sont très étroitement liées aux objets Données client de ces mêmes composants. Par défaut, ces données sont encodées. La section <context-param> représentée ci-après sert normalement à annuler l'encodage des données client. Si vous l'incorporez dans votre fichier web.xml en mettant à false l'attribut <param-value>), l'encodage des données de page des composants Graphique et Arbre de données sera également annulé. Aucun autre composant utilisant des données de page ne sera affecté. Annuler l'encodage des données de page alors que deux portlets disposés sur une même page contiennent tous les deux un graphique ou un arbre de données peut entraîner des problèmes, notamment des erreurs JavaScript et/ou l'affichage incorrect de l'un des portlets.
Pour permettre aux deux portlets de s'exécuter indépendamment l'un de l'autre et pour activer le support de WSRP, vous devez supprimer la section <context-param> suivante du fichier web.xml ou mettre à true son attribut <param-value> :
<context-param>
<param-name>com.ibm.faces.ENCODE_DATA</param-name>
<param-value>true</param-value>
<description></description>
</context-param>
La déclaration suivante figure au début de la page :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Cette déclaration force les navigateurs Web à passer en mode strict (standard). Dans ce mode, les éléments
HTML
etbody
se plient aux règles de leur conteneur plutôt que de remplir toute la fenêtre comme c'est le cas avec l'ancien mode HTML par défaut (appelé mode "quirks" dans le jargon des concepteurs de pages Web).Lorsqu'un panneau à onglets est placé seul sur la page, sans être contraint par un conteneur, et que sa hauteur est exprimée par un pourcentage, cette hauteur est mal reproduite à l'affichage.
Pour éviter ce problème, placez le panneau à onglets dans un conteneur dont la hauteur est explicitement définie ou remplacez la déclaration doctype en début de page par la suivante :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Des problèmes d'affichage des onglets ont été constatés en mode strict (ou standard) lorsque la déclaration doctype est la suivante :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Vous pouvez y remédier en remplaçant la déclaration doctype par la suivante :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
La balise
<hx:convertDateTime>
ne génère pas de code JavaScript correct lorsque le calendrier est de type arabe. De ce fait, la validation côté client, l'invite de saisie, l'auxiliaire sélecteur de date et le mini-calendrier ne fonctionnent pas correctement. Lorsque le code JavaScript généré est initialisé, une erreur est affichée (ou le composant ne fonctionne pas correctement).Solution : N'activez pas la validation côté client ni l'invite. N'activez pas l'auxiliaire sélecteur de date si le calendrier arabe est utilisé avec le convertisseur.
Lorsque votre projet Web a pour cible un environnement d'exécution serveur WebSphere®, veillez à ce que la facette WebSphere Web (coexistence) soit sélectionnée pour ce projet.
Solution : Sélectionnez la facette sur la deuxième page de l'assistant Projet Web dynamique lorsque vous créez le projet. S'il s'agit d'un projet existant, vous ajouter cette facette sur la page Valeurs de projet de la fenêtre Propriétés du projet. Lorsque vous créez un projet Web ciblant un serveur WebSphere, si vous sélectionnez "Projet Faces" ou "Projet Web dynamique avec XDoclet" dans la liste Configurations de la première page de l'assistant, la facette WebSphere Web (coexistence) n'est pas automatiquement sélectionnée. Vous pouvez cependant la sélectionner sur la seconde page de l'assistant. En revanche, si vous sélectionnez "<personnalisé>" dans la liste Configurations, la facette WebSphere Web (coexistence) est bien sélectionnée lorsque l'environnement d'exécution cible est un serveur WebSphere.
Lorsque des balises
<hx:columnEx>
sont utilisées à l'intérieur d'une table de données (<hx:dataTableEx>
) et que le défilement vertical est activé (scrollSize est défini), si une ou plusieurs colonnes de la table ont leur largeur exprimée en pourcentage, à l'affichage de la page, les en-têtes et le contenu des colonnes peuvent ne pas être alignés entre eux si le doctype de la page est interprété par le navigateur comme W3C standard (par opposition au W3C transitional). C'est le cas, par exemple, si le doctype inclut une déclarationloose.dtd
.
Solution : Donnez à chaque colonne une largeur fixe (exprimée en pixels et non en pourcentage de la largeur de la table) ou faites en sorte que le doctype soit résolu comme doctypetransitional
(par exemple, supprimez la déclaration loose.dtd).
Dans un composant Panneau - Dialogue (
<hx:panelDialog>
), si le positionnement horizontal ou vertical choisi estrelatif
et que la balise utilisée comme référence de ce positionnement (le composant par rapport auquel la boîte de dialogue est positionnée) se trouve dans une page dont le défilement est tel que le composant de référence est visible et que la barre de défilement de la page n'est pas en butée haute, lorsque la boîte de dialogue est affichée, elle peut être positionnée incorrectement (généralement trop en haut ou trop à gauche).Solution : Si vous tenez au positionnement relatif de la boîte de dialogue, faites en sorte que que le composant de référence se trouve à proximité du haut de la page. Sinon, utilisez l'un des autres types de positionnement (non relatifs).
Si une table de données (
<h:dataTable>
ou<hx:dataTableEx>
) est placée dans un panneau avec support de mise à jour via AJAX et que la sélection de lignes est activée (une balise<hx:inputRowSelect>
est incluse dans la table), les cases à cocher de la colonne de sélection ne fonctionnent pas lorsque la table est à nouveau extraite via AJAX. Elles fonctionnent correctement au premier affichage de la table, mais plus ensuite.Solution : Il n'existe pas actuellement de solution palliative à ce problème. Le seul conseil que l'on puisse donner est de ne pas placer de table de données dans un panneau avec support AJAX.
La balise
<hx:ajaxExternalRequest>
peut ne pas fonctionner correctement dans Internet Explorer si l'attribut source est utilisé pour spécifier l'ID du panneau à récupérer dans la page cible et si cet ID diffère de celui du panneau auquel la balise<hx:ajaxExternalRequest>
est attachée dans la page source. Par exemple,<hx:panel id="panel1"><hx:ajaxExternalRequest source="panel999" /><hx:panel>
. Ce problème se manifeste uniquement dans Internet Explorer, et seulement si le panneau cible est une grille, une boite ou un agencement (un panneau rendu comme table HTML).Solution : Assurez-vous que les ID sont les mêmes ou intégrez le panneau cible dans une balise panelGroup.
L'attribut
inProgresss
des balises<hx:ajaxRefreshRequest>
,<hx:ajaxRefreshSubmit>
,<hx:ajaxExternalRequest>
et<hx:inputHelperTypeahead>
ne fonctionne pas. L'affectation d'une valeur à cet attribut est sans effet. Pour garantir la compatibilité de votre code avec les futures éditions, n'affectez pas de valeur à cet attribut.
Lorsqu'une balise
<hx:inputHelperTypeahead>
est associée à un champ d'entrée, si un espace et/ou des caractères spéciaux tels le symbole perluète et le signe pour cent sont entrés dans le champ, la liste des suggestions ne comprend aucune entrée incluant ces caractères. Par exemple, si l'utilisateur tape %, aucune suggestion n'est renvoyée, même si le "dictionnaire" utilisé contient des entrées commençant par le signe %.
A compter de la version 1.5.0.8 de Firefox, certains attributs HTML DOM sont affectés d'un changement de comportement qui peut conduire à un positionnement incorrect du composant
panelDialog
lorsque celui-ci est rendu dans le navigateur. Le problème se produit le plus souvent lorsque la boîte de dialogue est configurée avec un positionnement relatif, mais il peut aussi se manifester dans d'autres cas où le contenu du corps est d'une taille "inférieure" à la hauteur de la fenêtre du navigateur (c'est-à-dire lorsque la page tient en entier dans la fenêtre et n'est donc pas munie de barre de défilement vertical).Solution : Vous pouvez ajouter du contenu au corps (même un espace tel qu'une balise <div> avec une hauteur définie) afin que page soit toujours munie d'une barre de défilement vertical (tout dépend des dimensions exactes de la fenêtre du navigateur et du contenu).
<hx:pagerDeluxe>
ne rend pas le marquage HTML correct si la classe de style (styleClass) est autre que la classe par défautpagerDeluxe
. Les boutons de la fonction de pagination sont toujours rendus avec des noms de classe qui incorporent le nom de la classe par défaut.Solution :
- Ne remplacez pas le nom de classe par défaut ; conservez pagerDeluxe.
- Adaptez le fichier CSS utilisé afin qu'il tienne compte des noms de classe rendus sur les boutons si un nom de classe différent est utilisé.