[1883] add some metadata to the projects

CHANGELOG.adoc

@@ -6,12 +6,19 @@
 
 - Filter tree based representations
 - Add pages to form in the view DSL
+- Simplify the programmatic creation of view models
+- Add the ability to convert an odesign to a view model
+- Provide a view-based version of Flow
+- Add support for the features of the compatibility layer not supported in the view DSL
+- Add an example showing how to contribute to the details view with the View DSL
 
 === Architectural decision records
 
+- [ADR-098] Use the editing context to compute the metamodels
+
 === Breaking changes
 
-- https://github.com/eclipse-sirius/sirius-components/issues/1897[1897] [diagram] ToolSection are not using records
+- https://github.com/eclipse-sirius/sirius-components/issues/1897[1897] [diagram] ToolSection are now using records
 - https://github.com/eclipse-sirius/sirius-components/issues/1616[#1616] [core] Use Java records for all our payloads
 - https://github.com/eclipse-sirius/sirius-components/issues/1848[#1848] [project] Remove the frontend dependency to `uuid` in favor of `crypto.randomUUID`
 - https://github.com/eclipse-sirius/sirius-components/issues/1907[#1907] [view] The management of colors is changing, it is not possible anymore to use color directly represented by a string in the _styleDescription_.
@@ -34,6 +41,11 @@ In the _styleDescription_, the definition of a color are now a select list of al
 
 === New Features
 
+- https://github.com/eclipse-sirius/sirius-components/issues/1883[#1883] [sirius-web] Add the possibility to programmatically set some metadate such as specifics natures to a project.
+These natures can be used later to enable or not some capabilities on a project.
+This work will start by adding the ability to filter the project's domains.
+A large set of features will have to be updated in order to stop considering the list of metamodels available in an editing context as a certainty.
+
 === Improvements
 
 - https://github.com/eclipse-sirius/sirius-components/issues/1869[#1869] [tree] Navigate to the first child with the right arrow if a node is expanded.

doc/adrs/098_use_the_editing_context_to_compute_the_metamodels.adoc

@@ -0,0 +1,28 @@
+= ADR-098 - Use the editing context to compute the metamodels
+
+== Context
+
+Up until now, in Sirius Web, the metamodels available for an editing context were a mix of global metamodels available all the time and the domains converted when the editing context was loaded.
+
+There are no specific features related to the metamodels converted from a domain.
+Only the global metamodels have some dedicated features such as the creation of dedicated resources (robot flow, domain and view sample etc)
+
+If we ever want to consider specific features for any metamodel, we should embrace the fact that, all the editing contexts do not have the same metamodels.
+
+== Decision
+
+In Sirius Web, we will only use the `EPackage.Registry` of the editing context in order to find the available metamodels.
+Sirius Components will stop considering a set of global EPackages as special and available everywhere.
+
+In order to force ourselves to properly consider the impact of this use case, some metadata will be added to Sirius Web projects.
+We will only keep a list of natures in these project metadata for now.
+A nature will be defined as an identifier.
+
+We will introduce the nature `siriusWeb://nature?kind=studio` in order to identify Sirius Web projects created using the studio template.
+
+Those projects will be the only one with all metamodels, view and domain included.
+No other project should be able to create domains or views.
+
+== Status
+
+Accepted

doc/iterations/2023.6/shapes/add_missing_features_in_the_view_support.adoc

@@ -0,0 +1,34 @@
+= (M) Add support for the features of the compatibility layer not supported in the view DSL
+
+== Problem
+
+Some odesign concepts are not implemented in View (like selection dialogs or icons support). 
+
+== Key Result
+
+Each new feature works and can be used by the end user, the new flow version is updated to use those features, integration tests of those features are available
+
+== Solution
+
+For each concepts we should provide an adrs that will explain the solution if more details.
+
+We should also provide some mock ui in these adrs.
+
+=== Scenario
+
+An user will be able to use the newly implemented concept that was available in odesign models in updated views.
+
+=== Breadboarding
+
+Futurs ui changes will be discussed in their respective adrs.
+
+=== Cutting backs
+
+Some concepts may be challenging to implement. We will discuss it further in specific adrs.
+
+== Rabbit holes
+
+Some concepts may be challenging to implement. We will discuss it further in specific adrs.
+
+== No-gos
+

doc/iterations/2023.6/shapes/odesign_to_view_converter_api.adoc

@@ -0,0 +1,48 @@
+= (M) Add the ability to convert an odesign to a view model
+
+== Problem
+
+We can create representations descriptions programmatically, with the view model and with the compatibility layer that converts to odesign files in representation descriptions.
+It will be more efficient to concentrate our efforts in the creation of representation description programmatically and with the view model.
+As such the odesign will be converted to a view.
+Using plain old Java code, we should be able to transform an odesign model into a view model while converting the diagram and form descriptions. 
+
+== Key Result
+
+A first version of flow, simplified, is available (potentially behind a flag), integration tests are available to validate the result.
+
+== Solution
+
+This code should be provided in a dedicated project named `sirius-components-odesign-converter`.
+
+```
+package org.eclipse.sirius.components.odesign.converter;
+
+import org.eclipse.sirius.viewpoint.description.Group;
+import org.eclipse.sirius.components.view.View;
+
+public interface IOdesignConverter {
+    Optional<View> convert(Group group);
+}
+```
+
+The implementation will use an iterative transformation approach meaning that the API should be decomposed in smaller APIS that convert specific entities and that it should be possible to add more entities to be converted in the future.
+The implementation will use the the soon to be introduced view creation API.
+
+=== Scenario
+
+A user will be able to use the new interface IOdesignConverter to convert an odesign file to a view model.
+
+=== Breadboarding
+
+No ui changes
+
+=== Cutting backs
+
+We will be able to support more concepts of the odesign model in the view model in a near future
+
+== Rabbit holes
+
+== No-gos
+
+

doc/iterations/2023.6/shapes/provide_a_view_based_version_of_flow.adoc

@@ -0,0 +1,38 @@
+= (M) Provide a view-based version of Flow
+
+== Problem
+
+In order to include a test which covers the odesign to view transformation, we will migrate the existing flow model.
+
+== Key Result
+
+The new view-based version of flow is fully equivalent to the previous odesign based version, all integrations tests of the odesign version of flow are working on the new version
+
+== Solution
+
+We will use the same maven package flow's dependencies.
+We will offer an interface that if implemented will convert the odesign from their path to Views.
+
+=== Scenario
+
+The end user will open Sirius Web and not see any single change at all.
+
+Everything will work as before including our Cypress integration tests.
+
+=== Breadboarding
+
+no ui changes
+
+=== Cutting backs
+
+Some concepts might not be available in the first implementation of the odesign converter.
+They will be added back progressively
+
+== Rabbit holes
+
+== No-gos
+
+
+
+
+

doc/iterations/2023.6/shapes/simplify_the_programmatic_creation_of_view_models.adoc

@@ -0,0 +1,49 @@
+= (L) Simplify the programmatic creation of view models
+
+== Problem
+
+We can create representations descriptions programmatically, with the view model and with the compatibility layer that converts odesign files in representation descriptions.
+Another use case is to create view models programmatically but we don't have an API to create complex models easily.
+
+
+== Key Result
+
+The Papaya View will be created with this new API and offer the same functionalities than before this implementation.
+All the tests will still work.
+
+
+== Solution
+
+In a project `sirius-components-view-builder`, depending only on `sirius-components-view`, we should provide utility classes to help the creation of view based models.
+We will need to synthesize how other applications using Sirius Web implements some parts of the future API.
+The detailed ADR will gather some feedback first.
+
+
+=== Scenario
+
+Some features that the API will offer are :
+
+* Helpers for creating diagrams, nodes and edges
+* Helpers for creating element's style and conditional style
+* Helpers for creating unsynchronized nodes (including unsynchronized children or recursively with reused node description)
+* Easy access to previously declared elements to use them as reference to other elements (for example an edge description will need some node description)
+* Helpers for creating tools (node & edge creation, delete, direct edit, drag & drop, simple or complex tools)
+* Helpers for creating and reusing AQL expressions that will be used in previous scenarios.
+
+
+=== Breadboarding
+
+no ui changes
+
+=== Cutting backs
+
+The AQL expressions API could be reused for scenarios other than diagram, tool, node and edge creation.
+
+As such, it will probably need specific ADR and might be too large to implement completely in this scope.
+
+== Rabbit holes
+
+== No-gos
+
+The API will not generate a complete diagram description from a metamodel, we want to explicitly control what's created.
+

doc/iterations/2023.6/shapes/view-based_details_view.adoc

@@ -0,0 +1,62 @@
+= (S) Add an example showing how to contribute to the details view with the View DSL
+
+== Problem
+
+The default rules used for the _Details_ view provide a good generic solution, but in practice applications often need more specific details views for (some of) their elements.
+
+It is possible override these default rules by providing more specific custom `FormDescription` which apply to specific elements using the `IPropertiesDescriptionRegistryConfigurer` API.
+Indeed, we already use this capability ourselves in `NodeStylePropertiesConfigurer`.
+However this is not documented, and relatively cumbersome as it requires creating a fully programmatic `FormDescription` instance.
+
+We already support the definition of _Forms_ using the View DSL, which providers nicer APIs for this.
+We should provide an end-to-end example showing how to use a View-based Form definition to customize the _Details_ view for specific elements.
+
+== Key Result
+
+A studio maker who wants to provide custom _Details_ view for some types will find a clear documented path to do it by leveraging the View DSL to define the contents of the _Details_ views in question.
+
+== Solution
+
+We will rewrite the `NodeStylePropertiesConfigurer` to create its `FormDescription` as View-based Forms which are converted at startup into a programmatic `FormDescription` instance.
+
+We will organize its implementation to clearly separate the *definition* of the various View-based forms (which will be different in every use case) from their *conversion* and *registration* (which will be the same "glue code" in most/all cases).
+
+The definition part is specific to this case, while the conversion and registration parts are generic and will be lifted into reusable and documented helpers.
+
+=== Scenario
+
+A studio maker who wants to provide custom Details view for some types will then need to:
+
+1. Write a Java class which builds a View-based Form using the EMF API for the View DSL (maybe with some simple helpers).
+2. If the AQL expressions used by this Form need them, write the AQL Service classes needed.
+3. Define a Spring `@Component` which extends `IPropertiesDescriptionRegistryConfigurer` and in its `addPropertiesDescriptions` method uses a helper (that we will provide) to convert the result of the two steps above into a fully functional API-base `FormDescriptionEditor`.
+
+=== Breadboarding
+
+No UI changes.
+
+=== Cutting backs
+
+Allow the definition of these "details view" from a `.view` resource loaded on startup, which could have been designed graphically using the FormDescriptionEditor.
+The workflow would be:
+
+1. Design a Form visually using the FormDescriptionEditor.
+2. Test it at runtime as an actual Form representation.
+3. Once satisfied, download the _Form_ as a local file, put it in the `src/main/resources` folder of the application as a `.view` model.
+4. Follow the same steps as in the scenario above, except that instead of creating the View model using plain Java and EMF, it is loaded "fully formed" from the file.
+
+Note that this scenario is more "user friendly" but less powerful as it does not allow the use of custom Java services in the definition of the Form.
+Or more precisely it allow their use (AQL expressions are just strings) but features which use them can not be tested.
+
+== Rabbit holes
+
+- NodeStylePropertiesConfigurer uses various advanced techniques (for example to support images and their previous) which may or may not translate easily in View-based Forms.
+In particular the AQL expressions used by the Forms will need to depend on Java services to be extracted and provided to the converter.
+
+- Building a high-level API on top of the EMF-based one to ease the creation of these View-based FormDescriptions.
+We may extract some helpers here and there, but the goal is not to try and design a nicer API for this.
+This may come later after https://github.com/eclipse-sirius/sirius-components/issues/1921 has done something like this for View-based diagrams.
+
+== No-gos
+
+It is not in the scope of this shape to register a FormDescription defined *in a studio* as the one to be used for the _Details_ view of elements for a given domain.

integration-tests/cypress/e2e/project/edit/document-context-menu.cy.js

@@ -38,7 +38,7 @@ describe('/projects/:projectId/edit - Document Context Menu', () => {
 
     cy.getByTestId('create-object').click();
 
-    cy.getByTestId('explorerTree').contains('Domain');
+    cy.getByTestId('explorerTree').contains('System');
   });
 
   //fails during build
@@ -49,8 +49,8 @@ describe('/projects/:projectId/edit - Document Context Menu', () => {
 
     cy.getByTestId('create-object').click();
 
-    cy.getByTestId('explorerTree').contains('Domain');
-    cy.getByTestId('selected').contains('Domain');
+    cy.getByTestId('explorerTree').contains('System');
+    cy.getByTestId('selected').contains('System');
   });
 
   it('can delete a document', () => {

integration-tests/cypress/e2e/project/edit/explorer.cy.js

@@ -161,7 +161,7 @@ describe('/projects/:projectId/edit - Explorer', () => {
 
   it('documents are alphabetically ordered (case insensitive order)', () => {
     // Create Flow Model
-    cy.getByTestId('08e5c635-7d98-37e9-847c-df286e3b2f16').click();
+    cy.getByTestId('empty_flow').click();
     // Check documents order
     cy.getByTestId('tree-root-elements').children().first().contains('Flow').should('exist');
     cy.getByTestId('tree-root-elements').children().last().contains('robot').should('exist');

integration-tests/cypress/e2e/project/edit/formdescriptioneditor.cy.js

@@ -13,8 +13,8 @@
 describe('/projects/:projectId/edit - FormDescriptionEditor', () => {
   beforeEach(() => {
     cy.deleteAllProjects();
-    cy.createProject('Cypress Project').then((res) => {
-      const projectId = res.body.data.createProject.project.id;
+    cy.createProjectFromTemplate('studio-template').then((res) => {
+      const projectId = res.body.data.createProjectFromTemplate.project.id;
       const view_document_id = 'ea57f74d-bc7b-3a7a-81e0-8aef4ee85770';
       cy.createDocument(projectId, view_document_id, 'ViewDocument').then(() => {
         cy.visit(`/projects/${projectId}/edit`);

integration-tests/cypress/e2e/project/edit/onboarding.cy.js

@@ -20,9 +20,8 @@ describe('/projects/:projectId/edit - Onboarding', () => {
     });
   });
 
-  it('Create a new model', () => {
-    const empty_flow_id = '08e5c635-7d98-37e9-847c-df286e3b2f16';
-    cy.getByTestId(empty_flow_id).click();
+  it('Create a new model', () => {    
+    cy.getByTestId('empty_flow').click();
     cy.getByTestId('explorerTree').contains('Flow');
   });
 });

integration-tests/cypress/e2e/project/edit/studio.cy.js

@@ -37,4 +37,12 @@ describe('/projects/:projectId/edit - Studio', () => {
         .then((value) => expect(value).to.match(/translate\(.*, .*\) translate\(.*, .*\)/));
     });
   });
+
+  it('Check the new object domain list', () => {
+    cy.getByTestId('DomainNewModel-more').click();
+    cy.getByTestId('new-object').click();
+    cy.getByTestId('domain').click().get('[data-value="http://www.eclipse.org/sirius-web/domain"]').should('exist');
+    cy.getByTestId('domain').get('[data-value="http://www.eclipse.org/sirius-web/view"]').should('exist');
+    cy.getByTestId('domain').get('[data-value="http://www.obeo.fr/dsl/designer/sample/flow"]').should('exist');
+  });
 });

packages/charts/backend/sirius-components-charts/.settings/org.eclipse.jdt.ui.prefs

@@ -96,7 +96,7 @@ sp_cleanup.convert_functional_interfaces=false
 sp_cleanup.convert_to_enhanced_for_loop=false
 sp_cleanup.convert_to_enhanced_for_loop_if_loop_var_used=false
 sp_cleanup.convert_to_switch_expressions=false
-sp_cleanup.correct_indentation=true
+sp_cleanup.correct_indentation=false
 sp_cleanup.do_while_rather_than_while=false
 sp_cleanup.double_negation=false
 sp_cleanup.else_if=false

packages/charts/backend/sirius-components-collaborative-charts/.settings/org.eclipse.jdt.ui.prefs

@@ -96,7 +96,7 @@ sp_cleanup.convert_functional_interfaces=false
 sp_cleanup.convert_to_enhanced_for_loop=false
 sp_cleanup.convert_to_enhanced_for_loop_if_loop_var_used=false
 sp_cleanup.convert_to_switch_expressions=false
-sp_cleanup.correct_indentation=true
+sp_cleanup.correct_indentation=false
 sp_cleanup.do_while_rather_than_while=false
 sp_cleanup.double_negation=false
 sp_cleanup.else_if=false

packages/compatibility/backend/sirius-components-compatibility-emf/.settings/org.eclipse.jdt.ui.prefs

@@ -96,7 +96,7 @@ sp_cleanup.convert_functional_interfaces=false
 sp_cleanup.convert_to_enhanced_for_loop=false
 sp_cleanup.convert_to_enhanced_for_loop_if_loop_var_used=false
 sp_cleanup.convert_to_switch_expressions=false
-sp_cleanup.correct_indentation=true
+sp_cleanup.correct_indentation=false
 sp_cleanup.do_while_rather_than_while=false
 sp_cleanup.double_negation=false
 sp_cleanup.else_if=false

packages/compatibility/backend/sirius-components-compatibility/.settings/org.eclipse.jdt.ui.prefs

@@ -96,7 +96,7 @@ sp_cleanup.convert_functional_interfaces=false
 sp_cleanup.convert_to_enhanced_for_loop=false
 sp_cleanup.convert_to_enhanced_for_loop_if_loop_var_used=false
 sp_cleanup.convert_to_switch_expressions=false
-sp_cleanup.correct_indentation=true
+sp_cleanup.correct_indentation=false
 sp_cleanup.do_while_rather_than_while=false
 sp_cleanup.double_negation=false
 sp_cleanup.else_if=false