Contrôle de l'état d'affichage

Article
08/21/2007

Les pages Web Microsoft ASP.NET sont capables de conserver leur état lors d'accès répétés. Lorsqu'une propriété est définie pour un contrôle, ASP.NET enregistre la valeur de la propriété comme faisant partie de l'état du contrôle. Pour l'application, la page semble avoir une durée de vie qui s'étend sur plusieurs demandes clientes. Cet état au niveau de la page est appelé état d'affichage de la page.

Sur les pages Web ASP.NET ordinaires, l'état d'affichage est envoyé par le serveur sous forme de champ masqué dans un formulaire, dans le cadre de la réponse adressée au client, puis il est retourné au serveur par le client dans le cadre d'une publication. Cependant, pour réduire la demande en matière de bande passante lors de l'utilisation de contrôles mobiles, ASP.NET n'envoie pas l'état d'affichage d'une page au client. En revanche, l'état d'affichage est enregistré sur le serveur dans le cadre de la session d'un utilisateur. Lorsqu'un état d'affichage existe, ASP.NET envoie un champ masqué qui identifie l'état d'affichage de la page dans le cadre de chaque réponse adressée au client, et le champ masqué est retourné au serveur par le client lors de la publication suivante.

Gestion de l'historique de l'état d'affichage

Dans la mesure où l'état d'affichage d'une page donnée doit être conservé sur le serveur, si l'utilisateur clique sur le bouton Précédent du navigateur, il se peut que l'état actif sur le serveur soit désynchronisé par rapport à la page actuellement affichée sur le navigateur. Par exemple, l'utilisateur accède à la page 1, clique ensuite sur un bouton pour accéder à la page 2, puis clique sur Précédent pour retourner à la page 1. La page actuelle du navigateur est maintenant la page 1, mais l'état actif sur le serveur est celui de la page 2.

Pour résoudre ce problème, les pages Web mobiles ASP.NET conservent un historique des informations sur l'état d'affichage dans la session de l'utilisateur. Chaque identificateur envoyé au client correspond à une position dans cet historique. Dans l'exemple précédent, si l'utilisateur effectue à nouveau une publication à partir de la page 1, la page Web mobile utilise l'identificateur enregistré avec la page 1 pour synchroniser l'historique de l'état d'affichage.

Vous pouvez configurer la taille de cet historique pour le régler avec précision pour l'application. La taille par défaut est 6 ; il est possible de la modifier en ajoutant un attribut numérique à une balise du fichier Web.config, comme illustré dans l'exemple suivant :

<configuration>
  <system.web>
    <mobileControls sessionStateHistorySize="10" />
  </system.web>
</configuration>

Gestion des sessions expirées

Dans la mesure où l'état d'affichage est enregistré dans la session de l'utilisateur, il peut expirer si une page n'est pas publiée avant l'expiration de la session. Cette expiration est propre aux pages Web mobiles. Lorsque l'utilisateur publie une page pour laquelle il n'existe pas d'état d'affichage, la méthode OnViewStateExpire de la page est appelée. L'implémentation par défaut de cette méthode lève une exception qui indique que l'état d'affichage a expiré. Cependant, si votre application est en mesure de restaurer manuellement l'état d'affichage après l'expiration, vous pouvez substituer cette méthode au niveau de la page et choisir de ne pas appeler l'implémentation de base.

Activation et désactivation de l'état d'affichage

La gestion de l'état d'affichage via la session a pour avantage de réduire la taille de la réponse. L'inconvénient est qu'une utilisation inefficace de l'état de session peut aboutir à une baisse des performances. Si vous utilisez des contrôles qui contiennent de grandes quantités de données, vous pouvez recourir à certaines techniques telles que la pagination personnalisée ou la désactivation de l'état d'affichage, pour gagner en efficacité. Prenons l'exemple d'un site qui affiche des articles de presse. Au lieu d'enregistrer le contenu de l'article pour chaque session utilisateur, il est possible d'implémenter un mode d'accès aux données plus performant sur le site, afin de mettre en cache une seule copie de chaque article sur le serveur et réduire l'utilisation de l'état de session.

Pour désactiver l'état d'affichage d'un contrôle et de ses enfants, affectez la valeur false à la propriété EnableViewState du contrôle. Pour désactiver l'état d'affichage d'une page entière, affectez la valeur false à l'attribut EnableViewState de la directive @ Page.

Même lorsque l'état d'affichage est désactivé, certains contrôles mobiles enregistrent des informations d'état essentielles lors d'accès répétés au client. L'indication du formulaire actif sur une page est un exemple d'information. Lorsque vous désactivez l'état d'affichage, la page enregistre ces informations essentielles sous la forme d'une variable de formulaire masquée, qui est envoyée au client lors d'accès répétés.

Gestion des cookies et de l'état du client

Par défaut, les fonctionnalités de gestion de session de ASP.NET requièrent l'écriture d'un cookie de session par le serveur sur un client. Ce dernier envoie ensuite le cookie à chaque demande au cours de la session, ce qui permet au serveur de rechercher les informations d'état de session à l'aide des informations de cookie. Toutefois, de nombreux périphériques mobiles ne prennent pas en charge les cookies. Pour permettre le bon fonctionnement de la gestion de session (et de l'état d'affichage) sur ces périphériques, vous devez configurer l'application pour une gestion de session sans cookies. Une fois la fonctionnalité activée, ASP.NET insère automatiquement la clé de session dans les URL d'application.

Certains périphériques ne prennent pas en charge les cookies. Pour rendre persistant l'état du client à long terme, une application peut utiliser les informations propres au client, telles qu'un numéro de client saisi par l'utilisateur. Dans la mesure où le client ne prend pas en charge les cookies, votre application doit vous permettre d'accéder à une autre page pouvant être associée à un signet. Le code ci-dessous présente un exemple. Les utilisateurs qui accèdent à cette URL voient s'afficher un formulaire dans lequel ils peuvent entrer leur ID de client. L'application affiche alors une URL de remplacement, que les utilisateurs peuvent associer à un signet.

<%@ Page Inherits="System.Web.UI.MobileControls.MobilePage"
    Language="C#"
    EnableViewState="false" %>

<script runat="server" language="c#">
protected void Page_Load(Object sender, EventArgs e)
{
    String customerID = Request.QueryString["cid"];

    if (customerID != null)
    {
        // A customer ID was found. Simulate a lookup by 
        // converting the client ID back to a user.
        int underscore = customerID.IndexOf('_');
        if (underscore != -1)
        {
            // If visiting the first time, prompt the user to bookmark.
            if (Session["FirstTime"] != null)
            {
                Session["FirstTime"] = null;
                WelcomeLabel.Text = String.Format("Welcome, {0}", 
                customerID.Substring(0, underscore));
                ActiveForm = WelcomeForm;
            }
            else
            {
                ReturnLabel.Text = String.Format("Welcome back, {0}", 
                    customerID.Substring(0, underscore));
                ActiveForm = ReturnForm;
            }
        }
    }
}

protected void LoginForm_OnSubmit(Object sender, EventArgs e)
{
    // Generate a customer ID. Normally, you would create
    // a new customer profile.
    String customerID = CustomerName.Text + "_" + 
        System.Guid.NewGuid().ToString();
    String path = AbsoluteFilePath + "?cid=" + 
        Server.UrlEncode(customerID);
    Session["FirstTime"] = true;
    RedirectToMobilePage(path);
}
</script>

<mobile:Form runat="server">
  <mobile:Label runat="server" StyleReference="title">
    Welcome to the site. Please register to continue.
  </mobile:Label>
  <mobile:TextBox runat="server" id="CustomerName" />
  <mobile:Command runat="server" OnClick="LoginForm_OnSubmit" 
    Text="Register" />
</mobile:Form>

<mobile:Form id="WelcomeForm" runat="server">
  <mobile:Label runat="server" id="WelcomeLabel" />
    Please bookmark this page for future access.
</mobile:Form>

<mobile:Form id="ReturnForm" runat="server">
  <mobile:Label runat="server" id="ReturnLabel" />
</mobile:Form>

Optimisation de l'état d'affichage pour les applications mobiles

Les considérations ci-dessous sont importantes pour les pages Web mobiles :

L'enregistrement de l'état d'affichage dans l'état de session est fortement optimisé. S'il n'y a pas d'état d'affichage à enregistrer, aucune information n'est stockée dans la session et aucun identificateur n'est envoyé au client. Cependant, les développeurs d'applications qui ne souhaitent pas recourir à la gestion de session ou qui veulent des pages capables d'atteindre un débit élevé, peuvent réduire ou supprimer l'utilisation de l'état d'affichage. Dans de nombreux cas d'application (par exemple le rendu d'une page contenant du texte mis en forme), l'état d'affichage n'est pas nécessaire et doit plutôt être désactivé.
Outre l'état d'affichage de l'application, une page Web mobile doit stocker d'autres types d'informations d'état sur la page. Il peut s'agir d'une indication sur le formulaire actif ou d'informations sur la pagination du formulaire. Ces informations sont toujours envoyées au client au lieu d'être conservées sur le serveur et sont habituellement générées de manière optimisée. Par exemple, si le premier formulaire est actif ou si la première page d'un formulaire est affichée, ces informations ne sont pas enregistrées, car il s'agit d'états par défaut. Ce type d'informations d'état s'appelle un état d'affichage privé. Tous les contrôles peuvent substituer les méthodes LoadPrivateViewState et SavePrivateViewState pour lire et écrire l'état d'affichage privé.

Notes

Les bonnes méthodes en matière de sécurité impliquent que si vous ajoutez des informations sensibles dans l'état de session, vous devez utiliser une connexion utilisant l'authentification HTTPS et SSL/TLS.

Voir aussi

Partager via

Contrôle de l'état d'affichage

Gestion de l'historique de l'état d'affichage

Gestion des sessions expirées

Activation et désactivation de l'état d'affichage

Gestion des cookies et de l'état du client

Optimisation de l'état d'affichage pour les applications mobiles

Voir aussi

Référence

Concepts

Autres ressources

Ressources supplémentaires