-
Notifications
You must be signed in to change notification settings - Fork 58
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[doc] Add shape to dynamically update representation description
Signed-off-by: Michaël Charfadi <[email protected]>
- Loading branch information
1 parent
58d390b
commit 7557f0f
Showing
2 changed files
with
45 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
44 changes: 44 additions & 0 deletions
44
...tions/2025.2/add_support_to_dynamically_update_ representation_description.adoc
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,44 @@ | ||
= Add support to dynamically update representation descriptions | ||
|
||
== Problem | ||
|
||
A specifier or an end user can't update at runtime the description of any representation that was declared using the view DSL. | ||
This feature is currently only supported for tables. | ||
|
||
|
||
== Key Result | ||
|
||
We want to be able to generate a new studio from any representation whose description comes from a view model. | ||
This new studio will be a copy of the current description used by the representation. | ||
The description will thus become modifiable in this studio. | ||
|
||
=== Acceptance Criteria | ||
|
||
- Some backend test will be necessary to ensure that the studio is properly created with the expected description for any representation. | ||
This can be tested using the Papaya diagrams which are described using the view DSL | ||
- Some Cypress test will also be relevant to validate the entire user experience. | ||
It will especially be useful to ensure that the studio is properly connected with the existing representation and that new changes to the studio are visible in the representation | ||
- We should also validate that this behavior exists only for representations created using the view DSL | ||
|
||
=== Scenario | ||
|
||
A specifier wants to change a representation description : | ||
|
||
1 - He clicks on the tree item menu associated with the representation in the explorer | ||
2 - He clicks on the new option 'Create a copy of the current description' | ||
3 - He is redirected to a new studio where he can make changes to the representation (a modal was shown to validate the user choice before the redirection) | ||
|
||
|
||
=== Breadboarding | ||
|
||
Since we want to add this option generically for all representations, we will move away from a custom contribution in the table actions to use instead a tree item context menu available on all representations created using a view DSL. | ||
|
||
=== Cutting backs | ||
|
||
|
||
== Rabbit holes | ||
|
||
|
||
== No-gos | ||
|
||
We will not consider representation descriptions created programmatically |