Comprendre le rafraichissement partiel d'une page avec ASP.NET AJAX.

Propriétés accessibles depuis la balise :

Propriétés accessibles par code uniquement :

Méthode publique :

Balises enfants :

Le contrôle ScriptManager est le cœur des extensions ASP.NET AJAX. Il fournit l'accès à la bibliothèque des scripts, le support du rafraichissement partiel et fournit un support complet pour des services ASP.NET supplémentaires (tels que l'authentification et le profilage, mais également d'autres Services Web). Le contrôle ScriptManager fournit également le support de l'internationalisation et localisation pour les scripts clients.

Alors que les Extensions AJAX pour ASP.NET 2.0 comprennent l'intégralité du code du script, tant en mode debug que production, comme ressources incorporées dans les assemblies référencées, les développeurs sont libres de rediriger le ScriptManager vers des scripts personnalisés ou encore d'ajouter des scripts supplémentaires nécessaires.

Pour écraser le lien par défaut vers les scripts habituellement inclus (tels que ceux qui supportent l'espace de noms Sys.WebForms et le système de typage personnalisé), vous devez vous abonner à l'événement ResolveScriptReference de la classe ScriptManager. Quand cette méthode est invoquée, le gestionnaire d'événements à l'opportunité de changer le chemin vers les scripts en question; le ScriptManager enverra alors une version différente ou modifiée des scripts au client.

De plus, les références aux scripts (représentées par la classe ScriptReference) peuvent être ajoutées via le code ou la balise. Pour faire cela, modifiez soit par code la collection ScriptManager.Scripts, ou ajoutez un tag <asp:ScriptReference> en dessous du tag <Scripts> qui est un enfant direct du contrôle ScriptManager.

Même si les rafraichissements sont gérés à travers des déclencheurs définis par des UpdatePanels, la gestion des erreurs et des messages d'erreur personnalisés s'effectue via l'instance du contrôle ScriptManager de la page. Cela s'effectue en exposant un événement, AsyncPostBackError, à laquelle on peut abonner la page pour fournir une gestion d'erreurs personnalisée.

En consommant l'événement AsyncPostBackError, vous pouvez préciser la propriété AsyncPostBackErrorMessage, ce qui provoquera l'apparition d'une boîte d'alerte à la fin du callback.

La personnalisation côté client est également possible plutôt que d'utiliser la boite d'alerte par défaut. Vous pourriez, par exemple, afficher une <div> personnalisée plutôt que la boîte de dialogue par défaut. Dans ce cas, vous pouvez gérer l'erreur dans un script client :

<script type="text/javascript">      
    <!--      
        Sys.WebForms.PageRequestManager.getInstance().add_EndRequest(Request_End);
        function Request_End(sender, args){ 
            if (args.get_error() != undefined){
                var errorMessage = "";
                if (args.get_response().get_statusCode() == "200"){
                    errorMessage = args.get_error().message;
                }else{
                    // Le serveur n'était pas le problême
                    errorMessage = "Une erreur inconnue est survenue...";
                }
                // Faites ce que vous voulez avec le message d'erreur ici.
                // Maintenant, il faut signaler qu'on a géré l'erreur.
                args.set_errorHandled(true);
            }
        }
    // -->
    </script>

De façon très simple, le script ci-dessus définit une fonction de rappel (callback), via le noyau AJAX côté client, pour lorsque la requête asynchrone sera terminée. Il vérifie ensuite si un message d'erreur a été rapporté, et si c'est le cas, le traite pour finalement indiquer au noyau que l'erreur a été gérée dans un script personnalisé.

Le contrôle ScriptManager fournit un support étendu pour la localisation des chaînes des scripts et les composants de l'interface utilisateur; cependant, ce sujet dépasse le cadre de cet article. Pour en savoir plus, lisez l'article Comprendre l'internationalisation avec ASP.NET AJAX.

Propriétés accessibles depuis la balise :

Propriétés accessibles par code uniquement :

Méthode publique :

Balises enfants :

Le contrôle UpdatePanel est le contrôle qui délimite le contenu côté serveur qui prendra part dans la fonctionnalité de rafraichissement partiel des extensions AJAX. Il n'y a pas de restriction quant au nombre de contrôles UpdatePanel qui peut être placé sur une page, et ils peuvent être imbriqués. Chaque UpdatePanel est isolé de façon à ce que chacun travaille indépendamment (vous pouvez avoir deux UpdatePanels qui s'exécutent en même temps, actualisant deux parties différentes de la page, indépendamment du postback de la page).

Le contrôle UpdatePanel travaille principalement avec des déclencheurs - par défaut, n'importe quel contrôle contenu dans le ContentTemplate d'un UpdatePanel qui provoque un postback est enregistré comme déclencheur pour l'UpdatePanel concerné. Cela signifie que l'UpdatePanel est capable de fonctionner avec les contrôles à liaison de données (tel que le contrôle GridView), avec les contrôles utilisateurs, et ils peuvent être programmés dans le script.

Par défaut, quand un rafraichissement partiel est déclenché, tous les UpdatePanels de la page seront actualisés, qu'ils aient, ou non, définit un déclencheur pour une telle action. Par exemple, si un UpdatePanel contient un Bouton, et que le Bouton est cliqué, tous les UpdatePanels de la page seront actualisés par défaut. Cela est du au fait que, par défaut, la propriété UpdateMode d'un UpdatePanel est définie à Always. Alternativement, vous pouvez définir cette propriété à Conditional, ce qui signifie que l'UpdatePanel ne sera actualisé que si un déclencheur spécifique est activé.

Un UpdatePanel peut être ajouté à n'importe quel contrôle utilisateur ou contrôle personnalisé; cependant, la page sur laquelle ces contrôles sont inclus doit également comprendre un contrôle ScriptManager pour lequel la propriété EnablePartialRendering est définie à true. Une méthode pour vous affranchir de ce problème lorsque vous utilisez des contrôles Web personnalisés et de surcharger la méthode protected CreateChildControls() de la classe CompositeControl. En procédant de la sorte, vous pouvez injecter un UpdatePanel entre les enfants du contrôle et le reste si vous déterminez que la page supporte le rafraichissement partiel; autrement, vous pouvez simplement placer les contrôles enfants dans une instance de contrôle conteneur.

Le fonctionnement du contrôle UpdatePanel ressemble à celui d'une boîte noire, encapsulant les postbacks ASP.NET dans le contexte de l'objet JavaScript XMLHttpRequest. Cependant, il y a un impact significatif des performances à prendre en compte, tant en terme de comportement que de vitesse. Pour comprendre comment l'UpdatePanel fonctionne, de façon à pouvoir décider quand son utilisation est perspicace, vous devriez examiner les échanges AJAX. L'exemple suivant repose sur un site existant et Mozilla Firefox avec l'extension Firebug (Firebug permet d'observer les données de l'objet XMLHttpRequest).

Imaginez un formulaire qui, entre autres choses, contient un contrôle textbox pour saisir un code postal. Ce contrôle étant supposé remplir les champs ville et pays du formulaire. Ce formulaire collecte finalement des informations d'identification telles qu'un nom d'utilisateur, une adresse et des informations de contact. Il y a de nombreuses exigences de conception à prendre en compte, basées sur des pré-requis du projet concerné.

Lors du premier chargement de cette application, un contrôle est créé qui contient l'entièreté des informations d'identification de l'utilisateur, y compris le code postal, la ville et le pays. Le contrôle entier a été inclus dans un UpdatePanel et placé dans un Web Form. Lorsque le code postal est saisi par l'utilisateur, l'UpdatePanel détecte l'événement (l'événement TextChanged en l'occurrence, soit en spécifiant un déclencheur ou en définissant la propriété ChildrenAsTriggers à true. Ajax envoie tous les champs contenus dans l'UpdatePanel, comme montré dans la capture de FireBug (voir le diagramme sur la droite).

Comme illustré sur la capture d'écran, les valeurs de tous les contrôles contenus dans l'UpdatePanel sont transmises (dans ce cas, elles sont toutes vides), ainsi que le ViewState. Tout compris, c'est environ 9kb de données qui sont envoyés là où seulement 5 bytes étaient nécessaires pour effectuer cette requête. La réponse est encore plus étonnante : 57kb sont envoyés au client pour simplement actualiser la valeur d'un champ texte et d'une liste déroulante.

Il est également intéressant de voir comment ASP.NET AJAX actualise la présentation des contrôles. La portion de réponse à la requête d'actualisation de l'UpdatePanel est montrée dans la console d'affichage de FireBug, sur la gauche; il s'agit d'une chaîne formatée, délimitée qui est analysée par le script client et ensuite réassemblée sur la page. Plus précisément, ASP.NET AJAX définit la propriété innerHTML de l'élément HTML qui représente l'UpdatePanel côté client. Pendant que le navigateur régénère le DOM, il peut survenir un certain délai, dont la durée dépend de la quantité d'information qui doit être traitée.

La régénération du DOM déclenche un certain nombre de problèmes supplémentaires :

• Si l'élément HTML qui a le focus se trouve dans l'UpdatePanel, il perdra le focus. Ainsi, pour les utilisateurs qui ont appuyé sur la touche Tab pour quitter la zone de saisie du code postal, leur prochaine destination aurait du être la zone de saisie de la Ville. Cependant, une fois que l'UpdatePanel actualise son contenu, le formulaire qu'il contient perd le focus, et appuyer sur la touche Tab donnera le focus au premier élément non contenu dans l'UpdatePanel.
• Si un script client personnalisé est en train d'utiliser des éléments du DOM, les références éventuellement maintenues dans des fonctions risquent de devenir invalides lors de postback partiel.

Les UpdatePanels ne sont pas destinés à être des "solutions miracles". Au contraire, ils fournissent une solution rapide à certaines situations, telles que du prototypage, des mises à jour de petits contrôles, et fournir une interface familière aux développeurs ASP.NET qui sont peut-être familiers avec le model objet .NET mais moins à l'aise avec le DOM. Il existe de nombreuses alternatives qui peuvent donner de meilleures performances, selon le scénario de l'application :

• Utiliser les Méthodes de Page et JSON (JavaScript Object Notation) permet au développeur d'invoquer une méthode statique d'une page comme s'il s'agissait d'un appel à un service Web. Comme les méthodes sont statiques, aucun état n'est nécessaire; le script appelant fournit les paramètres et le résultat est retourné de façon asynchrone.
• Pensez à utiliser un service Web et JSON si vous avez un contrôle qui doit être utilisé à plusieurs endroits de votre application. De nouveau, cela nécessite peu de travail et fonctionne de façon asynchrone.

Ajouter des fonctionnalités à travers un Service Web ou des méthodes de page a également des inconvénients. D'abord et avant tout, les développeurs ASP.NET tendent habituellement à créer des petits composants regroupant certaines fonctionnalités au sein de contrôles utilisateurs (fichiers .ascx). Les méthodes de Page ne peuvent pas être intégrées à ces contrôles; elles doivent être intégrées directement dans le code-behind de la page .aspx. Les services Web, quant à eux, doivent être compris dans des fichiers .asmx. En fonction de l'application, cette architecture peut ne pas respecter le principe de responsabilité unique en ce sens que la fonctionnalité d'un composant unique est maintenant répartie à travers plusieurs composants physiques qui peuvent avoir peu de cohésion entre eux.

Pour finir, si une application nécessite d'utiliser des UpdatePanels, les règles suivantes devraient vous aider gérer les problèmes et la maintenance.

• Evitez autant que possible d'emboîter les UpdatePanels, pas seulement au sein du même composant, mais également à travers différents composants. Par exemple, un contrôle sur une page qui contient lui-même un contrôle contenant un UpdatePanel dans lequel se trouve également un contrôle contenant un UpdatePanel est de l'emboîtement inter composants. Procéder sans emboîtement permet de savoir facilement quel élément va être rafraichi et évite des actualisations involontaires d'UpdatePanels enfants.
• Maintenez la propriété ChilrdrenAsTriggers à false et définissez explicitement les événements déclencheurs. Utiliser la collection <Triggers> est la méthode la plus propre pour gérer les événements et peut éviter des comportements inattendus, facilitant la maintenance du composant et forçant les développeurs à effectuer des opt-in pour les événements.
• Utilisez le composant le plus petit possible pour implémenter une fonctionnalité. Comme souligné dans la discussion sur le service du code postal, encapsuler le strict minimum réduit la charge sur le serveur, le temps de traitement, la taille des informations nécessaires aux échanges client-serveur, ce qui améliore grandement les performances.

Propriétés accessibles depuis la balise :

Balise enfant :

Le contrôle UpdateProgress fournit un moyen de tenir l'utilisateur informé de la progression du traitement pendant le temps nécessaire à la requête. Cela permet de faire savoir à vos utilisateurs que vous êtes en train d'effectuer un traitement même si cela n'est pas apparent et cela est d'autant plus important que de plus en plus d'entre eux sont habitués à la barre de progression dans la barre de statut du navigateur ainsi qu'au bouton "actualiser".

Il est intéressant de noter que le contrôle UpdateProgress peut apparaître n'importe où dans la hiérarchie de la page. Cependant, au cas où le postback partiel serait provoqué par un UpdatePanel enfant (un UpdatePanel lui-même compris dans un autre UpdatePanel), le postback déclenché par l'UpdatePanel enfant provoquera l'affichage de l'UpdateProgress pour son UpdatePanel mais également pour celui du parent. Par contre, si le déclencheur est un enfant direct de l'UpdatePanel parent, seul l'UpdateProgress qui lui est associé sera affiché.