Personnalisation des mises à jour avec l’interface utilisateur Telerik pour ASP.NET Core DataGrid

Que se passe-t-il si vous devez permettre à vos utilisateurs de modifier certaines données dans leur grille ? Ce contrôle fini est facile avec Telerik UI pour ASP.NET Core.

Dans un message précédentj’ai regardé toutes les options de l’interface utilisateur Progress Telerik pour Grille de données ASP.NET Core vous permet de créer la variété d’expériences de mise à jour dont les utilisateurs ont besoin, et le tout sans écrire de code.

Mais si vous lisez cet article, je soupçonne que vous réfléchissiez déjà aux cas particuliers dans lesquels vous souhaiteriez peut-être prendre plus de contrôle sur le processus de mise à jour que ne vous en donne cette solution sans code. Ainsi, dans cet article, je vais examiner certains des endroits où vous pouvez ajouter votre propre code pour prendre le contrôle de l’expérience utilisateur de mise à jour de la grille.

Obtenir une référence à la grille

La première étape dans la personnalisation de l’UX de mise à jour de kendo-grid consiste à obtenir une référence à la grille. Le moyen le plus simple de le faire est, dans la fonction ready de jQuery, de récupérer la grille via le nom que vous lui avez attribué. Une fois que vous avez cette référence, il vous suffit d’appeler la fonction data de la référence, en passant la chaîne "kendoGrid".

Ainsi, si votre page ou vue ASP.NET Core Razor a une grille configurée comme ceci :

<kendo-grid name="gridCustomer">
   <datasource …

alors vous pouvez utiliser le JavaScript suivant pour obtenir une référence à la grille et la stocker dans une variable qui sera utilisée par d’autres fonctions de votre page (j’ai intelligemment donné le nom de « grille » à la variable qui contiendra la référence à mon grille):

<script type="text/javascript">
    let grid;    
    $(
        () => {
            grid = $("#gridCustomer").data("kendoGrid");
        } 
    );

Définition de la possibilité de modification

La seule véritable limitation de l’approche sans code pour gérer les mises à jour avec la grille est que vous devez décider au moment de la compilation quelle expérience de mise à jour la grille offrira à vos utilisateurs. Cela peut signifier devoir créer plusieurs pages, essentiellement, de la même grille, car vous avez différents utilisateurs ou scénarios qui nécessitent des UX différentes. L’exemple le plus évident est celui où un groupe d’utilisateurs n’est pas autorisé à mettre à jour les données dans la grille et où l’autre groupe est autorisé.

Si cela ressemble à quelque chose auquel vous pourriez être confronté, l’une des premières choses que vous voudrez faire est de modifier dynamiquement l’état d’édition de la grille afin que vous puissiez basculer entre lecture seule et « modifiable », en fonction de l’identité de l’utilisateur connecté (ou quels que soient les autres critères qui vous semblent pertinents).

Toutefois, pour que le code de mon étude de cas reste simple, je vais démontrer le code nécessaire en l’encapsulant dans une fonction appelée enableEditing et en l’appelant à partir de l’événement click d’un bouton :

<button type="button" onclick="turnonEditing()">Enable Editing</button>

Dans la version la plus récente de la grille, vous pouvez basculer une grille entre ses états en lecture seule et modifiable en appelant simplement le enableEditing et disableEditing fonctions. Voici tout ce qui est requis dans mon turnonEditing fonction pour mettre la grille dans un état modifiable :

    let turnonEditing = () => grid.enableEditing();

Si vous disposez d’une ancienne version de la grille (et que vous ne souhaitez pas la mettre à niveau), vous pouvez modifier la propriété modifiable en créant un littéral d’objet JavaScript qui définit la propriété modifiable de la grille, puis en transmettant cet objet à la propriété de la grille. setOptions fonction. Cette version permet l’édition dans les anciennes versions de la grille :

    let turnonEditing = () => grid.setOptions({ editable: true });

Il n’y a qu’un seul véritable problème lors de la mise en œuvre de cela : la grille semble exactement la même chose avant l’activation de la modification qu’après : vous souhaiterez peut-être mettre à jour votre interface utilisateur pour informer votre utilisateur qu’il peut apporter des modifications.

Si vous le souhaitez, vous pouvez récupérer l’état de modification actuel de la grille via le getOptions fonction qui, entre autres valeurs, renvoie un editable propriété qui est vraie si la grille est actuellement dans un état modifiable. Ce code en profite pour activer/désactiver la possibilité d’édition de la grille :

let toggleEditing = () => { 
       if (grid.getOptions().editable) { 
                    grid.disableEditing();
       }
      else
      {
           grid.enableEditing();
     }
};

Un avertissement : vous pourriez être tenté d’utiliser l’un des événements liés aux données de la grille pour exécuter ce code. Ne le faites pas. Modification de la possibilité de modification dans l’un ou l’autre on-data-binding ou on-data-bound les événements provoquent le réaffichage et la reliure de la grille, ce qui entraînera le on-data-* les événements se déclencheront à nouveau, ce qui entraînera la réexécution de votre code, ce qui… en gros, vous serez pris dans une boucle sans fin (ne nous demandons pas comment je le sais). D’une manière générale, vous ne souhaitez pas modifier quoi que ce soit concernant les données dans la grille pendant le processus. on-data-* événements.

Définition du mode d’édition

Une fois que la grille est dans un état modifiable, la grille peut être dans l’un des trois modes suivants (voir mon article précédent pour les différences dans l’UX) :

Ici encore, plutôt que de définir le mode au moment de la compilation, vous souhaiterez peut-être basculer dynamiquement entre ces modes au moment de l’exécution en fonction de l’utilisateur, des données ou d’un autre ensemble de conditions.

Vous pouvez définir dynamiquement le mode de comestibilité de la grille à partir du code en appelant le setOptions fonction et, dans ce cas, définir la propriété modifiable mode propriété. Que mode la propriété peut être définie sur l’un des "incell" (la valeur par défaut), "inline" ou " popup".

Le mode la propriété et l’état modifiable de la grille sont interdépendants : définir la mode permet également l’édition ; rendre la grille modifiable équivaut à définir le mode sur "incell".
Voici trois exemples de fonctions JavaScript qui :

• Activer l’édition et définir le mode d’édition sur popup
• Remettre l’édition à la valeur par défaut de incell
• Désactiver la modification

let enablePopup = () => grid.setOptions({
      editable: { mode: "popup" }
  });
let restoreDefault = () => grid.enableEditing();
let disableEditing = () => grid.disableEditing();

Dans les anciennes versions de la grille, ces deux dernières fonctions ressembleraient à ceci :

let restoreDefault = () => grid.setOptions({
      editable: true
  });
let disableEditing = () => grid.setOptions({
      editable: false
  });

Contrôle des ajouts et des mises à jour de lignes individuelles

En plus de contrôler le mode d’édition, vous souhaiterez peut-être également contrôler la capacité des utilisateurs à mettre à jour ou supprimer des lignes individuelles.

Dans l’interface utilisateur de la grille, vous générez des boutons sur lesquels l’utilisateur peut cliquer pour activer la modification ou la suppression de lignes individuelles en ajoutant un column-commandà votre grille avec son attribut de nom défini pour modifier ou détruire. Si vous ne souhaitez pas que cette colonne soit affichée initialement (empêchant ainsi l’utilisateur de mettre à jour ou de supprimer des lignes individuelles), vous pouvez définir la valeur de la colonne. hidden attribut à true, comme dans cet exemple qui comporte à la fois un bouton d’édition et un bouton de suppression :

<columns>
    <column hidden="true">
        <commands>
            <column-command Name="edit" />
            <column-command Name="destroy" />
        </commands>
    </column>
   <column field="CustId" …

Pour afficher la colonne (permettant ainsi les mises à jour et les suppressions de lignes individuelles pour votre utilisateur), vous pouvez utiliser l’option de la grille. showColumn fonction, en passant le membre de la collection de colonnes de la grille que vous souhaitez afficher. Puisque ma colonne de commandes est la première colonne de ma grille, une fonction affichant cette colonne ressemblerait à ceci :

    let enableAddsDeletes = () => {
        grid.showColumn(grid.columns[0]);
}

Vous pouvez également masquer la colonne avec la grille hideColumn fonction. Si vous souhaitez activer les mises à jour et les suppressions séparément, placez simplement les boutons de modification et de suppression dans des colonnes séparées et affichez/masquez-les individuellement.

Dans l’UX de la grille, l’ajout de nouvelles lignes à la grille est géré via un bouton Ajouter un nouvel enregistrement dans la barre d’outils de la grille. Vous pouvez contrôler le moment où les boutons apparaissent dans la barre d’outils et ajouter vos propres boutons à la barre d’outils, également en utilisant l’option de la grille. toolbar élément.

Une fois que vous avez ajouté la grille toolbar élément, c’est à vous de décider quels boutons apparaissent en haut de votre grille. La manière la plus simple d’ajouter un bouton est d’utiliser le toolbar-button élément pour ajouter un des boutons intégrés de la grille. Vous spécifiez lequel des boutons intégrés ajouter en définissant la valeur du bouton Name attribut à de la grille commandes intégrées.

Cet exemple définit le toolbar-buttonc’est Name attribuer à "create' pour mettre un bouton « Ajouter un nouvel enregistrement » sur la barre d’outils :

<kendo-grid name="gridCustomer">
    <toolbar>
        <toolbar-button Name="create"/>

Le Name L’attribut définit également le data-role attribut sur le bouton HTML généré à partir de ce balisage : vous pouvez l’utiliser data-role pour obtenir une référence à ce bouton afin que vous puissiez le gérer. Ce code, par exemple, configure une variable pour contenir une référence à mon bouton de création, puis trouve ce bouton de création dans la fonction prête pour jQuery et (enfin) masque le bouton :

let createButton;
$(
        () => {
                     createButton = $('button[data-role="create"]');
                     createButton.hide();
        }
);

Vous pouvez également utiliser le toolbar-button élément pour ajouter vos propres boutons à la barre d’outils. Vous pouvez définir l’interface utilisateur de votre nouveau bouton (qui ne doit pas nécessairement être un bouton) en imbriquant un toolbar-command-template à l’intérieur du toolbar-button.

Cet exemple étend la barre d’outils avec un kendo-button affichant le texte « Activer les créations » et l’une des icônes de Telerik liste d’icônes. L’événement au clic du bouton est configuré pour appeler une fonction appelée showCreate qui révélera le bouton de création :

<kendo-grid name="gridCustomer">
    <toolbar>
        <toolbar-button Name="create"/>

       <toolbar-button> 
            <toolbar-command-template> 
               <kendo-button name="showCreateButton"                                 
                                                icon="thumb-up-outline"
                                                on-click="showCreate"> 
                    Enable Creates
                </kendo-button> 
            </toolbar-command-template> 
      </toolbar-button>

Voilà ça showCreate fonction, en tirant parti de la référence au bouton de création que j’ai créé dans mon exemple de code précédent :

let showCreate =  () =>  createButton.show();

Il s’agit évidemment d’un « code démo » (pourquoi masquer le bouton de création si le simple fait de cliquer sur un autre bouton l’affichera ?). Dans la vraie vie, tu appellerais le showCreate fonctionner dans le cadre de la vérification des autorisations de l’utilisateur (ou d’autres conditions) pour décider si l’utilisateur doit avoir accès au bouton de création.

Dans cet article, je me suis délibérément limité aux parties de l’API JavaScript de kendo-grid directement liées à l’UX de mise à jour de la grille. Il y a une raison à cela : l’API de la grille est énorme et je devais limiter la longueur de cet article de blog à une certaine longueur (semi-raisonnable). Mais il y a un point plus important ici : si jamais vous découvrez qu’il y a quelque chose que vous ne pouvez pas faire lors de la déclaration de votre grille, vous pouvez probablement trouver quelque chose dans l’API de la grille qui vous permettra de faire ce que vous voulez.