Comportement du bouton Précédent

Découvrez comment le comportement du bouton Précédent du navigateur Web peut affecter la navigation dans le portail.

Grâce à HCL Digital Experience Portal, les utilisateurs peuvent utiliser le bouton Précédent du navigateur pour parcourir l'historique récent des vues des pages qu'ils ont visitées.

Lorsqu'un utilisateur revient sur ses pas à l'aide du bouton Précédent du navigateur, le portail restaure les vues des pages visitées récemment. Ce comportement du portail peut avoir une incidence sur les aspects suivants des pages :

L'ordre dans lequel l'utilisateur a navigué dans le portail et sélectionné les pages.
L'état développé ou réduit de l'arborescence que révèle la navigation.
La position des onglets permettant aux utilisateurs de passer d'une page à l'autre.
Les informations relatives à la sélection par défaut d'un utilisateur pour un libellé. Il peut par exemple s'agir des informations portant sur la page sélectionnée par défaut pour un libellé pour cet utilisateur. Si l'utilisateur sélectionne une autre page de ce libellé, le portail l'affichera alors comme page par défaut.
Les informations de la fenêtre de portlet permettant de faire la distinction entre différentes instances d'un même portlet sur des pages différentes.
Modifications de l'affichage ou de l'état de fenêtre d'un portlet (par exemple, réduite, agrandie ou par défaut). Par exemple, si un utilisateur visualise un portlet dans son état d'affichage par défaut, puis agrandit ce dernier, le fait de cliquer sur le bouton Précédent replace le portlet dans son état précédent, ce qui signifie que le portlet est affiché dans sa taille par défaut.
Les options de sélection de mode du portlet, comme Afficher, Personnaliser, Editer les paramètres partagés ou Configurer.
Les informations précisant si un portlet est affiché à l'état solo et de quel portlet il s'agit.
Les informations précisant si le lien permettant de basculer entre Afficher les outils de présentation et Masquer les outils de présentation est affiché. Par exemple, ces outils incluent des options permettant de déplacer des portlets sur une page.
Si le portlet est compatible avec l'API de portlet standard, l'état de la vue du portlet est conservé, puisqu'il est déterminé par les paramètres de rendu du portlet. Pour plus d'informations sur les modifications d'état pour des portlets conformes à l'API standard, reportez-vous à la rubrique Utilisation du bouton Précédent avec des portlets d'API standard.

Terminology : Les conventions terminologiques suivantes sont utilisées dans cette section :

Les termes état de vue et état de navigation sont considérés comme des synonymes. Render parameters dans le sens de l'API de portlet standard fait également référence à la même chose.
Toute information relative au bouton Précédent du navigateur s'applique également au bouton Suivant.
Le bouton Précédent du navigateur est dépourvu d'une fonction d'annulation. Il interagit uniquement avec l'état de vue ou l'état de navigation et pas avec l'état de l'application.

Environnement de l'utilisateur

Les utilisateurs peuvent cliquer sur le bouton Précédent autant de fois que l'historique du navigateur le permet. Dans ce cas, la mise en page, qui provient de la mémoire cache d'historique du navigateur, est transmise au serveur sans requête supplémentaire. Les utilisateurs voient exactement la même mise en page que celle qu'ils ont pu voir lors de leur dernier passage sur cette page.

Lorsque les utilisateurs utilisent le bouton Précédent pour revenir à une page, ils peuvent utiliser n'importe quel lien y figurant afin de poursuivre leur navigation comme suit :

Si le lien n'est qu'un lien de rendu et ne se traduit pas par une action du portlet, aucun cas spécial ne s'applique.
Si le lien est un lien d'action comprenant une action de portlet, le comportement change, selon que l'utilisateur a déjà cliqué ou non sur ce même lien actif lors d'une précédente visite sur cette page effectuée au cours de la même session :
- Si l'utilisateur n'a jusqu'à présent jamais cliqué sur le lien, le portail accomplit l'action.
- Si l'utilisateur a déjà cliqué sur le lien actif, le portail affiche la mise en page de l'état découlant de la dernière utilisation du lien actif. En d'autres termes, le portail n'accomplit pas deux fois la même action.

Du point de vue de l'utilisateur, ces paramètres ont les conséquences suivantes :

Chaque combinaison d'états fait partie de l'adresse de la page (c'est-à-dire son URL) et peut se voir attribuer un signet. Les utilisateurs peuvent définir des signets distincts pour différents états d'une même page.
Les utilisateurs peuvent utiliser le bouton Précédent pour parcourir les modifications apportées aux états de vues. Par exemple, un utilisateur agrandissant un portlet peut utiliser le bouton Précédent du navigateur pour revenir à l'état de fenêtre précédent du portlet.
L'incidence du bouton Précédent sur les interactions avec les portlets est intimement liée à l'implémentation du portlet. Si le portlet implémente ses liens en tant que liens de rendu en modifiant les paramètres de rendu lien par lien, le bouton Précédent peut servir à parcourir l'historique des interactions avec ce portlet. Cela n'est toutefois possible qu'avec les portlets compatibles avec l'API de portlet standard.

Exemples de scénarios

Exemple de scénario 1 : Agrandissement ou réduction des portlets

L'utilisateur affiche une page A comportant deux portlets A1 et A2, tous deux dans leur état de fenêtre par défaut normal.
L'utilisateur agrandit le portlet A1.
L'utilisateur clique sur le bouton Précédent. Le portlet A1 s'affiche à nouveau dans son état normal.

Exemple de scénario 2 : Passage d'une page à l'autre

L'utilisateur affiche une page A comportant deux portlets A1 et A2, tous deux dans leur état de fenêtre par défaut normal.
L'utilisateur agrandit le portlet A1.
L'utilisateur sélectionne la page B. Le portail affiche la page B.
L'utilisateur clique sur le bouton Précédent. Le portail retourne à la page A. Le portlet A1 est affiché dans l'état agrandi.
L'utilisateur clique à nouveau sur le bouton Précédent. Le portlet A1 s'affiche à nouveau dans son état normal.

Exemple de scénario 3 : Différentes actions de l'utilisateur aboutissent au même résultat.

Scénario de départ et actions de l'utilisateur :

L'utilisateur affiche une page A comportant un certain nombre de portlets.
L'utilisateur interagit avec les portlets.
L'utilisateur place le portlet A1 en mode édition.
D'un clic, l'utilisateur place A2 en état réduit.
L'utilisateur fait en sorte que le portlet A3 de visualisation de documents (portlet d'API standard), affiche la page 2 du document qu'il révèle.
L'utilisateur bascule alors sur la page B et le portlet B1. Le portlet B1 est affiché en état normal, en mode visualisation et dans état d'application par défaut.
L'utilisateur réduit le portlet B1.

Malgré les actions effectuées ultérieurement par l'utilisateur, les sous-scénarios suivants aboutissent tous au même résultat :

Scénario 3a : Utilisation du bouton Précédent

L'utilisateur clique sur le bouton Précédent. Le portail affiche le portail A1 dans l'état normal.
L'utilisateur clique à nouveau sur le bouton Précédent. Le portail bascule sur la page A. Il affiche le portlet A1 en mode édition et le portail A2 dans l'état réduit. Le portlet A3 affiche la page 2 du document.

Scénario 3b : Réalisation d'une nouvelle sélection

L'utilisateur clique sur la page A in the navigation afin de "revenir" à la page A. D'un point de vue conceptuel, cette modification n'est pas considérée comme un back à la page A, mais comme une forward vers la page A. Le portail affiche donc la page A. Il montre le portlet A1 en mode édition et le portail A2 dans l'état réduit. Le portlet A3 affiche la page 2 du document.

Ajout de signets

A l'exception de l'état d'application du portlet, toutes les informations d'état sont marquées par un signet, par exemple les paramètres d'affichage et les états et modes des fenêtres. Le fait d'appeler un signet réinitialise l'état de l'application dans son état par défaut tel qu'il a été défini par ce signet.

Remarque : L'utilisateur peut définir plusieurs signets indépendants pour plusieurs fenêtres d'une même page. Dès lors, le résultat de l'exemple précédent de scénario ne dépend pas d'autres signets que l'utilisateur aurait définis sur différents états de fenêtre de cette même page.

Exemple de scénario : Ajout de signets

L'utilisateur sélectionne une page A comportant des portlets A1 et A2.
L'utilisateur agrandit le portlet A1 et réduit le portlet A2.
L'utilisateur ajoute un signet à la page. L'utilisateur renomme le signet A1min_A2max.
L'utilisateur se déconnecte, puis se reconnecte.
L'utilisateur sélectionne le signet A1min_A2max. Le portail affiche la page A avec le portlet A1 agrandi et le portlet A2 réduit.

L'utilisateur peut définir un autre signet A1Edit_A2Default distinct sur la même page A avec le portlet A1 en mode édition et le portlet A2 dans son état par défaut. Ces deux signets fonctionneront de manière totalement indépendante.

Remarques à destination des administrateurs concernant le comportement du bouton Précédent

Le comportement du bouton Précédent du portail est obtenu de manière interne par codification de l'association de tous les états figurant dans l'adresse de la vue, c'est-à-dire dans son URL. Ainsi, chaque combinaison d'états de navigation se traduit par une URL différente. Cela offre en outre les avantages suivants :

Les utilisateurs peuvent définir des signets distincts pour différents états d'une même page.
Certaines pages peuvent être placées dans la mémoire cache en mettant en place une configuration requise spécifique.

N'en tirez pas pour autant des conclusions à propos de la syntaxe ou de la structure des URL de portails. Par exemple, vous ne pouvez pas créer d'URL valides par simple concaténation. Cela ne sera automatiquement le cas que si l'API publique est utilisée pour créer des URL.

Utilisation du bouton Précédent avec les portlets d'API standard

Si un portlet est compatible avec l'API de portlet standard, les utilisateurs peuvent utiliser le bouton Précédent pour parcourir à rebours les états de vue de ce portlet tels qu'ils ont été déterminés par les paramètres de rendu de ce dernier. Lorsque l'utilisateur clique sur le bouton Précédent après avoir exécuté ce type de portlet, toutes les informations définies par les paramètres de rendu sont inversées. Il n'existe pas de règle générale relative au type d'informations stockées dans la mémoire cache en tant que paramètres de rendu d'un portlet. L'incidence du bouton Précédent sur les interactions avec les portlets dépend de l'implémentation de ce dernier. Celle-ci est déterminée par la personne qui a développé ce portlet.

Si le portlet implémente ses liens en tant que liens de rendu en modifiant les paramètres de rendu lien par lien, les utilisateurs peuvent utiliser le bouton Précédent pour parcourir l'historique des interactions avec ce portlet. Cela n'est toutefois possible qu'avec les portlets compatibles avec l'API de portlet standard.

En règle générale, toutes les informations ayant une incidence sur la view du portlet plutôt que sur son état d'application doivent être implémentées en tant que paramètres de rendu. Pour plus d'informations sur le développement de portlets conformes à l'API standard pour HCL Portlet, reportez-vous à l'article Best practices: Developing portlets using JSR 168 and HCL Portal.

Configuration de la limite d'expiration d'historique pour des pages de portail

Vous pouvez configurer le portail de sorte qu'il élimine les paramètres de rendu pour les pages que l'utilisateur n'a pas visitées lors de la même session. L'objet de ce paramétrage est de restreindre la longueur de l'URL en vue d'améliorer les performances de votre portail. Le portail élimine l'état de navigation de l'application des portlets compatibles avec l'API standard sur les pages trop éloignées dans l'historique.

Vous pouvez définir le nombre de visites effectuées sur chaque page au-delà duquel l'historique peut éliminer les paramètres de rendu du portlet. Votre paramètre détermine dans quelle mesure minimum les utilisateurs peuvent naviguer à rebours dans l'historique récent des pages de portail visitées. Le nombre que vous choisissez définit le nombre minimum de pages différentes sélectionnées par l'utilisateur au-delà duquel le portail peut éliminer les paramètres d'affichage d'une page. (La décision d'éliminer les paramètres d'affichage dépend des règles d'expiration de la mémoire cache interne qui stocke les paramètres d'affichage de ces pages.) Si l'utilisateur retourne sur une page après avoir visité le nombre défini d'autres pages, and si les paramètres de rendu de cette page ont expiré, le portail affiche cette page dans son état par défaut.

Pour configurer cette limite d'expiration, il convient de définir la valeur de la propriété keymanager.lru.size= (integer). Vous spécifiez cette propriété dans StateManagerService.

Vous pouvez définir les circonstances régissant l'enregistrement ou la suppression d'une page :

1: Chaque fois que l'utilisateur sélectionne une nouvelle page, les paramètres de rendu des portlets de la dernière page sélectionnée peuvent être éliminés.
Entier positif: Définissez le nombre nécessaire de pages. Les paramètres de rendu d'une page donnée peuvent être éliminés une fois que l'utilisateur atteint ce nombre de pages visitées.
0: Les paramètres d'affichage sont toujours stockés dans la mémoire de session du portail et ne sont jamais éliminés.

Remarque : Ne spécifiez pas de valeur inférieure à zéro (0). Celles-ci ne sont en effet pas considérées comme valides.

Exemple de scénario : Configuration d'une limite pour l'historique des pages affichées

Le paramètre de configuration est défini sur une valeur d'historique de 2.
Les pages de portail A, B et C contiennent des instances distinctes des portlets A1, B1 et C1 de visualisation de document compatibles avec l'API de portlet standard. Chacun des portlets affiche la page 1 du même document sur chaque page A, B et C. Il s'agit là de la configuration par défaut du portlet.
L'utilisateur sélectionne la page de portail A et atteint la page 2 du document dans le portlet A1.
L'utilisateur sélectionne la page de portail B et atteint la page 3 du document dans le portlet B1.
L'utilisateur sélectionne la page de portail C et atteint la page 4 du document dans le portlet C1.
L'utilisateur sélectionne la page de portail B. Le portlet B1 affiche la page 3 du document tel qu'il le faisait précédemment.
L'utilisateur sélectionne la page de portail C. Le portlet C1 affiche la page 4 du document tel qu'il le faisait précédemment.
L'utilisateur sélectionne la page de portail A. Le portlet A1 affiche la page 1 du document car il s'agit de l'état par défaut de ce portlet. L'état précédent a été éliminé car il se trouve déjà 3 pages en amont dans l'historique des vues et dépasse donc le paramètre de configuration, établi à 2 pages.
L'utilisateur sélectionne la page C. Le portlet C1 affiche encore la page 4 comme précédemment, puisqu'elle respecte la valeur d'historique configurée sur 2 pages enregistrées.

Le fait de configurer le paramètre d'historique peut entraîner des irrégularités dans le fonctionnement, selon la mémoire cache dont dispose le navigateur. Si l'utilisateur a recours au bouton Précédent pour consulter les pages précédemment visitées au lieu d'utiliser la navigation explicite, le fonctionnement peut s'avérer irrégulier si l'utilisateur dépasse la taille de l'historique configurée sur le serveur. Le cas échéant, le navigateur peut afficher les portlets dans leur état d'application précédent plutôt que dans leur état par défaut, car la majoration est transmise depuis la mémoire cache du navigateur client sans requête au serveur. Toutefois, si l'historique de vues a été dépassé, le serveur réinitialise le portlet dans son état par défaut. Le fait d'actualiser une page de ce type affiche le portlet concerné dans son état par défaut plutôt que dans celui qui était affiché avant l'opération d'actualisation. Si vous ne souhaitez pas accepter ce comportement, définissez la taille de l'historique de vues sur la valeur 0 . Cela signifie que l'état d'application du portlet n'expire jamais.

La limite de l'historique de vues n'a d'incidence que sur l'état de navigation de l'application

La limite configurée de l'historique de vues n'a d'incidence que sur l'état de navigation des applications de portlets. Elle n'a aucune influence sur les éléments suivants :

L'état de vue ou de navigation du portail.
L'état de session d'une application de portlet, c'est-à-dire toute action ou transaction réalisée avec ce portlet.

Exemple de scénario : La limite de l'historique de vues n'a d'incidence que sur l'état de navigation de l'application

Le paramètre de configuration est défini sur une valeur d'historique de 3.
L'utilisateur se rend sur un site marchand.
L'utilisateur parcourt plusieurs vues de pages et étudie divers produits.
Sur une page X, l'utilisateur sélectionne un article et le place dans son panier électronique virtuel.
L'utilisateur parcourt encore quatre vues de pages et étudie d'autres produits.
L'utilisateur clique à quatre reprises sur le bouton Précédent du navigateur afin de retourner à l'endroit où il avait placé l'article dans le panier électronique. Le portail affiche la page X dans son état par défaut et non dans l'état dans lequel elle était au moment où l'utilisateur a accédé à la page suivante. Ceci s'explique par le fait que la vue de page se trouve 4 niveaux plus haut dans l'historique et dépasse donc le paramètre de configuration, établi à 3 vues. Néanmoins, le produit que l'utilisateur souhaite acheter n'est pas supprimé du panier électronique car cette information fait partie de l'état de session de l'application.