From ad11b79ac0b4718f867d7b811cb8ce30c8cc4ca7 Mon Sep 17 00:00:00 2001 From: Ole Martin Handeland Date: Fri, 20 Dec 2024 10:32:40 +0100 Subject: [PATCH 1/5] Some fixes from review --- .../guides/development/options/_index.en.md | 26 ++++++++++--------- .../guides/development/options/_index.nb.md | 19 +++++++------- .../automatic-cleanup/_index.en.md | 11 ++++---- .../automatic-cleanup/_index.nb.md | 9 ++++--- .../options/sources/static/_index.en.md | 2 +- 5 files changed, 36 insertions(+), 31 deletions(-) diff --git a/content/altinn-studio/guides/development/options/_index.en.md b/content/altinn-studio/guides/development/options/_index.en.md index 0cc3c482e8..e0981ee6ee 100644 --- a/content/altinn-studio/guides/development/options/_index.en.md +++ b/content/altinn-studio/guides/development/options/_index.en.md @@ -10,17 +10,17 @@ aliases: --- Several of the form components in Altinn 3 use options. By options, we mean a list of choices that can be selected by -the user. In the most basic use-cases you might [set up a list of options directly in the component configuration](sources/static), +the user. In the most basic use cases you might [set up a list of options directly in the component configuration](sources/static), but often you'll want to fetch the options from a _code list_. ### Terms There are subtle differences between the terms _options_ and _code lists_: -- **Options**: A list of choices that can be selected by the user. Think of the contacts in your phone. When you use - your contact list to dial someone, you are selecting from a list of options, and your phone uses the selected value - (the phone number) to dial the person. -- **Code list**: A list of codes and their corresponding value and texts. Think of +- **Options**: A list of choices that can be selected by the user. As an example, think of the contacts in your phone. When you use + your contact list to call someone, you are selecting from a list of options, and your phone uses the selected value + (the phone number) to call the person. +- **Code list**: A list of codes and their corresponding value and texts. This can for example be the [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) country codes. This list contains codes (like `NO` or `SE`) and their corresponding labels (like `Norway` or `Sweden`). @@ -33,14 +33,16 @@ The following components support options: | Component | Type | Use case | |-------------------------------------------------------------------------|-----------------------|----------------------------------------------------------------------------------------------------| -| [Dropdown](../../../reference/ux/components/dropdown) | Single choice | Used to select a single option from a dropdown list | -| [RadioButtons](../../../reference/ux/components/radiobuttons) | Single choice | Used to select a single option from a list of radio buttons | -| [List](../../../reference/ux/components/listcomponent) | Single choice | Used to select a single option from a list/table (with one radio button per row) | +| [Dropdown](../../../reference/ux/components/dropdown) | Single choice | Used to select a single option from a dropdown list. | +| [RadioButtons](../../../reference/ux/components/radiobuttons) | Single choice | Used to select a single option from a list of radio buttons. | +| [List](../../../reference/ux/components/listcomponent) | Single choice | Used to select a single option from a list/table (with one radio button per row). | | [Likert](../../../reference/ux/components/likert) | Single choice per row | Used to select a single option per row in a table, displayed as a scale. Commonly used in surveys. | -| [Checkboxes](../../../reference/ux/components/checkboxes) | Multiple choice | Used to select one or more options from a list of checkboxes | -| [MultipleSelect](../../../reference/ux/components/multipleselect) | Multiple choice | Used to select one or more options from a dropdown list | -| [FileUploadWithTag](../../../reference/ux/components/fileuploadwithtag) | Single choice | Used to upload a file and tag it with an option | +| [Checkboxes](../../../reference/ux/components/checkboxes) | Multiple choice | Used to select one or more options from a list of checkboxes. | +| [MultipleSelect](../../../reference/ux/components/multipleselect) | Multiple choice | Used to select one or more options from a dropdown list. | +| [FileUploadWithTag](../../../reference/ux/components/fileuploadwithtag) | Single choice | Used to upload a file and tag it with an option. | -In the categories below, you can learn more about how to produce a list of options, configure that option list to be used in a component, as well as common functionality supported across these components. +In the categories below, you can learn more about how to produce a code list, configure that list to be used in a +component in order to provide options in that component, as well as common functionality across +the previously mentioned components that support options. {{}} diff --git a/content/altinn-studio/guides/development/options/_index.nb.md b/content/altinn-studio/guides/development/options/_index.nb.md index 59d5f13320..0ffe55745c 100644 --- a/content/altinn-studio/guides/development/options/_index.nb.md +++ b/content/altinn-studio/guides/development/options/_index.nb.md @@ -18,10 +18,10 @@ men ofte kommer svaralternativene til å hentes fra en _kodeliste_. Det er noen små forskjeller mellom begrepene _svaralternativer_ og _kodelister_: -- **Svaralternativer**: En liste med valg som kan velges av brukeren. Tenk på kontaktene i telefonen din. Når du bruker +- **Svaralternativer**: En liste med valg som kan velges av brukeren. For eksempel, tenk på kontaktene i telefonen din. Når du bruker kontaktlisten din for å ringe noen, velger du fra en liste med svaralternativer, og telefonen din bruker den valgte verdien (telefonnummeret) for å ringe personen. -- **Kodeliste**: En liste med koder og deres tilhørende verdier og tekster. Tenk på +- **Kodeliste**: En liste med koder og deres tilhørende verdier og tekster. Som et eksempel, tenk på [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) landskoder. Denne listen inneholder koder (som `NO` eller `SE`) og deres tilhørende ledetekst (som `Norge` eller `Sverige`). @@ -34,14 +34,15 @@ Følgende komponenter støtter svaralternativer: | Komponent | Type | Bruksområde | |-------------------------------------------------------------------------|------------------|---------------------------------------------------------------------------------------------------------| -| [Dropdown](../../../reference/ux/components/dropdown) | Ett valg | Brukes for å velge ett alternativ fra en nedtrekksliste | -| [RadioButtons](../../../reference/ux/components/radiobuttons) | Ett valg | Brukes for å velge ett alternativ fra en liste med radioknapper | -| [List](../../../reference/ux/components/listcomponent) | Ett valg | Brukes for å velge ett alternativ fra en liste/tabell (med en radioknapp per rad) | +| [Dropdown](../../../reference/ux/components/dropdown) | Ett valg | Brukes for å velge ett alternativ fra en nedtrekksliste. | +| [RadioButtons](../../../reference/ux/components/radiobuttons) | Ett valg | Brukes for å velge ett alternativ fra en liste med radioknapper. | +| [List](../../../reference/ux/components/listcomponent) | Ett valg | Brukes for å velge ett alternativ fra en liste/tabell (med en radioknapp per rad). | | [Likert](../../../reference/ux/components/likert) | Ett valg per rad | Brukes for å velge ett alternativ per rad i en tabell, vist som en skala. Vanlig i spørreundersøkelser. | -| [Checkboxes](../../../reference/ux/components/checkboxes) | Flere valg | Brukes for å velge ett eller flere alternativer fra en liste med avkrysningsbokser | -| [MultipleSelect](../../../reference/ux/components/multipleselect) | Flere valg | Brukes for å velge ett eller flere alternativer fra en nedtrekksliste | -| [FileUploadWithTag](../../../reference/ux/components/fileuploadwithtag) | Ett valg | Brukes for å laste opp en fil og knytte den til en 'tag'/merkelapp | +| [Checkboxes](../../../reference/ux/components/checkboxes) | Flere valg | Brukes for å velge ett eller flere alternativer fra en liste med avkrysningsbokser. | +| [MultipleSelect](../../../reference/ux/components/multipleselect) | Flere valg | Brukes for å velge ett eller flere alternativer fra en nedtrekksliste. | +| [FileUploadWithTag](../../../reference/ux/components/fileuploadwithtag) | Ett valg | Brukes for å laste opp en fil og knytte den til en 'tag'/merkelapp. | -I kategoriene under kan du lære mer om hvordan du produserer en liste med svaralternativer, kobler den til en komponent, samt om felles funkjsonalitet som kan brukes på tvers av disse komponentene. +I kategoriene under kan du lære mer om hvordan du produserer en kodeliste, kobler den til en komponent for å vise +frem svaralternativer, samt om felles funksjonalitet som kan brukes på tvers av disse komponentene. {{}} diff --git a/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.en.md b/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.en.md index cd5d05520d..2879487a3c 100644 --- a/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.en.md +++ b/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.en.md @@ -9,19 +9,20 @@ Some options for components may be dynamic. Either directly via [dynamic options where some values may be [filtered](../filtering) out. When the options are dynamic, the data model may contain values that are no longer valid. This can happen if the user -(or prefill) has selected an option that is no longer available. In such cases, to avoid the data model from containing -invalid values, unknown options are automatically removed from the data model. +(or prefill) has selected an option that is no longer available. In such cases, to prevent the data model from containing +invalid values, unknown options are automatically removed. ## How it works When the form is loaded, the options for all components are fetched and compared to their values in the data model. Even -if a component is not visible (i.e. when on a page that is not currently shown), the app-frontend will still +if a component is not visible (i.e. on a page that is not currently shown, _not_ when it's +actively hidden using the `hidden` property), the app-frontend will still check the options for that component and remove any values that are not in the options list. This has some implications that you should be aware of: - If you configure multiple components pointing to the same field in the data model, the options for all those components - should be the same. If they are not, the data model will be cleaned up to only contain the options that are valid for - all components. + should be the same. If they are not, the field in the data model will be adjusted to include only the options that + are valid for all components. - If the component is not marked as `required`, the user can submit the form even if the value is removed from the data model. If you want to ensure that the user selects a valid option, you should mark the component as required. diff --git a/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.nb.md b/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.nb.md index d90519997c..4fbda68fe9 100644 --- a/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.nb.md +++ b/content/altinn-studio/guides/development/options/functionality/automatic-cleanup/_index.nb.md @@ -10,17 +10,18 @@ hvor noen verdier kan være [filtrert](../filtering) bort. Når svaralternativene er dynamiske, kan datamodellen inneholde verdier som ikke lenger er gyldige. Dette kan skje hvis brukeren (eller forhåndsutfyllingen) har valgt et alternativ som ikke lenger er tilgjengelig. I slike tilfeller, for å -unngå at datamodellen inneholder ugyldige verdier, fjernes ukjente svaralternativer automatisk fra datamodellen. +forhindre at datamodellen inneholder ugyldige verdier, fjernes ukjente svaralternativer automatisk. ## Hvordan det fungerer Når skjemaet lastes, hentes svaralternativene for alle komponenter og sammenlignes med verdiene i datamodellen. Selv om -en komponent ikke er synlig (dvs. når på en side som for øyeblikket ikke vises), vil app-frontend fortsatt +en komponent ikke er synlig (her mener vi at den er på en side som for øyeblikket ikke +vises, _ikke_ at den er aktivt skjult via `hidden`-egenskapen), vil app-frontend fortsatt sjekke svaralternativene for den komponenten og fjerne eventuelle verdier som ikke er i svaralternativlisten. Dette har noen implikasjoner som du bør være klar over: - Hvis du konfigurerer flere komponenter som peker på det samme feltet i datamodellen, bør svaralternativene for alle - disse komponentene være de samme. Hvis de ikke er det, vil datamodellen ryddes opp for å kun inneholde de + disse komponentene være de samme. Hvis de ikke er det, vil feltet i datamodellen ryddes opp i slik at det kun inneholder de svaralternativene som er gyldige for alle komponentene. - Hvis komponenten ikke er merket som `required`, kan brukeren sende inn skjemaet selv om verdien fjernes fra datamodellen. Hvis du vil sikre at brukeren velger et gyldig alternativ, bør du merke komponenten som påkrevd. @@ -31,7 +32,7 @@ Dette har noen implikasjoner som du bør være klar over: dvs. når brukeren åpner skjemaet i en nettleser. - Automatisk opprydding skjer ikke når komponenten er merket som `hidden`. Derfor kan du også ha flere komponenter som peker på det samme feltet i datamodellen, hvor noen er skjulte og noen er synlige. I slike - tilfeller vil bare de synlige komponentene ha svaralternativene sjekket og ryddet opp. Dette er også tilfelle + tilfeller vil bare de synlige komponentene ha svaralternativene sjekket og ryddet opp. Dette er også tilfellet hvis en komponent er skjult fordi den er på en skjult side, eller inne i en annen skjult komponent. Begrepet 'skjult' i denne sammenhengen refererer til [dynamiske uttrykk](../../../dynamics) brukt for å skjule komponenter, ikke hvilke komponenter som for øyeblikket er synlige på siden. diff --git a/content/altinn-studio/guides/development/options/sources/static/_index.en.md b/content/altinn-studio/guides/development/options/sources/static/_index.en.md index 04a4ea0aff..fcbe5b7c07 100644 --- a/content/altinn-studio/guides/development/options/sources/static/_index.en.md +++ b/content/altinn-studio/guides/development/options/sources/static/_index.en.md @@ -8,7 +8,7 @@ aliases: - /altinn-studio/guides/development/options/static-codelists --- -For simpler use-cases, a static list of options or a simple code list is easy to configure. +For simpler use cases, a static list of options or a simple code list is easy to configure. These can either be set directly in the component configuration (in which case we call them options) or in a json file in the application repository (the simplest form for code lists). Which method to use depends on the need for reusability. If multiple components need to use the same set of options, it is recommended to From 010ae3590f33b707da9a00eb456d005a3f882dbd Mon Sep 17 00:00:00 2001 From: Ole Martin Handeland Date: Fri, 20 Dec 2024 10:47:16 +0100 Subject: [PATCH 2/5] More fixes from review --- .../options/functionality/data-binding/_index.en.md | 2 +- .../options/functionality/data-binding/_index.nb.md | 1 - .../options/functionality/filtering/_index.en.md | 11 ++++++----- .../options/functionality/filtering/_index.nb.md | 5 +++-- 4 files changed, 10 insertions(+), 9 deletions(-) diff --git a/content/altinn-studio/guides/development/options/functionality/data-binding/_index.en.md b/content/altinn-studio/guides/development/options/functionality/data-binding/_index.en.md index 0c6d1cf410..06b0751466 100644 --- a/content/altinn-studio/guides/development/options/functionality/data-binding/_index.en.md +++ b/content/altinn-studio/guides/development/options/functionality/data-binding/_index.en.md @@ -72,7 +72,7 @@ Components using options will usually only store the value of the selected optio usually sufficient, there are cases where you might want to store the label of the selected option as well. This can be useful for displaying the selected option in a simple presentation of the data without additional lookups or if you have a requirement to remember the label the user actually picked in case it has changed over time. When storing -the label in the data model, it will respect the users chosen language, look up the actual text from the text resources +the label in the data model, it will respect the user's chosen language, look up the actual text from the text resources and store the final value in the data model. This is configured by having a separate binding with the key `label`. The `label` binding should point to a field in the diff --git a/content/altinn-studio/guides/development/options/functionality/data-binding/_index.nb.md b/content/altinn-studio/guides/development/options/functionality/data-binding/_index.nb.md index 417794e6c1..335256aaad 100644 --- a/content/altinn-studio/guides/development/options/functionality/data-binding/_index.nb.md +++ b/content/altinn-studio/guides/development/options/functionality/data-binding/_index.nb.md @@ -117,4 +117,3 @@ datamodellen som inneholder en `string`-verdi: Denne konfigurasjonen vil nå lagre metadataen til de hentede svaralternativene som en kommaseparert streng i feltet `soknad.nyGaranti.loyvetypeMetadata` i datamodellen. -` \ No newline at end of file diff --git a/content/altinn-studio/guides/development/options/functionality/filtering/_index.en.md b/content/altinn-studio/guides/development/options/functionality/filtering/_index.en.md index 9223ac2022..2d1b2d4a70 100644 --- a/content/altinn-studio/guides/development/options/functionality/filtering/_index.en.md +++ b/content/altinn-studio/guides/development/options/functionality/filtering/_index.en.md @@ -21,14 +21,15 @@ Keep in mind that there are different approaches to making options dynamic: even when dynamic options based on query parameters would be problematic. Filtering options via the `optionFilter` property works with all of the above, and with -plain [static options](../../sources/static) as well. It makes it possible to use a [dynamic expression](../../../dynamics) +plain [static options](../../sources/static) as well. It allows you to use a [dynamic expression](../../../dynamics) to filter out options based on the current state of the form. ### Configuration In the example below, the `optionFilter` property is set to a dynamic expression that filters out the -option `should-be-removed`. Note that the `optionFilter` property accepts an expression for which options to keep, -so you should invert the logic to remove an option. +option `should-be-removed`. Note that the `optionFilter` property accepts an expression to determine which options +to keep. To remove an option, you should invert the logic. One way to do this is by writing the expression +inside a `not` function call. The expression is evaluated for each option, and if it returns `true`, the option is _kept_. All other options are _removed_. @@ -141,8 +142,8 @@ A few things to note about the configuration: equal to the data set in the current `Dropdown` component. {{% notice warning %}} -The example above relies on saving the form data to the backend and running data processing to update -the `UsedTypes` field. For this reason, it is still fully possible to select the same ingredient in multiple rows +The example above depends on saving the form data to the backend and running data processing to update +the `UsedTypes` field. For this reason, it is still entirely possible to select the same ingredient in multiple rows in the repeating group if you're fast enough. When using a method like this you should also [implement validation](../../../../../reference/logic/validation) to catch any duplicates that might slip through. {{% /notice %}} diff --git a/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md b/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md index 07ffa0e356..b246da8aa9 100644 --- a/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md +++ b/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md @@ -27,8 +27,9 @@ på den nåværende tilstanden i skjemaet. ### Konfigurasjon I eksempelet under er `optionFilter`-egenskapen satt til et dynamisk uttrykk som filtrerer ut alternativet -`should-be-removed`. Merk at `optionFilter`-egenskapen settes opp med et uttrykk for hvilke alternativer som skal beholdes, -så du må snu om logikken for å fjerne et alternativ. +`should-be-removed`. Merk at `optionFilter`-egenskapen settes opp med et uttrykk som bestemmer hvilke alternativer som +skal beholdes. Om du vil fjerne alternativer, må du snu om logikken. Dette kan for eksempel gjøres ved å pakke inn +hele uttrykket i en `not`-funksjon. Uttrykket evalueres for hvert svaralternativ, og hvis det returnerer `true`, beholdes alternativet. Alle andre alternativer fjernes. From 12781393fd32ed4174614c90eade21b0e9bc6902 Mon Sep 17 00:00:00 2001 From: Ole Martin Handeland Date: Fri, 20 Dec 2024 12:56:27 +0100 Subject: [PATCH 3/5] More fixes from review --- .../functionality/filtering/_index.nb.md | 10 +++++----- .../functionality/preselection/_index.en.md | 4 ++-- .../functionality/preselection/_index.nb.md | 17 +++++++++-------- .../options/functionality/sorting/_index.en.md | 2 +- .../options/functionality/texts/_index.nb.md | 2 +- .../options/sources/dynamic/_index.en.md | 15 ++++++++------- .../options/sources/dynamic/_index.nb.md | 14 +++++++------- .../sources/from-data-model/_index.en.md | 2 +- 8 files changed, 34 insertions(+), 32 deletions(-) diff --git a/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md b/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md index b246da8aa9..18c8d6ff70 100644 --- a/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md +++ b/content/altinn-studio/guides/development/options/functionality/filtering/_index.nb.md @@ -9,7 +9,7 @@ alternativer brukeren kan velge mellom. Legg merke til at det allerede finnes flere måter å gjøre svaralternativene dynamiske på: -1. Du kan bruke [dynamikk](../../../dynamics) for å skjule og vise helt forskjellige komponenter basert på en betingelse. Disse +1. Ved å bruke [dynamikk](../../../dynamics) for å skjule og vise helt forskjellige komponenter basert på en betingelse. Disse komponentene kan være bundet til samme sted i datamodellen, men ha forskjellige svaralternativer. Merk at [automatisk opprydding](../automatic-cleanup) kan fjerne verdier fra datamodellen når du bruker denne metoden. 2. Ved å bruke [dynamiske alternativer](../../sources/dynamic) og sende spørringsparametre til backenden, kan du skrive @@ -19,15 +19,15 @@ Legg merke til at det allerede finnes flere måter å gjøre svaralternativene d med data prosessering på backenden, kan dette være en kraftig måte å lage egendefinerte svaralternativer på, selv når dynamiske alternativer basert på spørringsparametre ville være problematisk. -Filtrering av svaralternativer via `optionFilter`-egenskapen fungerer med alle de nevnte metodene, og med -vanlige [statiske svaralternativer](../../sources/static) også. +Filtrering av svaralternativer via `optionFilter`-egenskapen fungerer med alle de nevnte metodene, inkludert +[statiske svaralternativer](../../sources/static). Dette gjør det mulig å bruke et [dynamisk uttrykk](../../../dynamics) for å filtrere ut svaralternativer basert på den nåværende tilstanden i skjemaet. ### Konfigurasjon I eksempelet under er `optionFilter`-egenskapen satt til et dynamisk uttrykk som filtrerer ut alternativet -`should-be-removed`. Merk at `optionFilter`-egenskapen settes opp med et uttrykk som bestemmer hvilke alternativer som +`should-be-removed`. Merk at `optionFilter`-egenskapen bruker et uttrykk for å bestemme hvilke alternativer som skal beholdes. Om du vil fjerne alternativer, må du snu om logikken. Dette kan for eksempel gjøres ved å pakke inn hele uttrykket i en `not`-funksjon. @@ -134,7 +134,7 @@ Konfigurasjonen for dette eksempelet er som følger: Noen ting å merke seg om konfigurasjonen: -1. De allerede brukte ingrediens-typene lagres i en komma-separert liste i feltet `UsedTypes` i datamodellen. Dette feltet +1. De allerede brukte ingredienstypene lagres i en kommaseparert liste i feltet `UsedTypes` i datamodellen. Dette feltet oppdateres ved hjelp av [dataprosessering](../../../../../reference/logic/dataprocessing) som finner alle unike ingredienstyper i `Ingredients`-lista. 2. Hvis vi bare sjekket `UsedTypes`-feltet mot `value`-verdien til den nåværende `Dropdown`-komponenten, ville alternativet diff --git a/content/altinn-studio/guides/development/options/functionality/preselection/_index.en.md b/content/altinn-studio/guides/development/options/functionality/preselection/_index.en.md index a04e66517c..3fc77b1fe2 100644 --- a/content/altinn-studio/guides/development/options/functionality/preselection/_index.en.md +++ b/content/altinn-studio/guides/development/options/functionality/preselection/_index.en.md @@ -19,7 +19,7 @@ In some cases it is desirable that one of the options is pre-selected. There are ### The `preselectedOptionIndex` property {{% notice info %}} -This property is available for most components support options, with the notable exception of the `FileUploadWithTag` +This property is available for most components that support options, with the notable exception of the `FileUploadWithTag` component. Only one option can be pre-selected at this time, and it is not possible to choose which option should be pre-selected based on the value property of the option. {{% /notice %}} @@ -54,7 +54,7 @@ This functionality follows a set of rules: component is visible on the screen or not. 4. Pre-selected values are not set for components that are hidden using [dynamics](../../../dynamics). If the component is shown again later, the pre-selection may be set. -5. The preselected option is determined before [sorting](../sorting) is applied, but after [filtering](../filtering). +5. The preselected option is determined after [filtering](../filtering), but before [sorting](../sorting) is applied. {{% notice warning %}} There are situations where pre-selection with this property is not optimal, and can lead to situations that may be diff --git a/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md b/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md index 164db237c8..bfb8a37000 100644 --- a/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md +++ b/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md @@ -19,12 +19,12 @@ Noen ganger er det ønskelig at et av svaralternativene er forhåndsvalgt. Det f ### `preselectedOptionIndex`-egenskapen {{% notice info %}} -Denne egenskapen er tilgjengelig for de fleste komponenter som støtter svaralternativer, med unntak av `FileUploadWithTag` -komponenten. Kun ett alternativ kan være forhåndsvalgt til enhver tid, og det er ikke mulig å velge hvilket alternativ -som skal være forhåndsvalgt basert på `value`-egenskapen til alternativet. +Denne egenskapen er tilgjengelig for de fleste komponenter som støtter svaralternativer, med unntak +av `FileUploadWithTag`-komponenten. Kun ett alternativ kan være forhåndsvalgt til enhver tid, og det er ikke mulig +å velge hvilket alternativ som skal være forhåndsvalgt basert på `value`-egenskapen til alternativet. {{% /notice %}} -Denne egenskapen lar deg velge et svaralternativ som forhåndsvalgt. Den tar et heltall som argument, som er indeksen +Med denne egenskapen kan du forhåndsvelge et svaralternativ. Den tar et heltall som argument, som er indeksen til svaralternativet som skal være forhåndsvalgt. Indeksen starter på 0 for det første svaralternativet, 1 for det andre osv. @@ -55,19 +55,20 @@ Denne funksjonaliteten følger et sett med regler: på skjermen eller ikke. 4. Forhåndsvalgte verdier blir ikke satt for komponenter som er skjult ved hjelp av [dynamikk](../../../dynamics). Om komponenten senere blir vist igjen, vil forhåndsvalget kunne bli satt. -5. Det forhåndsvalgte alternativet blir bestemt før [sortering](../sorting) blir utført, men etter [filtrering](../filtering). +5. Det forhåndsvalgte alternativet blir bestemt etter [filtrering](../filtering), men før [sortering](../sorting) blir + utført. {{% notice warning %}} Det finnes situasjoner hvor forhåndsvalg med denne egenskapen ikke er optimalt, og kan føre til situasjoner som kan oppleves som feil: -1. Dersom et alternativ blir valgt, brukeren velger det bort igjen, og laster skjemaet på nytt senere vil forhåndsvalget +1. Dersom et alternativ blir valgt, brukeren velger det bort igjen, og så laster skjemaet på nytt senere, vil forhåndsvalget bli satt igjen - selv om komponenten er på en side lenge før den brukeren ser på, og ikke vil se igjen. 2. Når skjemaet sendes inn via API-et vil forhåndsvalg satt med denne egenskapen ikke ha noen effekt. Denne egenskapen krever at skjemaet er åpent i nettleseren for å fungere. -3. Om skjemaet er i en tilstand hvor datamodellen ikke er skrivbar (f.eks. i PDF-generatoren), vil potensielt - setting av forhåndsvalgte verdier kunne føre til feilmeldinger og mislykket innsending dersom datamodellen ikke +3. Om skjemaet er i en tilstand hvor datamodellen ikke er skrivbar (f.eks. i PDF-generatoren), vil forhåndsvalget ikke + setting av forhåndsvalgte verdier potensielt føre til feilmeldinger og mislykket innsending dersom datamodellen ikke allerede hadde en verdi. Av disse grunnene anbefales det å bruke denne egenskapen med forsiktighet, og å vurdere et av de andre alternativene diff --git a/content/altinn-studio/guides/development/options/functionality/sorting/_index.en.md b/content/altinn-studio/guides/development/options/functionality/sorting/_index.en.md index c8710df0bb..4a1374c4f4 100644 --- a/content/altinn-studio/guides/development/options/functionality/sorting/_index.en.md +++ b/content/altinn-studio/guides/development/options/functionality/sorting/_index.en.md @@ -4,7 +4,7 @@ description: Sorting the options in the list weight: 300 --- -Options are usually displayed in the order they are defined in, but it is also possible to sort them alphabetically by +Options are usually displayed in the order they are defined, but it is also possible to sort them alphabetically by label. This can be useful to make it easier for the user to find the option they are looking for when the list does not need to be in a specific order. diff --git a/content/altinn-studio/guides/development/options/functionality/texts/_index.nb.md b/content/altinn-studio/guides/development/options/functionality/texts/_index.nb.md index 8c1bf2c5b2..0c2b219b0a 100644 --- a/content/altinn-studio/guides/development/options/functionality/texts/_index.nb.md +++ b/content/altinn-studio/guides/development/options/functionality/texts/_index.nb.md @@ -6,7 +6,7 @@ weight: 150 ## Ledetekst -Den vanligste tekstegenskapen for svaralternativer er `label`. `label` er teksten som vises for brukeren i +Den vanligste tekstegenskapen for svaralternativer er `label` (ledetekst). Dette er teksten som vises for brukeren i brukergrensesnittet (i motsetning til `value`, som er [verdien som lagres i datamodellen](../data-binding)). Både `label` og `value` er påkrevde egenskaper for et svaralternativ. diff --git a/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md b/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md index de72037596..422b9176a0 100644 --- a/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md +++ b/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md @@ -53,13 +53,13 @@ namespace Altinn.App.Core } ``` -For your implementation to be picked up you need to add the following line in your `Program.cs`: +For your implementation to work up you need to add the following line in your `Program.cs`: ```C# services.AddTransient(); ``` -The result of this implementation will be available at the endpoint `{org}/{app}/api/options/countries`. The identifier can be used in components, so to use the code list in a Dropdown component you can set `optionsId` as in the following example: +The result of this implementation will be available at the endpoint `{org}/{app}/api/options/countries`. The identifier can be used in components, so to use the code list in a `Dropdown` component you can set `optionsId` as in the following example: ```json {hl_lines=[10]} { @@ -77,7 +77,8 @@ The result of this implementation will be available at the endpoint `{org}/{app} ### Secured code lists -If you want to produce lists of options that are sensitive you can implement `IInstanceAppOptionsProvider`, which will validate that the user has read rights as defined in the authorization policy from the `policy.xml`-file. +If you need to generate sensitive code lists, you can implement the `IInstanceAppOptionsProvider` interface. +This ensures that the user access is validated based on read rights defined in the authorization policy specified in the `policy.xml` file. Below you'll find an example of how to implement a secured options provider. ```C# @@ -127,13 +128,13 @@ namespace Altinn.App.Core ``` -For your implementation to be picked up you need to add the following line in your `Program.cs`: +For your implementation to work up you need to add the following line in your `Program.cs`: ```csharp services.AddTransient(); ``` -The result of this implementation will be available at the endpoint `{org}/{app}/instances/{instanceOwnerId}/{instanceGUID}/options/children`. The identifier can be used in components, so to use the code list in a Dropdown component you can set `optionsId` as in the following example. It is also important to set the `secure` property to `true` to indicate that this is a secured code list. +The result of this implementation will be available at the endpoint `{org}/{app}/instances/{instanceOwnerId}/{instanceGUID}/options/children`. The identifier can be used in components, so to use the code list in a `Dropdown` component you can set `optionsId` as in the following example. It is also important to set the `secure` property to `true` to indicate that this is a secured code list. ```json {hl_lines=["10-11"]} { @@ -190,7 +191,7 @@ More examples of expressions can be found in the [dynamics documentation](../../ ### Based on the data model {{%notice warning%}} -This approach is discouraged. From app-frontend version 4.9.0, it is possible to use the `queryParameters` property instead. As described above, this property allows you to add both static and dynamic query parameters using expressions, making them more flexible than `mapping`. +This approach is discouraged. From app-frontend version 4.9.0, it is possible to use the `queryParameters` property instead. As explained above, `queryParameters` enabled you to include both static and dynamic query parameters through expressions, offering greater flexibility compared to `mapping`. At some point, the `mapping` property will be removed, but when that happens tools will be provided to migrate existing configurations to use `queryParameters` instead. {{% /notice%}} @@ -265,7 +266,7 @@ For a complete example of how this is setup see our [demo app.](https://altinn.s ## Things to consider -- The method `GetAppOptionsAsync` receives a language code in the `language` parameter. Language codes are based on ISO 639-1 or the W3C IANA Language Subtag Registry. The latter is built upon the ISO 639-1 standard but is guaranties uniques of the codes, whereas ISO 639-1 have conflicting usage for some codes. +- The `GetAppOptionsAsync` method accepts a language code through the `language` parameter. Language codes follow either the ISO 639-1 standard or the W3C IANA Language Subtag Registry. While ISO 639-1 may have conflicting usages for certain codes, the W3C IANA registry builds on ISO 639-1 and ensures the uniqueness of its codes. - An app can have many implementations of these interfaces, one for each option list. The correct implementation is found by looking at the code list identifier that is requested, and comparing it to the `Id` property in the implementation. This is also the identifier used in the `optionsId` property in the component configuration. Therefore, the `Id` property in the implementation must be unique per app. - It may be tempting to implement a dynamic option list that fetches data from the data model and produces the option list based on this. This is not recommended, as the app frontend only fetches the option list once for each unique set of query parameters. This means that the user interface showing the option list will not update in line with changes in the data model. - An alternative is to use the functionality for [dynamic code lists based on the data model](../from-data-model), in some cases together with corresponding code in [DataProcessor](../../../../../reference/logic/dataprocessing). diff --git a/content/altinn-studio/guides/development/options/sources/dynamic/_index.nb.md b/content/altinn-studio/guides/development/options/sources/dynamic/_index.nb.md index dcb9da9ad7..555863e64c 100644 --- a/content/altinn-studio/guides/development/options/sources/dynamic/_index.nb.md +++ b/content/altinn-studio/guides/development/options/sources/dynamic/_index.nb.md @@ -8,9 +8,9 @@ aliases: - /nb/altinn-studio/guides/development/options/dynamic-codelists --- -I en Altinn 3 app har man også mulighet til å ha dynamisk kodelister som produseres dynamisk ved kjøring av appen. Dette gjør det mulig å lage dynamiske verdier, for eksempel ved å hente og filtrere verdier fra andre kilder. Dynamiske kodelister kan enten være åpne (tilgjengelig for alle, uten autentisering), eller sikret slik at brukeren må ha tilgang til instansen for å hente kodelisten. +I en Altinn 3 app har man også mulighet til å ha dynamiske kodelister som blir fortløpende generert ved kjøring av appen. Dette gjør det mulig å lage dynamiske verdier, for eksempel ved å hente og filtrere verdier fra andre kilder. Dynamiske kodelister kan enten være åpne (tilgjengelig for alle, uten autentisering), eller sikret slik at brukeren må ha tilgang til instansen for å hente kodelisten. -For åpne kodelister implementerer man `IAppOptionsProvider` interfacet, mens for sikrede kodelister implementerer man `IInstanceAppOptionsProvider`. Fremgangsmåten er den samme for begge og modellen som returneres er lik. Implementeringen holdes adskilt for ikke å eksponere verdier som skulle vært sikret. +For åpne kodelister implementerer man `IAppOptionsProvider` interfacet, mens for sikrede kodelister implementerer man `IInstanceAppOptionsProvider`. Fremgangsmåten er den samme for begge og modellen som returneres er lik. Implementeringen holdes adskilt for ikke å eksponere kodelister som skulle vært sikret. ## Åpne kodelister @@ -59,7 +59,7 @@ For at denne implementasjonen skal plukkes opp av applikasjonen må den registre services.AddTransient(); ``` -Resultatet av denne implementasjonen vil bli tilgjengeleg på endepunktet `{org}/{app}/api/options/countries`. Identifikatoren kan brukes i komponenter, så for å bruke kodelisten i en Dropdown-komponent kan man sette `optionsId` som i følgende eksempel: +Resultatet av denne implementasjonen vil bli tilgjengeleg på endepunktet `{org}/{app}/api/options/countries`. Identifikatoren kan brukes i komponenter, så for å bruke kodelisten i en `Dropdown`-komponent kan man sette `optionsId` som i følgende eksempel: ```json {hl_lines=[10]} { @@ -77,7 +77,7 @@ Resultatet av denne implementasjonen vil bli tilgjengeleg på endepunktet `{org} ## Sikrede kodelister -Om du ønsker å produsere kodelister som inneholder sensitive data som ikke skal være tilgjengelige i et åpent API kan man implementere `IInstanceAppOptionsProvider`. Slike sikrede kodelister kontrollerer at brukeren har lesetilgang som definert i applikasjonens `policy.xaml`-fil før brukeren kan hente innholdet i kodelisten. +Om du ønsker å produsere kodelister som inneholder sensitive data som ikke skal være tilgjengelige i et åpent API kan man implementere `IInstanceAppOptionsProvider`. Slike sikrede kodelister kontrollerer at brukeren har lesetilgang som definert i applikasjonens `policy.xml`-fil før brukeren kan hente innholdet i kodelisten. Under finner du et eksempel på hvordan man setter opp en sikret kodeliste. ```C# @@ -133,7 +133,7 @@ For at denne implementasjonen skal plukkes opp av applikasjonen må den registre services.AddTransient(); ``` -Resultatet av denne implementasjonen vil bli tilgjengeleg på endepunktet `{org}/{app}/instances/{instanceOwnerId}/{instanceGUID}/options/children`. Identifikatoren kan brukes i komponenter, så for å bruke kodelisten i en Dropdown-komponent kan man sette `optionsId` som i følgende eksempel. Det er også viktig å sette `secure`-egenskapen til `true` for å indikere at dette er en sikret kodeliste. +Resultatet av denne implementasjonen vil bli tilgjengeleg på endepunktet `{org}/{app}/instances/{instanceOwnerId}/{instanceGUID}/options/children`. Identifikatoren kan brukes i komponenter, så for å bruke kodelisten i en `Dropdown`-komponent kan man sette `optionsId` som i følgende eksempel. Det er også viktig å sette `secure`-egenskapen til `true` for å indikere at dette er en sikret kodeliste. ```json {hl_lines=["10-11"]} { @@ -266,7 +266,7 @@ For et komplett eksempel kan du se vår [demo app.](https://altinn.studio/repos/ - Metoden `GetAppOptionsAsync` får inn en språkkode i parameteren `language`. Språkkoder bør baseres på ISO 639-1 standarden eller W3C IANA Language Subtag Registry standarden. Sistnevnte bygger på ISO 639-1 standarden men garanterer at alle kodene er unike, noe ISO 639-1 ikke gjør. - En app kan ha mange implementasjoner av disse interfacene, en for hver kodeliste. Den rette implementasjonen finnes gjennom å se på hvilken kodeliste-identifikator det spørres etter, og sammenlignes med `Id`-egenskapen i implementasjonen. Dette er også identifikatoren som brukes i `optionsId`-egenskapen i komponentkonfigurasjonen. Dermed må også `Id`-egenskapen i implementasjonen være unik per app. -- Det kan være fristende å sette opp en dynamisk og sikret kodeliste hvor man henter ut data fra datamodellen og produserer kodelisten basert på dette. Dette er ikke anbefalt, da appens frontend bare henter kodelisten en gang hvor hvert unike sett med spørringsparametre. Det betyr at visningen av kodelisten ikke vil oppdatere seg i tråd med endringene i datamodellen. +- Det kan være fristende å sette opp en dynamisk og sikret kodeliste hvor man henter ut data fra datamodellen og produserer kodelisten basert på dette. Dette er ikke anbefalt, da appens frontend bare henter kodelisten én gang for hvert unike sett med spørringsparametre. Det betyr at visningen av kodelisten ikke vil oppdatere seg i tråd med endringene i datamodellen. - Et alternativ er å bruke funksjonaliteten for [dynamiske kodelister basert på datamodell](../from-data-model), i noen tilfeller sammen med tilsvarende kode i [DataProcessor](../../../../../reference/logic/dataprocessing). - Et annet alternativ kan være å bruke spørringsparametre, som beskrevet over. -- Dersom man bruker spørringsparametre, kan det være lurt å tenke gjennom hvor mange unike kombinasjoner av parametre som typisk vil bli brukt i appen. Hvis det er mange, kan det være lurt å vurdere å bruke en annen tilnærming, som for eksempel å hente ut all data og filtrere gyldige verdier i frontend ved hjelp av [`optionFilter`](../../functionality/filtering). Mange ulike kombinasjoner av spørringsparametre kan før til at appen må gjøre mye unødvendig arbeid for å hente nye kodeliste-verdier hver gang brukeren gjør en endring i skjemaet. \ No newline at end of file +- Dersom man bruker spørringsparametre kan det være lurt å tenke gjennom hvor mange unike kombinasjoner av parametre som typisk vil bli brukt i appen. Hvis det er mange, kan det være lurt å vurdere å bruke en annen tilnærming, som for eksempel å hente ut all data og filtrere gyldige alternativer i frontend ved hjelp av [`optionFilter`](../../functionality/filtering). Mange ulike kombinasjoner av spørringsparametre kan føre til at appen må gjøre mye unødvendig arbeid for å hente kodelisten på nytt hver gang brukeren gjør en endring i skjemaet. \ No newline at end of file diff --git a/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md b/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md index 6e816ee16c..0f8ecb68be 100644 --- a/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md +++ b/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md @@ -7,7 +7,7 @@ aliases: - /altinn-studio/guides/development/options/repeating-group-codelists --- -In the previous section about [dynamic code lists](../dynamic) we covered how to write code on the backend to generate a dynamic code list for a component. You could use pass certain values from the data model to the backend to generate that code list (via [query parameters](../dynamic#query-parameters)), but that approach scales poorly when the query parameters would end up changing the code list frequently, i.e. when the options are functionally unique for some set of data in the data model. +In the previous section about [dynamic code lists](../dynamic) we covered how to write code on the backend to generate a dynamic code list for a component. You could pass certain values from the data model to the backend to generate that code list (via [query parameters](../dynamic#query-parameters)), but that approach scales poorly when the query parameters would end up changing the code list frequently, i.e. when the options are functionally unique for some set of data in the data model. Another approach is to set up a code list based on a 'repeating group' in the data model. Such a repeating object in the data model could also represent a list of options for a dropdown, radio buttons, or checkboxes. This is especially useful combined with the [RepeatingGroup](../../../../../reference/ux/fields/grouping/repeating) component, as it allows the user to add and remove items from the list, and the code list will automatically update. From 951b0ffdd7df4046e78a4e4df40f0e0473cda4b6 Mon Sep 17 00:00:00 2001 From: Ole Martin Handeland Date: Fri, 20 Dec 2024 13:12:09 +0100 Subject: [PATCH 4/5] More fixes from review --- .../options/sources/from-data-model/_index.en.md | 12 ++++++------ .../options/sources/from-data-model/_index.nb.md | 14 +++++++------- .../options/sources/shared/_index.nb.md | 4 ++-- .../options/sources/static/_index.en.md | 4 ++-- .../options/sources/static/_index.nb.md | 8 ++++---- 5 files changed, 21 insertions(+), 21 deletions(-) diff --git a/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md b/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md index 0f8ecb68be..ac20ac60ef 100644 --- a/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md +++ b/content/altinn-studio/guides/development/options/sources/from-data-model/_index.en.md @@ -9,7 +9,7 @@ aliases: In the previous section about [dynamic code lists](../dynamic) we covered how to write code on the backend to generate a dynamic code list for a component. You could pass certain values from the data model to the backend to generate that code list (via [query parameters](../dynamic#query-parameters)), but that approach scales poorly when the query parameters would end up changing the code list frequently, i.e. when the options are functionally unique for some set of data in the data model. -Another approach is to set up a code list based on a 'repeating group' in the data model. Such a repeating object in the data model could also represent a list of options for a dropdown, radio buttons, or checkboxes. This is especially useful combined with the [RepeatingGroup](../../../../../reference/ux/fields/grouping/repeating) component, as it allows the user to add and remove items from the list, and the code list will automatically update. +Another approach is to set up a code list based on a repeating structure (list of objects) in the data model. Such a repeating structure in the data model could also represent a list of options for a dropdown, radio buttons, or checkboxes. This is especially useful combined with the [RepeatingGroup](../../../../../reference/ux/fields/grouping/repeating) component, as it allows the user to add and remove items from the list, and the code list will automatically update. This functionality does not require the use of any `RepeatingGroup` component in the form layout, but it does require that the data model contains a repeating structure. @@ -33,13 +33,13 @@ This property contains the fields `group`, `label`, and `value`. Example: Explanation: -- **group** - the repeating group field in the data model to base the code list on -- **label** - a reference to a text id to be used as the label for each option, see more below. -- **value** - a reference to a field in the group that should be used as the option value. Notice that we set up a placeholder `[{0}]` that will be replaced with the index of the repeating element. +- `group` - the repeating group field in the data model to base the code list on. +- `label` - a reference to a text id to be used as the label for each option, see more below. +- `value` - a reference to a field in the group that should be used as the option value. Notice that we set up a placeholder `[{0}]` that will be replaced with the index of the repeating element. -The **value** field must be unique for each element. If the repeating group does not contain a field which is unique for each item it is recommended to add a field to the data model that can be used as identifier, for instance a GUID. Non-unique values will be filtered out from all code lists, so not choosing a unique value can make it seem like the code list is not being correctly populated. +The `value` field must be unique for each element. If the repeating group does not contain a field which is unique for each item it is recommended to add a field to the data model that can be used as identifier, for instance a GUID. Non-unique values will be filtered out from all code lists, so not choosing a unique value can make it seem like the code list is not being correctly populated. -As for the **label** property, you have to define a text resource that can be used as a label for each option. +As for the `label` property, you have to define a text resource that can be used as a label for each option. In the example below, other values from the repeating structure is used in the label via [variables in text](/altinn-studio/reference/ux/texts): ```json diff --git a/content/altinn-studio/guides/development/options/sources/from-data-model/_index.nb.md b/content/altinn-studio/guides/development/options/sources/from-data-model/_index.nb.md index 307d097311..6f7be7b6fd 100644 --- a/content/altinn-studio/guides/development/options/sources/from-data-model/_index.nb.md +++ b/content/altinn-studio/guides/development/options/sources/from-data-model/_index.nb.md @@ -9,9 +9,9 @@ aliases: I den forrige seksjonen om [dynamiske kodelister](../dynamic) beskrev vi hvordan man kan skrive kode på backend for å generere dynamiske kodelister. Du kunne også sende visse verdier fra datamodellen til backend for å generere denne kodelisten (via [spørringsparametre](../dynamic#spørringsparametre)). Denne fremgangsmåten skalerer dårlig når kodelisten ender opp med å endre alternativene ofte, dvs. når alternativene er funksjonelt unike for en del av dataene i datamodellen. -En annen tilnærming er å sette opp en kodeliste basert på en 'repeterende gruppe' i datamodellen. En slik repeterende struktur i datamodellen kan også representere en liste over alternativer for en nedtrekksliste, radioknapper eller avmerkingsbokser. Dette er spesielt nyttig i kombinasjon med [RepeatingGroup](../../../../../reference/ux/fields/grouping/repeating) komponenten, da det lar brukeren legge til og fjerne elementer fra listen, og alternativene vil automatisk oppdateres. +En annen tilnærming er å sette opp en kodeliste basert på en 'repeterende gruppe' i datamodellen. En slik repeterende struktur i datamodellen kan også representere en liste over alternativer for en nedtrekksliste, radioknapper eller avmerkingsbokser. Dette er spesielt nyttig i kombinasjon med [RepeatingGroup](../../../../../reference/ux/fields/grouping/repeating)-komponenten, da det lar brukeren legge til og fjerne elementer fra listen, og alternativene vil automatisk oppdateres. -Denne funksjonaliteten krever ikke bruk av noen `RepeatingGroup` komponent i skjemalayout, men det krever at datamodellen inneholder en repeterende struktur. +Denne funksjonaliteten krever ikke bruk av noen `RepeatingGroup`-komponent i layout-filen, men det krever at datamodellen inneholder en repeterende struktur. ### Konfigurasjon @@ -33,14 +33,14 @@ I dette objektet definerer man feltene `group`, `label` og `value`. Eksempel: Forklaring: -- **group** - den repeterende strukturen i datamodellen man baserer kodelisten på. -- **label** - en referanse til en tekstnøkkel som brukes som ledetekst for hvert svaralternativ. Se mer under. -- **value** - en referanse til det feltet i den repeterende strukturen som skal bruke som verdi, og dermed lagres når brukeren gjør et valg. Legg merke til at vi har fyllt inn `[{0}]` som vil bli erstattet med indeksen til det repeterende elementet. +- `group` - den repeterende strukturen i datamodellen man baserer kodelisten på. +- `label` - en referanse til en tekstnøkkel som brukes som ledetekst for hvert svaralternativ. Se mer under. +- `value` - en referanse til det feltet i den repeterende strukturen som skal bruke som verdi, og dermed lagres når brukeren gjør et valg. Legg merke til at vi har fyllt inn `[{0}]` som vil bli erstattet med indeksen til det repeterende elementet. -Verdien hentet ut fra **value** må være unikt for hvert repeterende element. Om man ikke har et felt som er unikt per rad, anbefales det å legge på et ekstra felt i datamodellen som kan benyttes som identifikator f.eks en GUID eller liknende. Dersom verdien ikke er unik vil den bli filtrert bort fra alle kodelister, og antallet svaralternativer tilgjengelige for brukeren kan da være noen færre enn forventet ut fra det som ligger i datamodellen. +Verdien hentet ut fra `value` må være unik for hvert repeterende element. Om man ikke har et felt som er unikt per rad, anbefales det å legge på et ekstra felt i datamodellen som kan benyttes som identifikator. For eksempel en GUID eller liknende. Dersom verdien ikke er unik vil den bli filtrert bort fra alle kodelister, og antallet svaralternativer tilgjengelige for brukeren kan da være noen færre enn forventet ut fra det som ligger i datamodellen. -For **label** feltet må vi definere en tekstressurs som kan bli brukt som ledetekst for hvert svaralternativ. +For `label`-feltet må vi definere en tekstressurs som kan bli brukt som ledetekst for hvert svaralternativ. I eksempelet under, brukes andre verdier fra den repeterende strukturen i ledeteksten via [variabler i tekst](/nb/altinn-studio/reference/ux/texts): ```json diff --git a/content/altinn-studio/guides/development/options/sources/shared/_index.nb.md b/content/altinn-studio/guides/development/options/sources/shared/_index.nb.md index 45c57c8582..5b47fa14e9 100644 --- a/content/altinn-studio/guides/development/options/sources/shared/_index.nb.md +++ b/content/altinn-studio/guides/development/options/sources/shared/_index.nb.md @@ -37,11 +37,11 @@ aliases: Ved å kalle denne metoden vil du registrere alle kodelistene på tvers av alle kilder. Du kan også registrere kodelistene én og én hvis du vil ha kontroll på hvilke kodelister som er tatt i bruk eller konfigurere og tilpasse oppsettet av kodelisten. ### 3. Koble applikasjonen din til kodeverket du ønsker å bruke - Se [dokuemntasjon](https://github.com/Altinn/codelists-lib-dotnet#available-codelists) nedenfor for tilgjengelige kodelister. + Se [dokumentasjon](https://github.com/Altinn/codelists-lib-dotnet#available-codelists) nedenfor for tilgjengelige kodelister. Du kan gjøre dette enten ved hjelp av [Altinn Studio](https://altinn.studio) og konfigurere *Kodeliste-ID* for komponenten din i brukergrensesnittet. - Eller du kan konfigurere komponenten ved å redigere egenskapen `optionsId` form komponenten i layout-filen. + Eller du kan konfigurere komponenten ved å redigere egenskapen `optionsId` på komponenten i layout-filen. ## Tilpasset konfigurasjon Mens konfigurasjonen nevnt ovenfor der du kaller `services.AddAltinnCodelists();` vil legge til alle tilgjengelige kodelister med standardverdier, kan det være tilfeller der du ønsker å tilpasse konfigurasjonen av en kodeliste. Eksemplene under vil variere noe avhengig av kilden til kodelisten siden de ulike kildene tilbyr ulike muligheter. diff --git a/content/altinn-studio/guides/development/options/sources/static/_index.en.md b/content/altinn-studio/guides/development/options/sources/static/_index.en.md index fcbe5b7c07..14db196be4 100644 --- a/content/altinn-studio/guides/development/options/sources/static/_index.en.md +++ b/content/altinn-studio/guides/development/options/sources/static/_index.en.md @@ -14,7 +14,7 @@ in the application repository (the simplest form for code lists). Which method t If multiple components need to use the same set of options, it is recommended to use the [json file method](#from-json-files-code-list) and thus turn it into a code list. -Note that even though a static list of options can be completely static, it is also possible to make it (a bit more) dynamic +Note that even though a list of options can be completely static, it is also possible to make it (a bit more) dynamic by [filtering the options](../../functionality/filtering) using expressions. If you want even more flexibility, you can also [create your own code-based code list](../dynamic). @@ -78,7 +78,7 @@ The static code lists should be in the format as shown below: ] ``` -Note that the `label` field can be a key to a text resource (as shown above for sweden) or plain text. +Note that the `label` property can be a key to a text resource (as shown above for sweden) or plain text. In order to reference this code list in a component, you can use the `optionsId` property in the component configuration: diff --git a/content/altinn-studio/guides/development/options/sources/static/_index.nb.md b/content/altinn-studio/guides/development/options/sources/static/_index.nb.md index 697d2961c1..ce3e1daf0e 100644 --- a/content/altinn-studio/guides/development/options/sources/static/_index.nb.md +++ b/content/altinn-studio/guides/development/options/sources/static/_index.nb.md @@ -12,10 +12,10 @@ For enklere brukstilfeller er statiske svaralternativer og kodelister det lettes i komponentkonfigurasjonen (dette kaller vi ofte svaralternativer) eller i en json-fil i app-repositoriet (den enkleste formen for kodeliste). Hvilken metode som bør brukes avhenger av gjenbruksbehovet. Hvis flere komponenter skal bruke de samme svaralternativene, anbefales det å -[putte kodelisten i en json-fil](#fra-json-filer-kodeliste) og dermed gjøre den om til en kodeliste. +[putte svaralternativene i en json-fil](#fra-json-filer-kodeliste) og dermed gjøre den om til en kodeliste. -Legg merke til at selv om slike svaralternativer kan være helt statisk, er det også mulig å gjøre dem (litt mer) dynamiske -ved å [filtrere svaralternativene](../../functionality/filtering) ved hjelp av et uttrykk. Ønsker du enda mer +Legg merke til at selv om slike svaralternativer kan være helt statiske, er det også mulig å gjøre dem (litt mer) dynamiske +ved å [filtrere svaralternativene](../../functionality/filtering) ved hjelp av uttrykk. Ønsker du enda mer fleksiilitet, kan du også [lage en egen kodebasert kodeliste](../dynamic). ## I komponentkonfigurasjonen (svaralternativer) @@ -51,7 +51,7 @@ lagret i datamodellen når brukeren velger elementet. Egenskapen `label` er lede ## Fra JSON-filer (kodeliste) -Ved å legge json-lister i `options`-mappen i app repo vil appen automatisk lese denne filen og eksponere det gjennom `options`-APIet. +Ved å legge json-lister i `options`-mappen i app-repositoriet vil appen automatisk lese denne filen og eksponere det gjennom `options`-API-et. Options filene må ligge under `App/options/`. Lager man f.eks `land.json`, kan man sette opp en komponent med egenskapen `"optionsId": "land"`. Kodelisten kan hentes fra API via endepunktet `{org}/{app}/api/options/land`. From 5a19ea2d0af1e8943eb7311370cc5052e7f5804c Mon Sep 17 00:00:00 2001 From: Ole Martin Handeland Date: Sat, 11 Jan 2025 12:05:10 +0100 Subject: [PATCH 5/5] Changes requested in review --- .../options/functionality/preselection/_index.nb.md | 2 +- .../guides/development/options/sources/dynamic/_index.en.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md b/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md index bfb8a37000..306cf78379 100644 --- a/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md +++ b/content/altinn-studio/guides/development/options/functionality/preselection/_index.nb.md @@ -67,7 +67,7 @@ situasjoner som kan oppleves som feil: bli satt igjen - selv om komponenten er på en side lenge før den brukeren ser på, og ikke vil se igjen. 2. Når skjemaet sendes inn via API-et vil forhåndsvalg satt med denne egenskapen ikke ha noen effekt. Denne egenskapen krever at skjemaet er åpent i nettleseren for å fungere. -3. Om skjemaet er i en tilstand hvor datamodellen ikke er skrivbar (f.eks. i PDF-generatoren), vil forhåndsvalget ikke +3. Om skjemaet er i en tilstand hvor datamodellen ikke er skrivbar (f.eks. i PDF-generatoren), vil setting av forhåndsvalgte verdier potensielt føre til feilmeldinger og mislykket innsending dersom datamodellen ikke allerede hadde en verdi. diff --git a/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md b/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md index 422b9176a0..3994301864 100644 --- a/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md +++ b/content/altinn-studio/guides/development/options/sources/dynamic/_index.en.md @@ -128,7 +128,7 @@ namespace Altinn.App.Core ``` -For your implementation to work up you need to add the following line in your `Program.cs`: +For your implementation to work you need to add the following line in your `Program.cs`: ```csharp services.AddTransient(); @@ -191,7 +191,7 @@ More examples of expressions can be found in the [dynamics documentation](../../ ### Based on the data model {{%notice warning%}} -This approach is discouraged. From app-frontend version 4.9.0, it is possible to use the `queryParameters` property instead. As explained above, `queryParameters` enabled you to include both static and dynamic query parameters through expressions, offering greater flexibility compared to `mapping`. +This approach is discouraged. From app-frontend version 4.9.0, it is possible to use the `queryParameters` property instead. As explained above, `queryParameters` enables you to include both static and dynamic query parameters through expressions, offering greater flexibility compared to `mapping`. At some point, the `mapping` property will be removed, but when that happens tools will be provided to migrate existing configurations to use `queryParameters` instead. {{% /notice%}}