Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

la propriété SortDirection du GridView vaut toujours Ascending

On m’a récemment posé une question concernant la propriété SortDirection du GridView. Lorsque l’on binde un gridview en utilisant la propriété DataSource et non en utilisant un DataSourceControl, alors la propriété SortDirection retourne toujours Ascending. Il en va de même pour l’eventArgs que l’on récupere lors de l’événement Sorting du Gridview.

Après un petit tour dans Reflector, j’ai trouvé le code suivant :

1 // code provenant de Reflector 2 private void HandleSort(string sortExpression, SortDirection sortDirection) 3 { 4 bool isBoundUsingDataSourceID = base.IsBoundUsingDataSourceID; 5 GridViewSortEventArgs e = 6 new GridViewSortEventArgs(sortExpression, sortDirection); 7 this.OnSorting(e); 8 if (!e.Cancel) 9 { 10 // ??? 11 if (isBoundUsingDataSourceID) 12 { 13 this.ClearDataKeys(); 14 if (this.GetData() == null) 15 { 16 throw new HttpException(...); 17 } 18 this.EditIndex = -1; 19 this.SortExpressionInternal = e.SortExpression; 20 this.SortDirectionInternal = e.SortDirection; 21 this._pageIndex = 0; 22 } 23 this.OnSorted(EventArgs.Empty); 24 base.RequiresDataBinding = true; 25 } 26 }

A la ligne 11, on voit que la propriété SortDirection est modifié seulement lorsque l’on utilise un DataSourceControl. Cela confirme donc mes constatations. Je ne comprends pas pourquoi l’équipe ASP.net à fait ce choix.

Afin de pouvoir changer l’odre du tri, il faut manuellement persister le SortDirection dans le ViewState. Pour cela, on peut utiliser le code suivant :

protected SortDirection CurrentDirection { get { if (this.ViewState["CurrentDirection"] != null) { return (SortDirection)this.ViewState["CurrentDirection"]; } return SortDirection.Ascending; } set { this.ViewState["CurrentDirection"] = value; } } protected void gvPouet_Sorting(object sender, GridViewSortEventArgs e) { this.CurrentDirection = CurrentDirection == SortDirection.Ascending ? SortDirection.Descending : SortDirection.Ascending; this.BindData(); }

Au niveau de la méthode BindData, il faudra alors récuperer les données en fonction de la propriété CurrentDirection.

Attention, ce bout de code ne fait que gérer le tri sur une seule colonne, si vous souhaitez gérer le tri sur plus d’une colonne, il faudra alors persister une collection contenant la colonne et la direction du tri.

Vous pouvez télécharger l’intégralité des sources ici : Utilisation de la méthode Sort et SortDirection avec un GridView et ajout des flèches haut/bas sur le nom des colonnes

Posted: dimanche 28 février 2010 20:14 par cyril
Classé sous : , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

smo a dit :

Ca a toujours été comme ça, et c'est probablement pour être dans le même esprit que ASP.NET 1.1. En mode manuel, c'est au développeur de gérer. cf http://connect.microsoft.com/VisualStudio/feedback/details/104950/gridview-sortdirection-property-always-returns-assecnding-sort-direction

Ceci étant dit, le mode manuel est plus ou moins obsolete (même si ce n'est pas "officiel"). Ne pas utiliser le couple DataBoundControl / DataSourceControl en ASP.NET 2+ est une hérésie :) Il faut toujours essayer de se ramener à cette combinaison si on ne veut pas trop se compliquer la vie.

# mars 1, 2010 10:17

cyril a dit :

>> "Ne pas utiliser le couple DataBoundControl / DataSourceControl en ASP.NET 2+ est une hérésie"

Je ne suis pas d'accord, sur tous les projets que j'ai vu, je n'ai JAMAIS vu l'utilisation des DataSourceControl. Ces trucs sont purement indebuggable, nécessite du code fortement orienté pour utiliser ces trucs, donc non ! Je ne parle meme pas des SqlDataSource qui mélange code métier, accès aux données, et présentation dans un même fichier.

De plus, même si le DataSource est "obsolete" (ce dont je ne suis pas d'accord :)), ce n'est pas une raison pour avoir mis le if aussi large ... Je ne comprend pas pourquoi l'équipe ASP.net à fait ce choix, si quelq'un à une explication, je suis preneur :-)

# mars 1, 2010 11:01

smo a dit :

L'équipe ASP.NET a fait ce choix parce que justement elle a voulu favoriser l'utilisation du couple DataSourceControl (+DataSourceView) /DataBoundControl.

Attention, quand on parle de DataSourceControl, on ne parle pas forcément de SqlDataSource ou d'ObjectDataSource, qui n'en sont que des exemples, mais du principe. On peut tout à faire écrire très simplement son propre DataSourceControl (+DataSourceView), et ensuite bénéficier de tous les DataBoundControl (grid, form, details, list, etc...) avec du binding, du sorting, du paging, etc... sans se casser la tête. C'est un pattern propre et relativement classique (qu'on retrouve plus ou moins en WPF/SL avec des nouveaux noms sexy tels que MVVM). Malheureusement, ce pattern ASP.NET est très peu expliqué en tant que tel, les exemples ne parlent que de Sql/Xml/Object DataSource, et même la littérature sur ASP.NET est globalement obsolete (le seul bouquin sur les contrôles ASP.NET de nikhil kothari "Developing Microsoft ASP.NET Server Controls and Components" n'a plus aucun sens en ASP.NET 2).

Ensuite, sur le fait que c'est rarement utilisé "sur les projets", on est bien d'accord, mais c'est plutôt par flemmardise, par méconnaissance, et parce que le développeur de base préfère double-clicker sur les boutons dans le designer de VS et placer son code là où VS le propose sans se poser trop de questions. Au final, le code est presque le même mais au lieu d'être proprement organisé, il y en a partout.

Au final, c'est aussi pour ça que "sur les projets", les gens s'arrachent les cheveux avec le viewstate, la gestion du cycle asp.net, et c'est pour ça qu'on retrouve plein (trop) de code métier dans le UI, que le code développé n'est jamais réutilisable (ce qui est le cas du code ci-dessus qu'il faudra copier-coller dans des pages ou des contrôles à chaque nouveau projet).

En utilisant au maximum les DataSourceControl (il suffit d'une méthode à surcharger, on peut utiliser les génériques, ...) et le binding automatique avec les DataBoundControl, on peut éliminer entièrement le code behind, n'avoir que du markup d'un coté, du métier de l'autre et du binding (de la tuyauterie) entre les deux.

# mars 1, 2010 12:25
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01

- SharePoint Online: Script PowerShell pour supprimer une colonne dans tous les sites d’une collection par Blog Technique de Romelard Fabrice le 11-27-2018, 18:01