Investigate how built-in model validations works

[Gelio]

Before implementing custom endpoints for model validations (#14), let's investigate how built-in model validation works.

https://github.com/Gelio/CAL-web/blob/main/backend/sirius-web-services/src/main/java/org/eclipse/sirius/web/services/validation/ValidationDescriptionProvider.java

Maybe we could leverage the built-in validation instead of building our own.

[Gelio]

Good news 🎉

The built-in validations seem to be flexible enough to allow adding custom validation sources that are combined with the default EMF diagnostics.

How Sirius Web validations work

Validation providers are registered by implementing the IValidationDescriptionProvider interface. During initialization, their getDescription method is called

CAL-web/backend/sirius-web-services/src/main/java/org/eclipse/sirius/web/services/validation/ValidationDescriptionProvider.java

Lines 42 to 56 in 905d5ec

	public ValidationDescription getDescription() {
	// This predicate will NOT be used while creating the explorer but we don't want to see the description of the
	// explorer in the list of representations that can be created. Thus, we will return false all the time.
	Predicate<VariableManager> canCreatePredicate = variableManager -> false;
	// @formatter:off
	return ValidationDescription.newValidationDescription(UUID.nameUUIDFromBytes("validation_description".getBytes())) //$NON-NLS-1$
	.label("Validation") //$NON-NLS-1$
	.canCreatePredicate(canCreatePredicate)
	.diagnosticsProvider(this::getDiagnosticsProvider)
	.kindProvider(this::kindProvider)
	.messageProvider(this::messageProvider)
	.build();
	// @formatter:on
	}

which sets up how this provider will return validations. In this particular case, diagnostic messages are gathered by calling the getDiagnosticsProvider method after every model change:

CAL-web/backend/sirius-web-services/src/main/java/org/eclipse/sirius/web/services/validation/ValidationDescriptionProvider.java

Lines 58 to 66 in 905d5ec

	private List<Object> getDiagnosticsProvider(VariableManager variableManager) {
	var optionaEditingContext = variableManager.get(IEditingContext.EDITING_CONTEXT, IEditingContext.class);
	// @formatter:off
	return optionaEditingContext
	.map(this.validationService::validate)
	.orElseGet(List::of);
	// @formatter:on
	}

This method is not called when the diagram changes visually. It gets called only when the EMF side (the model itself) changes.

How we can use the existing validations framework

Instead of providing a custom way of emitting validations (#14), we can leverage the built-in validations framework by creating a new SemanticCALValidationDescriptionProvider. It will run all sematic model validations after every model change and return them so they are ultimately shown in the UI using the existing Validation panel.

We do not need #15, and #19 is done automatically because the built-in validations are streamed to the UI using a GraphQL subscription.

See #55 for a continuation of this work.