Overzicht van modern opdrachtgebruik
Opdrachten sturen het gedrag van kerntoepassingen aan voor modelgestuurde apps. Dit zijn de knoppen waarmee gebruikers interacties hebben tijdens het spelen van apps en de resulterende acties die worden uitgevoerd wanneer een knop wordt geselecteerd. Elke opdracht wordt gepositioneerd ten opzichte van andere opdrachten en is gebonden aan een opdrachtbalklocatie binnen de app.
Op een hoog niveau past opdrachtaanpassing in de volgende categorieën. Er zijn verschillende mogelijkheden binnen elke categorie en deze worden uitgebreider behandeld in documentatie voor modern opdrachtgebruik:
- Weergave. Hoe de knop wordt weergegeven en waar deze zich in een app bevindt. Bijvoorbeeld het label, het pictogram en de toegankelijkheidslabels van de knop, evenals de locatie en positie van de opdrachtbalk binnen een opdrachtbalk.
- Actie. De logica die wordt uitgevoerd wanneer een knop wordt geselecteerd. Bijvoorbeeld het maken en bijwerken van gegevens of interactie met verschillende besturingselementen en pagina's in de app.
- Zichtbaarheid. Logische voorwaarden die aangeven wanneer een knop zichtbaar of verborgen is voor een gebruiker. U wilt bijvoorbeeld dat de knop zichtbaar is voor sommige gebruikers en verborgen voor andere. Of misschien moet de knop pas zichtbaar worden als aan bepaalde criteria van de gegevensrecords wordt voldaan.
Locaties van opdrachtbalk
Hoofdraster. Deze opdrachtbalk die wordt weergegeven als u de appnavigatie aan de linkerkant gebruikt om een volledige paginalijst met records in deze tabel weer te geven.
Hoofdformulier. De opdrachtbalk die wordt weergegeven op de hoofdformulieren van deze tabel. Dit wordt boven aan het formulier weergegeven en is niet hetzelfde als de bijbehorende weergave of subrasterweergave die in verschillende delen van het formulier wordt weergegeven.
Subrasterweergave. Deze opdrachtbalk wordt weergegeven op formulieren van andere tabellen, die de gegevens van deze tabel in een subraster weergeven. Het accounthoofdformulier heeft bijvoorbeeld een subrasterbesturingselement dat contactpersoonrecords weergeeft die zijn gerelateerd aan de accountrecord. Om de onderstaande opdrachtbalk te bewerken, bewerkt u de opdrachtbalk voor de contacttabel en vervolgens de subrasterweergave.
Gekoppelde weergave. Deze opdrachtbalk wordt weergegeven in het formulier van een bovenliggende tabel bij het weergeven van gerelateerde gegevens in deze tabel. Selecteer bijvoorbeeld in het hoofdformulier van een accountrecord de Verwant tabblad selecteer vervolgens een gerelateerde tabel zoals contacten.
Snelle acties. Snelle acties zijn gekoppeld aan de hoofdrasterlocatie. Als u opdrachten wilt toevoegen of bewerken voor zowel snelle acties als hoofdrasterlocaties, selecteert u de gewenste tabel in de moderne appontwerper, bewerkt u vervolgens de opdrachtbalk en kiest u de hoofdrasterlocatie. De eerste vijf opdrachten, bepaald op volgorde, worden eveneens als snelle acties weergegeven tijdens het spelen van de app.
Notitie
Minder vaak aangepaste opdrachtbalklocaties worden niet ondersteund in de opdrachtontwerper. Zie de secties Algemene opdrachtbalk en andere linten voor meer informatie over het aanpassen van opdrachten voor deze locaties.
Typen opdrachten
- Opdracht. Standaardknop. Voert een actie uit wanneer deze wordt geselecteerd. Kan ook worden genest in groepen binnen vervolgkeuzelijsten en splitsknoppen. Deze werden flyouts genoemd bij klassiek opdrachtgebruik.
- Vervolgkeuzelijst. Hiermee wordt een menu gemaakt waarin u opdrachten kunt ordenen binnen een groep.
- Groep. Voeg titels toe aan groepen opdrachten die zijn genest binnen vervolgkeuzelijsten en knoppen Split.
- Splitsknop. Vergelijkbaar met een vervolgkeuzelijst, maar heeft een primaire opdracht. Wanneer de splitsknop is geselecteerd, wordt de actie van de primaire opdracht uitgevoerd. Als de punthaak voor uitvouwen wordt geselecteerd, wordt de primaire opdracht niet uitgevoerd. In plaats daarvan wordt een lijst uitgevouwen om extra groepen, flyouts en opdrachten weer te geven.
Belangrijkste verschillen tussen klassieke en moderne opdrachten
Klassieke opdrachten (voorheen bekend als het lint) waren niet aanpasbaar met behulp van weinig code. Met code waren opdrachtaanpassingen moeilijk, vervelend en foutgevoelig. Voor het schalen van opdrachtgebruik naar weinig code en het gebruiken van aangepaste pagina's om canvas- en modelgestuurde apps samen te voegen, was het van vitaal belang om de opdrachtinfrastructuur opnieuw uit te vinden en opnieuw op te bouwen.
Modern opdrachtgebruik biedt veel nieuwe mogelijkheden en is veel eenvoudiger te gebruiken.
| Mogelijkheid | Klassiek | Modern |
|---|---|---|
| Ondersteund tijdens uitvoering van modelgestuurde apps | Ja | Ja, ondersteunt bovendien Power Fx-runtime. |
| Aangepast met | Handmatige bewerking van XML in oplossingsbestanden of met behulp van tools van derden. Vereiste tijdrovende export- en importbewerkingen voor oplossingen. | Opdrachtontwerper en Dataverse API-ondersteuning. |
| Ondersteunt Power Fx. | No | Ja. Voor acties en zichtbaarheid. |
| Tijd vereist voor aanpassing | Traag, foutgevoelig. | Snel |
| Betrouwbaarheid en prestaties | Makkelijk om fouten te maken. Slechte aanpassing en gebrek aan bereikbepaling zijn vaak van invloed op app-prestaties | Inline foutafhandeling voorkomt fouten. Power Fx geoptimaliseerd voor betere runtime-prestaties. |
| Delen | Standaard op Dataverse-rollen gebaseerde beveiliging. | Niet-Power Fx-opdrachten gebruiken standaard op Dataverse-rollen gebaseerde beveiliging. Power Fx-opdrachten vereisen momenteel dat de onderdelenbibliotheek voor opdrachten wordt gedeeld en een geschikte beveiligingsrol heeft. |
| Oplossings- en ALM-gedrag | Inconsistente en problematische oplossingsgelaagdheid, geen aanwezigheid in de oplossingsinterface. Veel standaardgedragingen van oplossingen worden niet ondersteund, zoals patches, segmentatie, oplossingsupgrades, beheerde eigenschappen en nog veel meer. | Standaard oplossingsgelaagdheid wordt centraal beheerd voor meerdere oplossingsobjecttypen binnen Dataverse. Aanwezig in oplossingsinterface. Alle standaard oplossingsgedragingen worden ondersteund. |
| Lokalisatie | Niet-standaard | Gestandaardiseerd via het exporteren en importeren van vertalingen voor de gehele oplossing. |
| Gegevensmodel | Complex. Geoptimaliseerd voor klassieke linten en bevatten veel eigenschappen die niet meer nodig zijn. | Eenvoudig, geoptimaliseerd voor de opdrachtbalken van de hedendaagse modelgestuurde apps. |
| Gebruik van JavaScript | Ja | Ja. Nu eenvoudiger. Opmerking: dezelfde JavaScript kan worden gebruikt voor klassieke en moderne opdrachten. |
| Aanpassing van kant-en-klare opdrachten | Ja | Opdrachten worden bewerkbaar in de opdrachtontwerper zodra ze zijn gemigreerd naar het moderne framework. |
| App-specifieke opdrachten | Nee | Ja. Het gebruik van de moderne opdrachtontwerper zorgt ervoor dat opdrachten alleen zichtbaar zijn binnen de geselecteerde app. |
| Tabelspecifieke opdrachten die worden weergegeven in alle apps die de tabel bevatten | Ja | Ja. Vereist het wijzigen van de definitie appaction in het oplossingsbestand. |
| Algemene opdrachten die worden weergegeven voor alle tabellen en apps voor de opgegeven opdrachtbalklocatie | Ja | Ja. Vereist het wijzigen van de definitie appaction in het oplossingsbestand. |
| Splitsknoppen, flyouts en groepen maken | Ja | Ja |
| Dynamisch een flyout vullen met code | Ja | Nee We raden aan om opdrachten declaratief te maken. |
| Algemene opdrachten voor toepassingskoppen aanpassen | Ja | Nee |
| Opdrachten aanpassen voor andere/ongebruikelijke of verouderde opdrachtbalklocaties | Ja | Nee |
| Een moderne stroom of werkstroom uitvoeren | Gebruik van JavaScript | Gebruik van JavaScript. Ook ondersteund bij gebruik van een aangepaste pagina. |
Vergelijking van klassieke en moderne zichtbaarheidsregels
Klassieke zichtbaarheidsregels hadden vaak een specifieke regel voor elk scenario. Met Power Fx vervangt een declaratieve functie veel klassieke regels. En het is veel gemakkelijker te gebruiken.
Klassieke zichtbaarheidsregels zullen overigens binnenkort ook worden ondersteund in moderne opdrachten. Er was echter ondersteuning voor klassieke regels nodig voor het betrouwbaar migreren van klassieke opdrachten naar modern opdrachtgebruik en het aanpassen van klassieke regels binnen de opdrachtontwerper wordt niet ondersteund. We raden u aan om in de toekomst Power Fx te gebruiken.
| Gebruiksscenario | Klassieke regel | Klassieke opties | Zichtbare Power Fx-eigenschap |
|---|---|---|---|
| Weergeven/verbergen op basis van gegevenswaarde(n) | CustomRule | Gebruik van JavaScript | !IsBlank(Self.Selected.Item.Email) |
| Weergeven/verbergen op basis van tabelmachtiging | EntityPrivilegeRule | Meerdere | DataSourceInfo() |
| Weergeven/verbergen op basis van recordmachtiging | RecordPrivilegeRule | Meerdere | RecordInfo() |
| Verwijzen naar de besturingscontext voor primaire en gerelateerde tabellen | EntityRule | PrimaryEntity. SelectedEntity | Self.Selected |
| Verwijzen naar de besturingscontext | EntityRule | Form. HomePageGrid. SubGridStandard. SubGridAssociated | Self.Selected |
| Eigenschappen van metagegevens voor tabellen | EntityPropertyRule | DataSourceInfo() | |
| Weergeven/verbergen op basis van formulierstatus. Bijvoorbeeld weergeven voor het aanmaakformulier | FormStateRule | Create. Existing. ReadOnly. Disabled. BulkEdit | Self.Selected.State = FormMode.New |
| Weergeven wanneer > 1 record is geselecteerd in een raster | SelectionCountRule | CountRows(Self.Selected.Items) > 1 | |
| Weergeven/verbergen voor een gerelateerde tabel in een polymorfe opzoekactie. Bijvoorbeeld controleren of de opzoekactie een gebruiker OF een team is | CustomRule | PrimaryEntityTypeCode | IsType(), AsType |
| Verwijzen naar omgevingseigenschappen (Org) | CustomRule | OrgName. OrgLcid. UserLcid | Momenteel niet beschikbaar |
Veelgestelde vragen
- Waarom zie ik meer opdrachten in de ontwerper dan in mijn app?
- Er zijn verschillende redenen. Soms is er zichtbaarheidslogica die de opdracht verbergt wanneer de app wordt uitgevoerd. Andere keren worden deze opdrachten tijdens runtime dynamisch geïnjecteerd via aangepast JavaScript en zijn ze niet configureerbaar.
- Waarom zie ik dubbele opdrachten in de ontwerper?
- Dit was een veelvoorkomend patroon bij klassieke opdrachten. Beide opdrachten werden niet weergegeven tijdens runtime omdat ze werden beheerd door zichtbaarheidsregels. De opdrachtontwerper toont alle opdrachten, ongeacht hun zichtbaarheidsregels.
Zie ook
De opdrachtbalk aanpassen met de opdrachtontwerper
Opdrachten beheren in oplossingen
Bekende beperkingen voor modern opdrachtgebruik