Rob Howard
Quand j'étais enfant, je passais quelques semaines chaque année avec ma famille élargie. En tant que jeune garçon américain, j'étais fasciné par les trains électriques néerlandais, quelque chose que je n'avais jamais vu dans ma ville natale de Dallas, au Texas. Mes cousins m'ont offert une balade sur leur bateau pour observer le passage d'un train. Assis sur l'eau près de la voie ferrée, vous pouvez entendre le train qui approche, comme un léger sifflement à travers la voie ferrée, jusqu'à ce qu'il joue un lent point culminant lorsque le train passe. Je n'ai pas pu m'empêcher de me le rappeler en pensant à ASP.NET 2.0. ASP.NET 2.0 est très proche et la plupart d'entre nous attendent avec impatience sa sortie assez tôt pour entendre même le « woo » que la version continue de devenir de plus en plus forte. Ensuite, la façon dont nous écrivons des logiciels changera encore une fois.
L'objectif ASP.NET 2.0 de Microsoft est de fournir aux développeurs des performances de 50 %. Cependant, les améliorations réelles des performances semblent dépasser les attentes. Les nouvelles fonctionnalités de personnalisation, d'adhésion et de gestion des rôles soulagent les développeurs, tandis que d'autres fonctionnalités, telles que la liaison de données, sont également simplifiées. Par exemple, la syntaxe familière et toujours prise en charge :
<%# DataBinder.Eval (Container.DataItem, "FirstName") %>
Dans ASP.NET 2.0, il peut être simplifié comme suit :
<%# Eval("FirstName") %>
Non seulement il existe une tonne de nouvelles fonctionnalités impressionnantes, mais il existe également une tonne de contrôles de serveur significatifs. Le modèle de programmation ASP.NET deviendra encore plus puissant dans ASP.NET 2.0 en raison de l'intégration de l'adhésion avec des contrôles serveur tels que le contrôle <ASP:login> et de nouveaux contrôles de source de données et de serveur de contrôle de données.
Le nombre de bibliothèques de classes System.Web a presque doublé dans ASP.NET 2.0 - une telle couverture qu'elle nécessite même une chronique dans un magazine. Pour vraiment comprendre l'étendue de ces changements, vous aurez besoin d'un nouveau livre ASP.NET 2.0. J'ai l'intention d'écrire quelques colonnes ici pour mettre en évidence certaines des nouvelles fonctionnalités les plus importantes d'ASP.NET 2.0. Ce mois-ci, je vais me concentrer sur la navigation et le flux des pages, en commençant par une fonctionnalité très recherchée : la possibilité de soumettre à d'autres pages.
Livraison interpages
La plus grande plainte que j'entends de la part des développeurs migrant vers ASP.NET est le modèle de publication de page. Les pages ASP.NET peuvent avoir un seul <form> et ne peuvent se publier que via HTTP, de sorte que tout le traitement s'exécute sur toute la logique. cette page.
De nombreux développeurs, en particulier ceux qui sont familiers avec ASP et aiment contrôler l'élément <form>, sauront que dans ASP, vous pouvez indiquer au <form> où et comment soumettre ses données de contenu (HTTP Post ou HTTP Get), et le même page La quantité de <form>. Mais par rapport à ASP, ASP.NET autorise uniquement une page à avoir un seul <form runat=server>, et elle ne peut être publiée que sur elle-même. Cela peut être très frustrant. Voici un exemple de ce qui est envoyé à d'autres pages dans ASP.NET 2.0 :
<%@ Page MasterPageFile="~/Site.master" Language="C#"
CodeFile="Source.aspx.cs"
Héritage="Source" %>
<ASP:Content ID="MainContent"
ContentPlaceHolderID="Main" Runat="serveur">
Entrez votre nom :
<ASP:TextBox ID="NameBox" Runat="serveur"></ASP:TextBox>
<ASP:Button ID="Button1" Runat="server" Text="Soumettre" />
</ASP:Contenu>
Les pages maîtres sont utilisées pour contrôler la mise en page, avec un bloc <ASP:content> et certains contrôles serveur pour accepter les entrées de l'utilisateur.
Si vous envisagez de transmettre du contenu à une autre page, vous pouvez utiliser un code serveur similaire au suivant :
Response.Redirect("Target.aspx?Name= " +
HttpUtility.UrlEncode(NameBox.Text));
Le problème avec cette technologie est que lorsque l'utilisateur clique sur le bouton pour soumettre, le serveur accepte la demande et envoie une réponse pour rediriger le navigateur vers Target.aspx. Un problème aussi simple a nécessité beaucoup de travail !
Le travail peut-il être simplifié ? Dans ASP.NET 2.0, la réponse est oui. Ensuite, démontrez le code amélioré :
<%@ Page MasterPageFile="~/Site.master" Language="C#"
CodeFile="Source.aspx.cs"
Héritage="Source" %>
<ASP:Content ID="MainContent"
ContentPlaceHolderID="Main" Runat="serveur">
Entrez votre nom :
<ASP:TextBox ID="NameBox" Runat="serveur"></ASP:TextBox>
<ASP:Button ID="Button1" Runat="server" Text="Soumettre"
PostBackUrl="~/Target.aspx" />
</ASP:Contenu>
Notez l'attribut PostBackUrl dans <ASP:Button>. Cet attribut indique au bouton de ne pas effectuer la publication par défaut mais de soumettre les données directement à Target.aspx.
Vous vous demandez peut-être comment cela fonctionne, surtout si vous êtes familier avec ASP.NET ViewState. objet. Mais cela dépasse le cadre de cet article, lorsque la fonctionnalité de diffusion multipage est utilisée, un nouveau champ masqué sera ajouté à la page :
<input type="hidden" name="__PREVIOUSPAGE" id="__PREVIOUSPAGE"
value="p1-dFHlCpgH2alr1vkr3G21UIR7jOuzn074led6lbGf1KQ47_F25GwG0" />
C'est un peu comme l'état d'affichage généré par l'arborescence de contrôle, mais c'est un fragment de l'état d'affichage qui valide la page pour une diffusion multipage. Vous savez, lorsqu'une page est publiée sur une autre page, la page de réception doit pouvoir accéder à l'instance de la page de publication. Dans ce cas, cela signifie que Target.ASP peut accéder aux détails de Source.aspx. En fait, une approche plus efficace consiste à accéder à l'API de Source.aspx à Target.aspx via un gestionnaire fortement typé. Afin d'accéder à la page de livraison (page précédente), ASP.NET2.0 fournit un attribut de page pour la livraison sur plusieurs pages : Page Précédente.
PreviousPage renvoie l'instance de la page de diffusion, et il existe également une propriété utilisée pour vérifier s'il s'agit d'une diffusion inter-pages : IsCrossPagePostBack. Cette propriété est similaire à la propriété IsPostBack existante mais renvoie true uniquement si une publication sur plusieurs pages se produit.
La propriété PreviousPage peut se comporter différemment. La valeur par défaut renvoie simplement une instance de la page précédente en tant que type Page. Cependant, en utilisant une nouvelle directive, vous pouvez demander à la propriété PreviousPage de renvoyer une instance fortement typée pour accéder aux membres publics de la page. Par exemple, ajoutez le code suivant à Target.aspx :
<%@ PreviousPageType VirtualPath="~/Source.aspx" %>
Vous pouvez désormais utiliser la propriété PreviousPage sur Target.aspx pour accéder aux données de Source.aspx. Cependant, pour accéder à un contrôle serveur, comme le NameBox sur Source.aspx, vous devez également écrire le code suivant :
TextBox nameBox = PreviousPage.FindControl("NameBox") as TextBox
En d'autres termes, vous devez utiliser FindControl pour accéder à l’arborescence de contrôle. Pourquoi ? Les contrôles du serveur sont par défaut des variables membres protégées. Afin d'avoir un accès vraiment simple aux éléments de la page précédente, vous devez exposer la propriété ou la méthode sur Source.aspx en tant que publique, puis le code suivant fonctionnera : TextBox nameBox. = Page précédente. NameBox ;
La diffusion sur plusieurs pages est une fonctionnalité intéressante d'ASP.NET. Certains articles traitent en profondeur des détails techniques de la diffusion sur plusieurs pages. Si vous êtes intéressé par le fonctionnement de la diffusion sur plusieurs pages, vous pouvez vérifier. Découvrez Cutting de Dino Esposito dans le numéro de septembre de la rubrique MSDN Magazine Edge (veuillez consulter ma traduction : ASP.NET Form (Traduction)). Vous constaterez également probablement que si vous maîtrisez ASP.NET, vous continuerez à utiliser le modèle de publication de page standard la plupart du temps. (Traducteur : l'implication est que si vous êtes un expert, vous mépriserez cette fonctionnalité)
Le contrôle assistant
peut facilement créer une fonction de navigation complexe pour l'application via une livraison multipage. Cependant, cette fonctionnalité ne facilite pas la création d’interfaces utilisateur de type assistant. Les interfaces utilisateur de type assistant, qu'elles soient linéaires ou non linéaires, sont souvent conçues pour accomplir des tâches. Il offre aux utilisateurs finaux un moyen convivial d’effectuer une série complexe d’étapes, dont chacune est divisée en morceaux.
Dans ASP.NET 1.x, les assistants étaient souvent implémentés à l'aide de quelques astuces : placer plusieurs contrôles serveur <ASP:panel> sur la même page et changer de visibilité en fonction de l'emplacement de l'utilisateur. Écrire un assistant dans ASP.NET n'est pas une tâche facile. De nombreux concepteurs abandonnent l'assistant et la gestion du processus par étapes est également déroutante.
Les nouvelles fonctionnalités de diffusion multipages d'ASP.NET peuvent être utilisées pour résoudre le problème de l'assistant, mais elles constituent également un défi lorsqu'une navigation non linéaire est requise. Par exemple, étape 1, étape 2, ignorez les étapes 3 à 5, étape 6, étape 3, étape 2, étape 6, le contrôle de l'assistant ASP.NET 2.0 résout la plupart de ces problèmes. De plus, tous les éléments d'entrée de l'assistant de livraison multipage sont accessibles en permanence via le modèle de publication de page.
La fonctionnalité du contrôle Assistant est très proche de la manière de masquer les panneaux dans ASP.NET 1.1. Cependant, le contrôle Assistant expose une série de <ASP:WizardStep>, qui peuvent contenir n'importe quel nombre de contrôles enfants. Cependant, chaque <ASP:WizardStep> doit avoir son propre ID unique, voir Figure 1. La page de contrôle de l'assistant gère toute la navigation, prend en charge la navigation linéaire et non linéaire et offre une prise en charge complète au moment de la conception. La figure 2 illustre le contrôle de l'assistant. Le côté gauche est une navigation non linéaire basée sur des liens et le côté inférieur droit est une navigation par bouton linéaire. Dans le menu des tâches qui s'ouvre, vous pouvez voir non seulement une tâche courante, mais également une liste d'étapes permettant de basculer entre les étapes au moment de la conception.
Figure 2 Assistant dans Visual Studio
Tous les éléments visibles du contrôle assistant sont configurables. Les liens non linéaires peuvent être remplacés par des boutons ou supprimer des entrées, et les éléments de navigation linéaires précédents, suivants et terminés peuvent également être transformés en boutons ou liens d'image. En fait, tous les aspects du contrôle peuvent être configurés via des modèles.
L'une des difficultés liées à l'écriture de contrôles d'assistant dans ASP.NET 1.1 était de gérer l'emplacement où l'utilisateur devait se trouver. Le contrôle Assistant simplifie cette tâche en exposant la propriété ActiveStep. La propriété ActiveStep peut interroger et déterminer quelle étape est actuellement active. Le flux naturel de l'assistant se déroulera comme déclaré par l'implémentation, et le flux peut être modifié à tout moment via la méthode MoveTo. Grâce à MoveTo, n'importe quelle étape peut être définie comme ActiveStep Afin de faciliter la navigation et le processus, plusieurs événements sont également fournis, voir Figure 3.
Le nouveau contrôle Assistant est très utile lors de la collecte d'informations utilisateur. Vous ne souhaitez pas écrire toutes les structures de base dans ASP.NET 1.1. ASP.NET a fait tout le travail à votre place. Le contrôle Assistant est si utile que l'équipe ast.net l'utilise comme classe de base pour le contrôle CreateUserWizard, qui est utilisé pour créer des utilisateurs dans le cadre de la fonction d'adhésion.
Les sections
Publication sur plusieurs pages et le contrôle <ASP:Wizard> offrent aux développeurs ASP.NET plusieurs nouvelles options pour contrôler le flux de navigation dans leurs applications. La livraison sur plusieurs pages est utile dans les situations où vous devez actuellement utiliser Response.Redirect ou Server.Transfer. Les contrôles Assistant sont parfaits pour créer des collections de données complexes qui nécessitent une collecte de données linéaires et non linéaires.
-------------------------------------------------- ------
Figure 1 Étapes de l'Assistant
<ASP:Wizard runat="server" >
<Étapes de l'Assistant>
<ASP:WizardStep ID="Step1">
Accueillir!
</ASP:WizardStep>
<ASP:WizardStep ID="Step2">
Quel est votre nom : [TextBox1]
[Bouton1]
</ASP:WizardStep>
<ASP:WizardStep ID="Step3">
Merci, [TextBox1.Text] !
</ASP:WizardStep>
</WizardSteps>
</ASP:Assistant>
-------------------------------------------- --- ----------
Figure 3 Événements de navigation
Description | de l'événement |
---|---|
ActiveStepChanged | Déclenché lorsque l'ActiveStep est défini sur un nouveau WizardStep |
CancelButtonClick | Déclenché lorsque le bouton identifié comme le bouton Annuler est cliqué |
FinishButtonClick | Déclenché lorsque le bouton identifié comme le bouton Terminer est cliqué |
NextButtonClick | Déclenché lorsque le bouton identifié comme le bouton Suivant le bouton est cliqué. |
PreviousButtonClick | Déclenché lorsque le bouton identifié comme le bouton Précédent est cliqué. |
SideBarButtonClick | Déclenché lorsque l'on clique sur l'un des liens ou boutons de la barre latérale. |