Altinn / Altinn/app-lib-dotnet
Support seperate presentation model & data model
- Dominant language
- C#
- Stars
- 8
- Forks
- 27
- Avg merge
- 1h 21m
- Merged PRs (30d)
- 7
Description
## Description
To be able to support an optimal UI, we might end up in a suboptimal data model.
Not all data models can be mapped to a sensible view model or UI setup for the front end.
We then end up with a UI that is not 100%, or we need to change the data model in the app to something else defined for the core system.
It is requested that we support having one data model used for UI support, and we convert the data to a more data-centric model.
An example of a data model where this was done to support UI is Altinn/apps-backlog#1
## Considerations
- Hide data object for end-user
- Where and when should this conversion happen. For every save or when a data task is completed? Both?
- Do we risk more errors since mapping can cause errors
- Manuell mapping we need to support, but do we need to support automatic mapping for simple cases? The assumption is no; when the case is simply, the need for two models is probably low.
### Ops requirements
Are there any requirements related to backup? -->
## Acceptance criteria
- [ ] Support separate data model used for supporting UI and downloading to ORG
- [ ] Models are in sync
## Specification tasks
- [ ] Development tasks are defined
## Development tasks
## Test
## Definition of done
- [ ] Documentation (docs.altinn.studio) is updated (if relevant)
- [ ] Technical documentation
- [ ] User documentation
- [ ] QA
- [ ] Manual test is complete (if relevant)
- [ ] Automated test is implemented (if relevant)
- [ ] All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)
Contributor guide
Research direction
No files, tests, or entry points are identified. Start by defining the development tasks and deciding when and where manual model conversion occurs, including backup and error handling; done means separate UI and organization data models are supported and remain in sync, with relevant automated and manual tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100