Les nouveautés d'ASP.NET 4

En mode AutoID, les contrôles se comportent exactement de la même façon en ASP.NET V4 que dans les versions précédentes.

En conséquence, notre textbox aura toujours le même rendu côté client :

<input name="ctl00$ContentPlaceHolder1$maTextBox" type="text" id="ContentPlaceHolder1_maTextBox" />

Ce mode est le mode par défaut. Il se base sur la valeur donnée au parent pour déterminer la valeur du contrôle. Il est à noter que si le ClientIDMode d'aucun parent n'est défini, les contrôles se comporteront comme s'ils étaient en mode Legacy.

Le mode prédictible est surtout utile lorsque l'on veut définir une façon simple de retrouver des ensembles de contrôle côté client, et est donc particulièrement adapté à des GridView ou des Repeater. Une fois qu'un contrôle de l'arborescence est défini avec cette valeur de ClientIDMode, les descendants de ce contrôle auront comme ID la concaténation de tous les ID de plus haut niveau, jusqu'au contrôle en question.

Par exemple, pour un Repeater défini ainsi :

<asp:Content ID="MainContent" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
    <asp:Repeater ID="Clients" runat="server">
        <ItemTemplate>
            Nom :
            <asp:Label ID="LblNom" runat="server"><%# Eval("Nom") %></asp:Label>            
            Prénom :
            <asp:Label ID="LblPrenom" runat="server"><%# Eval("Prenom") %></asp:Label><br />
        </ItemTemplate>
    </asp:Repeater>
</asp:Content>

Le code html généré sera le suivant :

Nom :
<span id="ContentPlaceHolder1_Clients_LblNom_0">nom1</span>            
Prénom :
<span id="ContentPlaceHolder1_Clients_LblPrenom_0">prenom1</span><br />

Nom :
<span id="ContentPlaceHolder1_Clients_LblNom_1">nom2</span>            
Prénom :
<span id="ContentPlaceHolder1_Clients_LblPrenom_1">prenom2</span><br />
...

Comme on le voit, l'ID des contrôles peut être facilement prédit, quel que soit le nombre de contrôles générés. Pour bien voir la différence, voici ce que donne le même contrôle, avec la propriété ClientIDMode à AutoID :

Nom :
<span id="ctl00_ContentPlaceHolder1_Clients_ctl00_LblNom">nom1</span>
Prénom :
<span id="ctl00_ContentPlaceHolder1_Clients_ctl00_LblPrenom">prenom1</span><br />

Nom :
<span id="ctl00_ContentPlaceHolder1_Clients_ctl01_LblNom">nom2</span>
Prénom :
<span id="ctl00_ContentPlaceHolder1_Clients_ctl01_LblPrenom">prenom2</span><br />
...

Pour plus de souplesse, il est aussi possible de définir un suffixe pour les Id générés, par l'intermédiaire de la propriété RowClientIDSuffix, disponible pour les contrôles GridView et ListView. Cette propriété permet de définir une ou plusieurs clés qui seront recherchées dans les données du contrôle, de façon à le suffixer. Par exemple, si on remplace notre Repeater par la grille suivante :

<asp:GridView ID="Clients" ClientIDMode="Predictable" RowClientIDSuffix="Nom, Prenom" runat="server" AutoGenerateColumns="false">
    <Columns>
        <asp:TemplateField HeaderText="Nom">
            <ItemTemplate>
                <asp:Label ID="LblNom" runat="server" Text='<%# Eval("Nom") %>' />
            </ItemTemplate>
        </asp:TemplateField>
        <asp:TemplateField HeaderText="Prenom">
            <ItemTemplate>
                <asp:Label ID="LblPrenom" runat="server" Text='<%# Eval("Prenom") %>' />
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

Le HTML généré sera le suivant, l'Id de chaque label étant suffixé par le nom et le prénom de l'employé

<table cellspacing="0" rules="all" border="1" id="ContentPlaceHolder1_Clients" style="border-collapse:collapse;">
    <tr>
        <th scope="col">Nom</th><th scope="col">Prenom</th>
    </tr><tr>
        <td>
            <span id="ContentPlaceHolder1_Clients_LblNom_nom1_prenom1">nom1</span>

        </td><td>
            <span id="ContentPlaceHolder1_Clients_LblPrenom_nom1_prenom1">prenom1</span>
        </td>
    </tr><tr>
        <td>
            <span id="ContentPlaceHolder1_Clients_LblNom_nom2_prenom2">nom2</span>
        </td><td>
            <span id="ContentPlaceHolder1_Clients_LblPrenom_nom2_prenom2">prenom2</span>

        </td>
......

Cette option est certainement la plus naturelle de toutes, à savoir qu'elle laisse le développeur totalement libre de la gestion des collisions entre Id. Dans notre exemple de TextBox, le HTML généré, si on affecte la valeur Static à la propriété ClientIDMode sera désormais le suivant :

<input name="ctl00$ContentPlaceHolder1$maTextBox" type="text" id="maTextBox" />

Le contrôle ListView qui était apparu avec ASP.NET pour le plus grand bonheur des développeurs a été simplifié pour ne plus requérir la déclaration d'un template de mise en forme.

Dorénavant, une simple déclaration des éléments à afficher, via l'élément ItemTemplate est suffisant :

<asp:ListView ID="ListView1" runat="server"> 
  <ItemTemplate> 
    <% Eval("Nom")%> 
  </ItemTemplate> 
</asp:ListView>

Ici, une simple amélioration de la propriété RepeatLayout qui permet dorénavant d'ajouter les valeurs OrderedList et UnorderedList, deux valeurs destinées à obtenir un rendu utilisant les balises listes XHTML <OL> et <UL>. Cette petite modification permet entre autres, par rapport à la génération de tableaux (<table>), une meilleure personnalisation CSS et un meilleur respect des standards d'accessibilité.

Je ne sais pas pour vous, mais il y a bien longtemps que je n'utilise plus le contrôle Menu, car celui-ci, bien que pouvant se générer seul à partir d'un fichier Web.Sitemap, générait une série de tableaux imbriqués, rendant la personnalisation difficile et n'était absolument pas respectueux des standards d'accessibilité (WAI). J'utilise donc un composant personnalisé de ma composition, permettant de mixer le fonctionnement du Menu de base, à Jquery, mais également en respectant les standards Web en générant des listes, plutôt que des tableaux.

La nouvelle version du contrôle corrige cela et génère une liste non ordonnée d'éléments :

<div id="Menu1"> 
  <ul> 
    <li><a href="#">Accueil</a></li> 
    <li><a href="#">Page1</a></li> 
  </ul> 
</div>

Mieux encore, l'accessibilité a été fortement améliorée, car, lorsque le menu a le focus, il est possible de naviguer au sein de celui-ci à l'aide des touches du clavier (ARIA).

Enfin, il est possible de totalement paramétrer le rendu CSS du menu, en désactivant la génération CSS automatique en mode block, en mettant à faux, la propriété IncludeStyleBlock.

<style type="text/css">
    #MainContent_Menu1 { background-color:#F7F6F3; }
    #MainContent_Menu1 img.icon { border-style:none;vertical-align:middle; }
    #MainContent_Menu1 img.separator { border-style:none;display:block; }
    #MainContent_Menu1 ul { list-style:none;margin:0;padding:0;width:auto; }
    #MainContent_Menu1 ul.dynamic { background-color:#F7F6F3;z-index:1;margin-left:2px; }
    #MainContent_Menu1 a { color:#7C6F57;font-family:Verdana;font-size:0.8em;
                        text-decoration:none;
                        white-space:nowrap;
                        display:block; }
    #MainContent_Menu1 a.static { padding:2px 5px 2px 5px;text-decoration:none; }
    #MainContent_Menu1 a.popout { 
            background:url("/WebResource.axd?d=ZpQ_VdlsJ4NsCH6tI9Ff5pqkbJux-tl9iyjWiOQrwWU1&amp;t=633927035656763451") 
             no-repeat right center;padding-right:14px; }
    #MainContent_Menu1 a.dynamic { padding:2px 5px 2px 5px;text-decoration:none; }
    #MainContent_Menu1 a.static.selected { background-color:#5D7B9D;text-decoration:none; }
    #MainContent_Menu1 a.dynamic.selected { background-color:#5D7B9D;text-decoration:none; }
    #MainContent_Menu1 a.static.highlighted { color:White;background-color:#7C6F57; }
    #MainContent_Menu1 a.dynamic.highlighted { color:White;background-color:#7C6F57; }
</style>

Toujours dans l'amélioration et la personnalisation du rendu des contrôles existants, différents contrôles ont vu l'apparition de la propriété RenderOuterTable. Cette propriété, qui est maintenant disponible pour les composants :
- ChangePassword ;
- CreateUserWizard ;
- FormView ;
- Login ;
- PasswordRecovery ;
- Wizard.

Permet de désactiver la génération d'un tableau extérieur englobant le rendu HTML du contrôle. En effet, par défaut, le simple fait de positionner l'un de ces contrôles entrainait la génération d'un tableau dans lequel était placé le contrôle, afin de pouvoir positionner du style inline. La finalité est bien entendu d'alléger le code HTML généré, et surtout d'avoir un meilleur contrôle du HTML final, afin de pouvoir le personnaliser finement à l'aide de feuilles de style CSS.

Le déploiement passe dorénavant par un package Web, un fichier zip autodocumenté qui permet de contenir les sources à déployer, mais également les paramètres IIS à appliquer, les schémas de base de données et les scripts à déployer, les certificats, les paramètres registres, les composants à placer dans le GAC, etc.
L'intérêt du Web package provient aussi de sa facilité d'utilisation. Il suffit en effet de le copier sur le serveur Web où l'on souhaite déployer puis, via la console de gestion de IIS, on charge le fichier et c'est tout.

Petite merveille que nous attendions tous, la possibilité d'avoir des fichiers de configuration dynamiques permettant de passer rapidement d'une configuration de développement, à celle de test ou encore celle de production. Avec Visual Studio, cela se fait avec XML Document Transform (XDT), fonctionnalité qui permet de générer un fichier de configuration Web.config à partir d'autres fichiers de configuration.
Certains avaient peut-être l'habitude de passer par Nant ou par un module additionnel de Visual Studio, c'est maintenant chose incluse.

Au niveau fonctionnement, c'est extrêmement simple, vous placez vos différentes configurations au sein de fichiers de configuration complémentaires (ex. : web.Debug.config, web.Release.config, etc., sans limites), puis, au moment de la compilation, en fonction du profil de configuration choisi, Visual Studio ira piocher les éléments au sein de ces fichiers complémentaires pour les placer dans le Web.config qui sera exporté et déployé.

Par exemple, supposons un fichier de configuration web.debug.config qui contiendrait juste un bout de configuration : la chaine de connexion

<connectionStrings xdt:Transform="Replace"> 
  <add name="connexionBase" connectionString="blabla connexion à mon serveur" /> 
</connectionStrings>

Notez l'attribut xdt:Transform=« Replace ». Cela signifie qu'à la compilation, l'élément connectionStrings du fichier web.config sera automatiquement remplacé par celui-là.

Pour un exemple pas-à-pas sur l'utilisation de XDT, je vous encourage à lire l'article suivant.

Visual Studio propose désormais de s'interfacer directement avec les outils de gestion distante d'IIS, afin de déployer le site web sur un serveur distant de façon automatique.
En pratique, cette fonctionnalité ressemble à la fonctionnalité de publication existante depuis quelques versions, mais sous le capot, elle prépare en fait une vraie migration, incluant toutes les dépendances nécessaires.
Il est de plus possible de publier sur plusieurs serveurs de façon simultanée, avec toutefois la limite de 50 profils de déploiement dans un projet…soit 50 serveurs publiés simultanément…

Parmi les autres nouveautés, même si ce n’en est pas tout à fait une, se trouve l'ajout au Framework 4, du composant ASP.NET Chart Control, composant de graphes, apparu au sein du SP1 du Framework 3.5. Ce composant destiné à dessiner des graphiques permet de rendre vos applications plus parlantes, et de créer des tableaux de reporting professionnels. Si beaucoup d'entre vous étaient habitués à utiliser des composants tiers (ZedGraph, Aspose Chart, Infragistics, et bien d'autres), sachez que vous avez maintenant à disposition, un composant complet, simple à utiliser,facilement personnalisable et proposant un grand nombre de types de diagrammes disponibles.

Aucun paramétrage particulier n'est requis puisqu'il est possible de changer le type de diagramme avec une seule propriété.

Voici d'ailleurs la liste exhaustive des 35 types

Si vous voulez une documentation complète sur l'utilisation du contrôle Chart, téléchargez le document suivant.

Lorsque ASP.NET 2.0 apporta les MasterPages, les développeurs trouvèrent un moyen simple de partager des metatags (le Dublin Core) au sein de toutes les pages de leurs sites Web. Néanmoins, ils perdaient par la même l'occasion de rendre facilement ces metatags dynamiques pour certaines pages et dépendant du contenu de la page.
ASP.NET apporte une solution à ce problème en autorisant la modification en code-behind, de ces métatags.

Ainsi, avec une simple ligne de code, vous pourrez éditer leur contenu :

private string _variable = "developpez";
protected void Page_Load(object sender, EventArgs e)
{
    this.MetaDescription = String.Format("Description dynamique {0}", _variable);
    this.MetaKeywords = "developpez, tutoriel, microsoft";
}

Et vous obtiendrez deux belles balises :

<meta name="description" content="Description dynamique developpez" />
<meta name="keywords" content="developpez, tutoriel, microsoft" />

Si le fichier Web.Config est une chose merveilleuse pour centraliser la sécurité, la configuration et le comportement de vos sites Web, c'est aussi, au fil des fonctionnalités ajoutées à ASP.NET, devenu un vrai foutoir. Il n'est pas rare de rencontrer des Web.Config de plusieurs centaines de lignes et ces fichiers deviennent difficiles à maintenir.
Avec ASP.NET 4, le Web.Config a subi un régime forcé et ainsi, lorsque vous créez un projet ASP.NET vide, la seule chose qu'il contient est la version du Framework ciblée :

<?xml version="1.0"?>
<configuration>

    <system.web>
        <compilation debug="true" targetFramework="4.0" />
    </system.web>
    <system.webServer>
      <modules runAllManagedModulesForAllRequests="true"/>
    </system.webServer>

</configuration>

Ceci est notamment possible grâce au déplacement des paramètres par défaut au niveau du machine.config, permettant d'appliquer des paramètres à tous les sites Webs de la machine. Ce découpage, plus logique, vous permet de faire évoluer des fichiers Web.config qui ne contiennent que ce qui est propre à leur application, tout en enlevant le superflu.

La façon de retourner un set de données a beaucoup évolué ces dernières années, en imposant peu à peu l'utilisation d'ORM, puis via le langage de requêtage objet Linq. Ainsi, la façon de filtrer des données Linq ou Entity est devenue extrêmement simple grâce à ces requêtes objet, mais ne répond pas pourtant à tous les besoins courants des sites Web.
Prenons un exemple simple, une grille affichant la liste des utilisateurs et une textbox permettant de faire une recherche sur ces derniers. Pour le moment, rien de complexe puisqu'il suffit de créer une fonction qui génère une requête filtrée. Maintenant, imaginons que nous pouvions nous passer de ce code superflu tout en gardant cette possibilité de filtre. Ne serait-il pas merveilleux? Et bien c'est maintenant possible grâce au contrôle QueryExtender.

Ce contrôle permet de filtrer une source de données avant que celle-ci ne retourne ses données aux autres composants. Dans notre exemple précédant, nous allons par exemple pouvoir filtrer en live les données.

<asp:LinqDataSource ID="maSource" runat="server"> TableName="Utilisateurs"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="maSource" runat="server"> 
  <asp:SearchExpression DataFields="Nom" 
      SearchType="StartsWith"> 
    <asp:ControlParameter ControlID="txtSearch" /> 
  </asp:SearchExpression> 
</asp:QueryExtender>

Aussi simple que cela, les données seront filtrées en fonction du texte saisi dans la textBox.

Le QueryExtender va beaucoup plus loin, car il est aussi capable de retourner des éléments en fonction de certaines propriétés, par exemple un checkBox indiquant de ne retourner que les utilisateurs mâles. Il s'agit ici d'utiliser non plus une SearchExpression, mais une PropertyExpression qui, lorsque la comparaison sera vraiment, retournera l'élément traité.

<asp:LinqDataSource ID="maSource" runat="server"> TableName="Utilisateurs"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="maSource" runat="server"> 
 <asp:PropertyExpression> 
    <asp:ControlParameter ControlID="ckbOnlyMen" Name="IsAMan" /> 
  </asp:PropertyExpression> 
</asp:QueryExtender>

Enfin, pour finir, et pour aller encore plus loin, il est possible d'utiliser une CustomExpression qui utilisera une méthode écrite par le développeur.

<asp:LinqDataSource ID="maSource" runat="server"> TableName="Utilisateurs"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="maSource" runat="server"> 
     <asp:CustomExpression OnQuerying="maMethode" /> 
</asp:QueryExtender>

Qui appellera automatiquement ma méthode :

public void maMethode(object sender, CustomExpressionEventArgs e) 
{ 
  e.Query = from u in e.Query.Cast<Utilisateur>() 
      where u.Adresse.Ville = "Courbevoie"
      select u; 
}

Une propriété supplémentaire a fait son apparition au sein des contrôles GridView et ListView: la propriété EnablePersistedSelection.

Dans les versions précédentes du Framework, lorsque l'on sélectionnait un élément dans la première page d'un contrôle paginé, comme une GridView, et que l'on passait à la page suivante, l'élément de la page deux avec le même index que l'élément sélectionné dans la page un était automatiquement sélectionné.

Avec la version 4 du Framework, en affectant la valeur true à la propriété EnablePersistedSelection, on obtiendra le comportement suivant, plus naturel :

<asp:GridView ID="Clients"  EnablePersistedSelection="true" ...>
    <Columns>
        <asp:BoundField HeaderText="Nom"  DataField="Nom" SortExpression="Nom"/>
        <asp:BoundField HeaderText="Prenom" DataField="Prenom" SortExpression="Prenom"/>
        <asp:CommandField ShowSelectButton="True" />
    </Columns>
</asp:GridView>

À l'heure de l'écriture de cet article, il n'existe que deux moyens de stocker le Session State, soit dans un serveur SQL grâce à un provider dédié, soit sur un serveur distant dédié à la tâche de stockage. Ces deux cas de stockage sont notamment utilisés dans le cas de fermes serveurs.
Au niveau du fonctionnement, le Session State est sérialisé puis envoyé au provider qui le stocke. Cette sérialisation a un coût, notamment en quantité de données transmises.

ASP.NET 4 apporte alors la possibilité de compresser (et décompresser) ce flux de données à l'aide de classe System.IO.Compression.GZipStream. Pour cela, il suffit d'activer la compression dans le Web.Config à l'aide de l'attribut CompressionEnabled :

<sessionState
  mode="SqlServer"
  sqlConnectionString="blabla"
  allowCustomSqlDatabase="true"
  compressionEnabled="true"
/>

Il arrivera sûrement un jour où vous souhaiterez déplacer une page ou réorganiser votre site Web sans vouloir que les anciennes pages donnent une page d'erreur manquante (erreur 404). Que cela soit pour l'utilisateur ou au niveau du référencement sur les moteurs de recherche, il est important d'utiliser les codes d'erreur de convention et indiquer dans la réponse renvoyée au navigateur client, que la page a été déplacée et d'indiquer le nouvel emplacement. En Web, cela se fait via le code d'erreur HTTP 301.

Maintenant, plutôt que de générer à la main la réponse HTTP à retourner, il vous est possible d'utiliser la méthode RedirectPermanent qui se charge de faire tout le travail à votre place.

this.Response.RedirectPermanent("nouvellepage.aspx", true);

Pour finir, parlons maintenant des expressions encodées automatiquement dans le code in-line. Par exemple un simple :

<%=monObjet.Nom %>

Qui nécessite, pour éviter un rendu incorrect ou de l'injection volontaire/involontaire de code, d'encoder le texte avant de le retourner au client.

<%= HttpUtility.HtmlEncode(monObjet.Nom) %>

Avec ASP.NET, pour arriver à la même chose, il vous suffit d'utiliser la nouvelle syntaxe (notez le deux-points en lieu et place du symbole égal) :

<%: monObjet.Nom %>

Jusque-là, les deux derniers bouts de code fournissent exactement le même résultat. Il devient donc une bonne habitude d'utiliser exclusivement cette nouvelle syntaxe.
Malheureusement, un problème survient, si nous utilisons la nouvelle syntaxe et que le contenu est encodé, comment faire lorsque l'objet fourni est déjà encodé? Un double encodage produirait un résultat peu réussi. La solution numéro 1, consisterait à repasser à l'ancienne syntaxe (signe égal). Mais pour éviter de jongler entre les deux, et se poser la question à chaque fois, de savoir si oui ou non, il faut utiliser la nouvelle syntaxe, ASP.NET apporte l'interface IHtmlString qui permet de préciser que la chaine est déjà encodée. Elle ne sera ainsi par réencodée, malgré l'utilisation de la nouvelle syntaxe. Exemple :

<%: new HtmlString("<b>Hello world</b>") %>