MainGrid

Le MainGrid composant est une grille autonome pour afficher les enregistrements Dataverse. Contrairement SubGridà , il ne nécessite pas de parent RecordContext — il charge les enregistrements directement depuis une table ou une vue spécifiée.

Chargement par nom de tableau

Réglez le TableName paramètre pour charger automatiquement toutes les vues publiques de cette table. La première vue par défaut est sélectionnée au départ.

Chargement par identifiants de vue

Utilisez ViewIds et DefaultViewId pour contrôler exactement quelles vues sont disponibles et lesquelles sont sélectionnées lors du chargement. Vous pouvez également fournir CustomViewDefinitions un FetchXML en ligne pour définir les vues directement dans le code.

Vues personnalisées avec FetchXML

Utilisez CustomViewDefinitions pour définir des vues avec des requêtes FetchXML personnalisées. Cela est utile pour les vues qui incluent des filtres basés sur l’utilisateur actuel, les entités liées ou d’autres critères dynamiques.

Note

Le Id pour une custom GridViewDefinition doit être un GUID aléatoire unique qui ne correspond pas à une vue Dataverse existante. Si elle correspond à un ID de vue existant, la vue Dataverse aura priorité et la définition personnalisée sera ignorée.

Affichage Nom

Réglez DisplayName sur a GridViewDefinition pour fournir une étiquette par défaut à la vue dans le sélecteur déroulant sans nécessiter d’entrée de fichier de localisation. Si une clé de localisation existe en tables.{TableName}.views.{Id}.label, elle a la priorité sur DisplayName. C’est utile pour les vues personnalisées où vous souhaitez un nom lisible immédiatement sans ajouter d’entrée de localisation.

Boutons de la barre d’outils

Il MainGrid supporte les mêmes boutons de barres d’outils que SubGrid. Pour les grilles autonomes, NavigateNewRecordGridButton et NavigateOpenRecordGridButton sont couramment utilisées pour naviguer vers des pages de formulaires séparées. Consultez la documentation Grid Buttons pour une référence complète de tous les boutons disponibles et de leurs options de configuration.

Comportement dans la boîte de recherche

Lorsque l’utilisateur tape dans la boîte de recherche de la grille, la vue configurée est automatiquement reinterrogée avec des conditions de filtre supplémentaires appliquées à chaque colonne éligible à la recherche affichée dans la vue. Les conditions sont associées à la OR logique, donc un enregistrement est inclus si l’une de ses colonnes visibles correspond au terme de recherche. La sémantique de correspondance par défaut diffère selon le type de colonne.

Texte et colonnes de recherche

Les colonnes de texte (champs de chaînes) et les colonnes de recherche (associées au nom principal de l’enregistrement cible) utilisent par défaut un démarrage par recherche. La saisie joh correspond à des valeurs qui commencent par joh — par exemple John ou Johnson. La correspondance est déléguée à l’opérateur de like FetchXML, qui est insensible à la casse dans Dataverse.

Utilisez-les * comme joker pour un jumelage plus flexible. La saisie *hn effectue une correspondance de type contains-style (par Johnexemple , Johnson) ; la correspondance j*n de type correspond à des valeurs où n’importe quel caractère peut apparaître entre le j et ( n par Johnexemple , Joneson). Le joker est converti en joker de % FetchXML au moment de la requête.

Colonnes de choix

Les colonnes de choix (ensembles d’options / listes de sélection) et les colonnes de sélection multiple sont comparées à l’etiquetatte d’affichage localisée de chaque option plutôt qu’à la valeur entière sous-jacente. Les labels sont comparés de manière insensible à la casse et à l’accent dans la culture de l’utilisateur actuel, donc la cafe saisie correspondra à une option étiquetée Café. Lorsque une ou plusieurs étiquettes d’option correspondent, la requête émet une condition FetchXML par rapport aux valeurs correspondantes — une in condition pour les colonnes à sélection unique, ou une contain-values condition pour les colonnes à sélection multiple. Lorsque les étiquettes ne correspondent pas, la colonne n’apporte aucune condition (en gardant le OR filtre compact).

Les colonnes de choix honorent le même * joker que les colonnes de texte : par défaut, la correspondance commence par (taper act correspondances Active), et un ouvrage * passe à contains (taper *act complémentairement correspondance Inactive). Les lignes correspondantes ont la sous-chaîne correspondante surlignée dans la grille, exactement comme les correspondances entre colonnes de texte.

Colonnes numériques et monétaires

Les colonnes numériques — int, big int, décimal, double et money — supportent les opérateurs de comparaison dans le terme de recherche. La boîte de recherche analyse un opérateur initial optionnel et applique l’opérateur de condition FetchXML correspondant :

• = 100 ou simplement 100  —  égal (le défaut lorsqu’aucun opérateur n’est spécifié)
• > 100  —  plus grand que
• < 100  —  moins que
• >= 100  —  supérieur ou égal
• <= 100  —  inférieur ou égal

Note

Les conditions de recherche pour chaque type de colonne sont ajoutées au même OR groupe de filtres, de sorte que le même terme de recherche est évalué simultanément par rapport aux colonnes de texte, aux colonnes de recherche, aux colonnes de choix et aux colonnes numériques. Taper 100 une grille comportant à la fois une colonne de nom et une colonne de montant correspondra aux enregistrements dont le nom commence par 100 ou dont le montant est égal à 100. Le filtre de recherche est superposé au-dessus du filtre existant de la vue, de sorte que les contraintes au niveau de la vue (comme un statecode = 0 filtre) sont toujours conservées.

Désactivation de la recherche

Réglé AllowSearch="false" sur la grille pour masquer complètement la barre de recherche. Cela est utile pour les grilles qui ne contiennent qu’un petit ensemble fixe d’enregistrements, ou où le filtrage est géré de l’extérieur (par exemple via une barre d’outils personnalisée).

Mode de pagination

La grille prend en charge deux stratégies de pagination via le PagingMode paramètre (Blazor) / pagingMode prop (React). Les deux modes utilisent la même vue sous-jacente, FetchXML, tri et recherche — seule la manière dont les lignes sont révélées à l’utilisateur diffère.

• Paged (par défaut) — un classique pistage Précédent / Suivant avec un sélecteur de taille de page. Idéal pour des ensembles de résultats plus courts et pour les cas où l’utilisateur souhaite sauter par numéro de page ou partager une page à lien profond dans l’URL.
• Virtualize — parchemin infini. Le pied de page du pager est caché, les lignes s’accumulent à mesure que l’utilisateur fait défiler le bas affiché, et la page suivante se récupère automatiquement. Un compteur en lecture seule « Affichant 1-N de M » remplace le pager une fois qu’un total est disponible. C’est idéal pour de longues listes où l’utilisateur scanne plutôt que de naviguer par page.

Inscrivez-vous en réglant le mode de pagination sur la grille :

Compromis

• Pas de passage direct à la page. Le mode virtualisation commence toujours à la première page et avance ; les consommateurs ne peuvent plus passer à la page N. Si vous avez besoin d’une navigation explicite sur les pages, restez sur Paged.
• Page n’est pas maintenu. Puisque la position de défilement de l’utilisateur n’est pas un concept de page distincte, PersistedStateQueryParameter la p clé est omis en mode virtualisation. La recherche en vue, tri et (en optant) sélectionnée continue de faire un aller-retour sur l’URL.
• La recherche et le tri fonctionnent toujours, mais ils réinitialisent l’accumulateur défilé — changer la vue active, appliquer un nouveau tri ou taper dans la boîte de recherche supprime les lignes chargées et les relance depuis le haut.
• Masque le pager / le sélecteur de taille de page. Le sélecteur de taille de page est remplacé par une taille de bloc fixe ; définir la valeur initiale via DefaultItemsPerPage (Blazor) / pageSize (Réagir) pour contrôler combien de lignes sont récupérées par page déclenchée par défilement.

Mode taille complète

Réglé FullSize="true" pour faire s’étendre la grille afin de remplir toute la hauteur de son conteneur parent. C’est utile lorsque la grille est le contenu principal d’une page.

État persistant de la grille

En définissant PersistedStateQueryParameter un nom de paramètre de requête (par exemple "gridState"), la grille reflétera son état interactif dans un seul paramètre URL sous ce nom. Chaque modification menée par l’utilisateur — changer la vue sélectionnée, paginar, redimensionner la taille de la page, cliquer sur les en-têtes de colonne pour trier, ou (s’inscrire) taper dans la boîte de recherche — re-encode l’état et remplace le paramètre URL en place. Lorsque la page est ouverte avec le paramètre présent (favori, lien partagé, rafraîchissement), la grille lit le paramètre lors du premier chargement et restaure tout l’état capturé avant de récupérer les données.

Ce qui persiste

Le paramètre de requête encode un objet JSON compact avec une touche courte par morceau d’état. Les clés sont délibérément abrégées pour garder les URL favorites courtes. Les champs correspondant à leurs valeurs naturelles par défaut sont omis, donc une grille à la page 1 sans tri ni recherche produit une masse bien plus petite qu’une avec les cinq champs remplis.

• v — le GUID de la vue sélectionnée (minuscule, trait d’union, sans appareils). Correspond à l’une des ViewIds entrées CustomViewDefinitions / avec lesquelles la grille était configurée.
• p — le numéro de page basé sur 1. Omise lorsque l’utilisateur est à la page 1 (par défaut).
• ps — le nombre de lignes par page. Reflète la dernière sélection de l’utilisateur dans le menu déroulant de taille de page ; Omise lorsqu’elle correspond à celle de DefaultItemsPerPagela grille.
• s — un ensemble ordonné de directives de tri. Chaque entrée a c (nom logique de colonne) et une option d (définie à true pour descendant ; ascendant est le défaut non marqué, donc d omise dans ce cas). L’état vide / non trié omet complètement le champ. Le tri multi-colonnes est conservé dans l’ordre de préséance.
• q — le texte actuel de la boîte de recherche. Inclus uniquement lorsque la grille était configurée avec IncludeSearchInPersistedState="true" ET que la boîte a une valeur non vide. Par défaut, car les termes de recherche peuvent être sensibles (par exemple, les noms des clients dans un contexte CRM).

Encodage d’URL

L’état est sérialisé en JSON compact (sans espace blanc) et encodé par URL dans le paramètre de requête. Une grille montrant la page 3 d’une vue de contact, triée par nom de famille ascendant puis créée en descendant, avec la recherche « smith » activée, allait faire circuler la charge utile suivante :

Après l’encodage d’URL, la valeur réelle de la barre d’adresses ressemble à ceci (le framework appelle encodeURIComponent la chaîne JSON avant de l’écrire) :

Suppression par valeur par défaut

L’encodeur retire tout champ correspondant à son défaut naturel avant la sérialise. Page 1 élimine p, une liste de tri vide disparaît s, un tri non marqué ascendant disparaît d, et une recherche vide disparaît q. Une grille fraîchement chargée sans interaction utilisateur s’encode en un blob contenant uniquement v et ps — empêchant les URL favorisées de croître pour un état que le consommateur n’a pas touché.

Comportement de l’historique du navigateur

Les changements d’état mettent à jour l’URL avec history.replaceState — ils ne poussent pas les nouvelles entrées vers la pile arrière. Cela signifie que cliquer sur Retour depuis une page de grille revient à la page distincte précédente (l’origine de navigation de l’utilisateur), et non à la combinaison de tri/page précédente. Le compromis est intentionnel : une seule session de grille peut produire des dizaines de changements d’état, et appuyer sur chacun comme entrée de navigation rendrait le bouton Retour pratiquement inutile sur le reste de l’application.

Activation de la persistance de la recherche

Par défaut, le texte de recherche est exclu de l’URL afin que le paramètre soit sûr à partager même lorsque la grille filtre par un terme sensible. Définissez IncludeSearchInPersistedState="true" pour inclure la valeur actuelle de la boîte de recherche dans la charge utile encodée (ajoutée comme champ q ci-dessus). Une fois activée, la recherche devient partie de l’état de favoris — l’utilisateur peut copier l’URL et le destinataire se retrouve sur la même vue : page, tri ET la même combinaison de filtre.

Compatibilité inter-stack

La forme JSON encodée est identique entre les implémentations de la grille Blazor et React — même nom de paramètre, mêmes clés (v / p / ps / s / ), qmême sémantique de valeurs. Un lien produit par une pile est consommable par l’autre, de sorte qu’une organisation qui exécute les deux surfaces (par exemple, un portail React public accompagné d’une application d’administration Blazor interne) peut partager des URL de grille entre elles sans aucune couche de traduction par pile.

Plusieurs grilles sur une même page

Deux grilles sur la même page doivent porter des noms différentsPersistedStateQueryParameter. Chaque grille ne lit et écrit que son propre paramètre, donc réutiliser le même nom ferait en sorte que les deux grilles se disputent le même emplacement d’URL — la dernière écriture l’emporte et l’autre grille perd son état à chaque changement. Une convention typique consiste à nommer le paramètre d’après le rôle de la grille (par contactsState exemple + accountsState).

Grilles multi-tables

A MainGrid peut afficher des vues provenant de différentes tables en incluant les identifiants de vues de plusieurs tables de la ViewIds collection. Lorsque l’utilisateur change de vue, la grille charge automatiquement les données de la bonne table. Utilisez le OnClick rappel sur les boutons de navigation pour définir dynamiquement l’URL en fonction du nom de la table de la vue sélectionnée.