MainGrid

Die Komponente MainGrid ist ein eigenständiges Raster zur Darstellung von Dataverse-Datensätzen. Im Gegensatz zu SubGridbenötigt sie keinen Elternteil RecordContext – sie lädt Datensätze direkt aus einer bestimmten Tabelle oder Ansicht.

Laden nach Tabellennamen

Stellen Sie den Parameter TableName so ein, dass alle öffentlichen Ansichten für diese Tabelle automatisch geladen werden. Die erste Standardansicht wird zunächst ausgewählt.

Laden nach View-IDs

Verwenden ViewIds Sie und DefaultViewId steuern Sie genau, welche Ansichten verfügbar sind und welche beim Laden ausgewählt wird. Sie können auch Inline-FetchXML bereitstellen CustomViewDefinitions , um Ansichten direkt im Code zu definieren.

Benutzerdefinierte Ansichten mit FetchXML

Verwenden CustomViewDefinitions Sie, um Ansichten mit benutzerdefinierten FetchXML-Abfragen zu definieren. Dies ist nützlich für Ansichten, die Filter basierend auf dem aktuellen Nutzer, verknüpften Entitäten oder anderen dynamischen Kriterien enthalten.

Anmerkung

Das Id für eine benutzerdefinierte Ansicht GridViewDefinition muss ein eindeutiger zufälliger GUID sein, der nicht einer bestehenden Dataverse-Ansicht entspricht. Wenn sie mit einer bestehenden Ansichts-ID übereinstimmt, hat die Dataverse-Ansicht Vorrang und die benutzerdefinierte Definition wird ignoriert.

DisplayName

Auf a GridViewDefinition eingestelltDisplayName, um im Dropdown-Menü eine Standardbezeichnung für die Ansicht bereitzustellen, ohne dass ein Lokalisierungsdateieintrag erforderlich ist. Wenn ein Lokalisierungsschlüssel bei tables.{TableName}.views.{Id}.labelexistiert, hat er Vorrang vor DisplayName. Das ist nützlich für benutzerdefinierte Ansichten, bei denen man sofort einen lesbaren Namen möchte, ohne einen Lokalisierungseintrag hinzuzufügen.

Werkzeugleisten-Buttons

Unterstützt MainGrid die gleichen Symbolleisten-Buttons wie SubGrid. Für eigenständige Raster und NavigateOpenRecordGridButton werden häufig verwendet, NavigateNewRecordGridButton um zu separaten Formularseiten zu navigieren. Siehe die Dokumentation zu den Grid Buttons für eine vollständige Referenz aller verfügbaren Buttons und ihrer Konfigurationsoptionen.

Suchbox-Verhalten

Wenn der Benutzer in das Suchfeld des Rasters eingibt, wird die konfigurierte Ansicht automatisch erneut abgerufen, wobei zusätzliche Filterbedingungen auf jede suchberechtigte Spalte angewendet werden, die in der Ansicht angezeigt wird. Die Bedingungen sind mit OR der Logik verbunden, sodass ein Datensatz enthalten ist, wenn eine seiner sichtbaren Spalten mit dem Suchbegriff übereinstimmt. Die Standardübereinstimmung variiert je nach Spaltentyp.

Text- und Nachschlagspalten

Textspalten (Zeichenkettenfelder) und Nachschlagespalten (abgeglichene mit dem primären Namen des Zieldatensatzes) verwenden standardmäßig eine Start-mit-Suche . Die Eingabe stimmt Werten joh ab, die mit joh — zum Beispiel John oder Johnsonbeginnen. Das Match wird an den like Operatoren von FetchXML delegiert, der in Dataverse als Groß- und Kleinschreibungsunempfindlich gilt.

Nutze sie * als Wildcard für flexiblere Matching. Das Typisieren *hn führt einen Contains-Stil Match aus (z. B. John, Johnson); Typing übereinstimmt Werte j*n , bei denen beliebige Zeichen zwischen der j und der n (z. B. John, Joneson) erscheinen können. Die Joker wird zur Abfragezeit in die % Joker von FetchXML umgewandelt.

Auswahlspalten

Auswahlspalten (Optionssets / Auswahllisten) und Mehrfachauswahl-Spalten werden mit dem lokalisierten Anzeigelabel jeder Option abgeglichen, anstatt mit dem zugrundeliegenden Ganzzahlwert. Labels werden in der Kultur des aktuellen Nutzers mit Kasus und Akzent unempfindlich verglichen, sodass das Tippen cafe mit einer Option namens Café. Wenn eine oder mehrere Optionslabels übereinstimmen, sendet die Abfrage eine FetchXML-Bedingung gegen die übereinanderstimmenden Optionswerte – eine in Bedingung für Einzelauswahl-Spalten oder eine contain-values Bedingung für Mehrfachauswahl-Spalten. Wenn keine Labels übereinstimmen, trägt die Spalte keine Bedingung bei (wodurch der Filter OR kompakt bleibt).

Auswahlspalten respektieren denselben * Joker wie Textspalten: Standardmäßig beginnt das Match mit (tippt act übereinander Active), und ein anführendes * Symbol wechselt zu contains (tippen *act zusätzlich stimmt überein). Inactive Passende Zeilen haben die passende Teilzeichenkette im Raster markiert, genau wie Text-Spalten-Übereinstimmungen.

Numerische und Geld-Spalten

Numerische Spalten – int, big int, dezimal, doppelt und money – unterstützen Vergleichsoperatoren im Suchbegriff. Das Suchfeld analysiert einen optionalen führenden Operator und wendet den entsprechenden FetchXML-Bedingungsoperator an:

• = 100 oder einfach 100  — gleich  (der Standard, wenn kein Operator angegeben ist)
• > 100  —  größer als
• < 100  —  weniger als
• >= 100  —  größer als oder gleich
• <= 100  —  kleiner als oder gleich

Anmerkung

Suchbedingungen für jeden Spaltentyp werden derselben OR Filtergruppe hinzugefügt, sodass derselbe Suchbegriff gleichzeitig gegen Textspalten, Nachschlagespalten, Auswahlspalten und numerische Spalten ausgewertet wird. Das Eingeben 100 eines Rasters, das sowohl eine Namens- als auch eine Zahlenspalte enthält, wird Einträge abgestimmt, deren Name mit 100 100 beginnt oder deren Betrag 100 entspricht. Der Suchfilter wird über den vorhandenen Filter der Ansicht gelegt, sodass Ansichtsebene-Einschränkungen (wie ein statecode = 0 Filter) immer erhalten bleiben.

Suche deaktivieren

Auf dem Raster eingestellt AllowSearch="false" , um das Suchfeld komplett zu verbergen. Dies ist nützlich für Raster, die nur eine kleine feste Anzahl von Datensätzen enthalten oder bei denen das Filtern extern durchgeführt wird (zum Beispiel über eine benutzerdefinierte Werkzeugleiste).

Paging-Modus

Das Gitter unterstützt zwei Paging-Strategien über den Parameter PagingMode (Blazor) / pagingMode Prop (React). Beide Modi verwenden dieselbe zugrundeliegende Ansicht, FetchXML, Sortieren und Suche – nur die Art und Weise, wie Zeilen dem Benutzer offenbart werden, unterscheidet sich.

• Paged (Standard) — ein klassischer Prev / Next Footer mit Seitengrößenauswahl. Am besten für kürzere Ergebnissets und für Fälle, in denen der Nutzer nach Seitenzahl wechseln oder eine tief verlinkte Seite in der URL teilen möchte.
• Virtualize — unendliche Schriftrolle. Der Pager-Fußer ist versteckt, Zeilen sammeln sich, wenn der Benutzer am gerenderten Untergrund vorbeiscrollt, und die nächste Seite wird automatisch geholt. Ein schreibgeschützter "Zeigt 1-N von M"-Zähler ersetzt den Pager, sobald eine Gesamtzahl verfügbar ist. Am besten für lange Listen, bei denen der Nutzer scannt statt nach Seite zu navigieren.

Melden Sie sich an, indem Sie den Paging-Modus auf dem Raster einstellen:

Kompromisse

• Kein Seitensprung. Der Virtualisierungsmodus beginnt immer auf der ersten Seite und zieht vorwärts; Verbraucher können nicht mehr zu Seite N springen. Wenn du eine explizite Seitennavigation brauchst, bleib auf Paged.
• Die Seite ist nicht persistiert. Da die Scrollposition des Benutzers kein diskretes Seitenkonzept ist, PersistedStateQueryParameter lässt der p Schlüssel im Virtualisierungsmodus weg. Ausgewählte Ansicht, Sortieren und (Opt-in) Suche laufen weiterhin rundweg durch die URL.
• Suchen und Sortieren funktionieren weiterhin, aber sie setzen den eingerollten Akkumulator zurück – wenn die aktive Ansicht geändert wird, eine neue Sortierung angewendet oder in das Suchfeld getippt wird, werden die geladenen Zeilen entfernt und von oben erneut abgerufen.
• Verbirgt den Pager / Seitengrößenwahlschalter. Der Seitengrößenwahler wird durch eine feste Chunk-Größe ersetzt; Setzen Sie den Anfangswert über DefaultItemsPerPage (Blazor) / pageSize (React), um zu steuern, wie viele Zeilen pro scroll-ausgelöster Seite abgerufen werden.

Full-Size-Modus

Stellen Sie ein, FullSize="true" dass das Gitter sich ausdehnt und die volle Höhe seines Elterncontainers ausfüllt. Das ist nützlich, wenn das Raster der Hauptinhalt einer Seite ist.

Persistierender Gitterzustand

Setzt PersistedStateQueryParameter man auf einen Abfrageparameternamen (z. B. "gridState") und das Raster spiegelt seinen interaktiven Zustand in einen einzigen URL-Parameter unter diesem Namen wider. Jede benutzergesteuerte Änderung – das Wechseln der ausgewählten Ansicht, das Ausrufen, das Anpassen der Seitengröße, das Klicken auf Spaltenüberschriften zum Sortieren oder das (Opt-in) Eingabe in das Suchfeld – kodiert den Zustand neu und ersetzt den URL-Parameter. Wenn die Seite mit dem vorhandenen Parameter geöffnet wird (Lesezeichen, geteilter Link, Aktualisierung), liest das Raster den Parameter beim ersten Laden und stellt den gesamten erfassten Zustand wieder her, bevor die Daten abgerufen werden.

Was bleibt bestehen

Der Abfrageparameter kodiert ein kompaktes JSON-Objekt mit einem kurzen Schlüssel pro Zustandsstück. Schlüssel werden absichtlich abgekürzt, um die Lesezeichen der URLs kurz zu halten. Felder, die ihren natürlichen Standardwerten entsprechen, werden weggelassen, sodass ein Raster auf Seite 1 ohne Sortierung und ohne Suche einen viel kleineren Blob erzeugt als eines, in dem alle fünf Felder ausgefüllt sind.

• v— das GUID der ausgewählten Ansicht (Kleinbuchstaben, mit Bindestrich, ohne Klammern). Stimmt mit einem der / CustomViewDefinitions Einträge überein, mit denen ViewIds das Raster konfiguriert wurde.
• p — die 1-basierte Seitenzahl. Weggelassen, wenn der Nutzer auf Seite 1 ist (der Standard).
• ps— die Anzahl der Zeilen pro Seite. Spiegelt die letzte Auswahl des Nutzers im Dropdown-Menü zur Seitengröße wider; weggelassen, wenn es mit dem Raster übereinstimmt.DefaultItemsPerPage
• s – ein geordnetes Array von Sort-Direktiven. Jeder Eintrag hat c (logischer Spaltenname) und eine optionale d (gesetzt auf true absteigend; aufsteigend ist der unmarkierte Standardwert und d wird in diesem Fall weggelassen). Leerer / unsortierter Zustand lässt das Feld komplett weg. Die Mehrspaltensortierung bleibt in der Vorrangreihenfolge erhalten.
• q — der aktuelle Text im Suchfeld. Nur dann enthalten, wenn das Gitter mit IncludeSearchInPersistedState="true" UND die Box einen nicht leeren Wert hat. standardmäßig ausgeschaltet, da Suchbegriffe empfindlich sein können (z. B. Kundennamen im CRM-Kontext).

URL-Codierung

Der Zustand wird als kompaktes JSON (ohne Leerraum) serialisiert und URL-kodiert in den Abfrageparameter. Ein Raster, das Seite 3 einer Kontaktansicht zeigt, sortiert nach Nachnamen, aufsteigend und dann auf absteigend, mit aktivierter Suche "Smith", würde die folgende Nutzlast hin und her umrunden:

Nach der URL-Codierung sieht der eigentliche Wert der Adressleiste so aus (das Framework ruft encodeURIComponent den JSON-String vor dem Schreiben auf):

Default-Value Stripping

Der Encoder entfernt jedes Feld, das seinem natürlichen Standard entspricht, bevor er serialisiert. Seite 1 fällt aus, peine leere Sortierliste fällt saus, eine unmarkierte aufsteigende Sortierung fällt d, und eine leere Suche fällt qaus. Ein frisch geladenes Raster ohne Benutzerinteraktion kodiert zu einem Blob, der nur v und enthält – ps und verhindert, dass Lesezeichen-URLs für den Zustand wachsen, den der Verbraucher nicht berührt hat.

Browser-Verlaufsverhalten

Statusänderungen aktualisieren die URL mit history.replaceState – sie verschieben keine neuen Einträge auf den Backstack. Das bedeutet, dass das Zurückdrücken von einer Gitterseite zur vorherigen eindeutigen Seite (dem Navigationsursprung des Benutzers) zurückkehrt, nicht zur vorherigen Sortier-/Seitenkombination. Der Kompromiss ist beabsichtigt: Eine einzelne Grid-Sitzung kann Dutzende von Zustandsänderungen verursachen, und wenn man jede einzelne als Navigationseintragung drückt, würde der Zurück-Button im Rest der App praktisch nutzlos machen.

Aktivierung der Suchpersistenz

Standardmäßig wird Suchtext von der URL ausgeschlossen, sodass der Parameter auch dann sicher geteilt werden kann, wenn das Raster nach einem sensiblen Begriff filtert. Stellen Sie ein, IncludeSearchInPersistedState="true" dass der aktuelle Wert des Suchfelds in der codierten Nutzlast enthalten ist (hinzugefügt als obiges Feld q ). Sobald aktiviert, wird die Suche Teil des Lesezeichenzustands – der Benutzer kann die URL kopieren und der Empfänger landet auf derselben Kombination aus Ansicht, Seite, Sortierung UND Filter.

Cross-Stack-Kompatibilität

Die kodierte JSON-Form ist identisch zwischen den Blazor- und React-Grid-Implementierungen – gleicher Parametername, gleiche Schlüssel (v / p / ps / s / ), qgleiche Wertsemantik. Ein Link, der von einem Stack erzeugt wird, ist vom anderen konsumierbar, sodass eine Organisation, die beide Oberflächen betreibt (z. B. ein öffentlich zugängliches React-Portal zusammen mit einer internen Blazor-Admin-App), Grid-URLs ohne eine Übersetzungsschicht pro Stack gemeinsam teilen kann.

Mehrere Raster auf einer Seite

Zwei Gitter auf derselben Seite müssen unterschiedliche PersistedStateQueryParameter Namen tragen. Jedes Gitter liest und schreibt nur seinen eigenen Parameter, sodass die Wiederverwendung desselben Namens dazu führen würde, dass beide Gitter um denselben URL-Slot kämpfen – letzter Schreib gewinnt, und das andere Gitter verliert bei jeder Änderung seinen Zustand. Eine typische Konvention ist es, den Parameter nach der Rolle des Gitters zu benennen (z. B. contactsState + accountsState).

Mehrtabellengitter

A MainGrid kann Ansichten aus verschiedenen Tabellen anzeigen, indem sie Ansichts-IDs aus mehreren Tabellen in der ViewIds Sammlung einfügt. Wenn der Benutzer die Ansicht wechselt, lädt das Raster automatisch die Daten der richtigen Tabelle. Verwenden Sie die OnClick Callback-Buttons, um die URL dynamisch basierend auf dem Tabellennamen der ausgewählten Ansicht einzustellen.