How to trigger the ModelValidator?

[rsoika]

Hi, I have a question regarding the ModelValidator in GLSP 2.x .
My old ModelValidator did no longer seem to work. At least it is not triggered at all when I click on the validation icon in the toolbar

My implementation is exactly like explained in the documentation, but for some reason there is no more trigger. I do not get any error messages on client or server side.

I found that there is some new feature regarding live and batch validation but did not found out if this is related to my problem.
What could be the reason that my ModelValidator is not longer called? My binding in the DiagramModule has not changed...

    @Override
    protected Class<? extends ModelValidator> bindModelValidator() {
        return BPMNGLSPValidator.class;
    }

[rsoika]

...ok it looks like instead of implementing the validate method you should now implement the doBatchValidation method. I am not sure now how to implement a validator in the correct way....?

[rsoika]

I get now some understanding about the idea behind doLiveValidation and doBatchValidation.

• doBatchValidation is only called when the user triggers the validate icon and a complete model validation can be performed.
• doLiveValidation is triggered when a model operation like load, create or delete is performed.

So this should give an implementer more control what/how to validate

But I think there is something gong wrong. If I have a model with 2 Node Elements and I load my model, the method validate is triggered 4 Times!

1. called with only the root element
2. called with full element list of my two elements
3. called with the first element
4. called with the second element

And it's the same when I click the 'validation' icon and the batch-mode is triggered. It seems to be to much?

Also a kind of interceptor hook would be nice - like beforeValidation and afterValidation - or is there already a action event for this?

The reason why I am thinking about this is that in our Open-BPMN project we have a internal validation method that is validating a BPMN model. And this is not related to a GNode. We validate the complete SourceModel. In the methods for doBatchValidation or doLiveValidation we can simply (and very fast) match our last validation result list against the requested GNode Element ID.

In any case I need to cache my validation results. But this can be done easily in the ModelState object or my SourceModel. And this is all fine to me.

But I think there are tree issues.

1. The validation methods are triggered much to often.
2. The live Validation should fro my understanding only be triggered on the element that is newly created (or is my Open-BPMN implementable again totally wrong....?)
3. There should be two interceptor points to allow a implementation to do some kind of caching/cleaning up of a Markers list

What do you think about this?

[tortmayr]

@rsoika I don't think I can follow. How does this solution behave differently then what we have now?
The current implementation should do exactly the same thing. Looks to me like his is just a different variant of the same recursion logic.

[rsoika]

Hi @tortmayr ,

my problem is/was that I need some point at the beginning of the validation to run some internal code to prepare general markers that are mostly independent from a GModel Element. And this can not work if the validate method calls itself recursive.
When you took a look at your example in the documentation you are doing exactly this to avoid the recursive call.

By overwriting the validate method in my own implementation I have overseen the recursive call that leads me into a situation where I run my internal caching multiple times. Ok this was my fault.

But to explain it in another way: I need to validate my BPMN model (which is a XML) using a XSD file. This is a complex process. With the result of this first analysis I can later - in the methods doLiveValidation and doBachValidation answer the question how a specific node should be marked very quickly.

If someone has a similar situation with a more complex validation situation, than he will not recursive call his validate method. But the validate method need to be overwritten in any case as this is the only interface to control the validation process.

Yes, you are right, my new validate impl above did exactly the same as your default impl. But this is only because I left all my other code I need to implement during validation. Imagine someone need to open a database to lookup some specific data needed for validation. This canÄ't work with the current default impl fro my understanding.

I know this is very philosophic now and a question about where a public API starts and where it should end.

See my following suggestion for the interface (with the recommendation not to overwrite validate):

public interface ModelValidator {

default List<Marker> validate(final <GModelRoot> root, final String reason) {
    beforeValidation(root);
    List<Marker> markers = new ArrayList<>();
    List<GModelElmeent> elements=root.getChildren();
    for (GModelElement element : elements) {
        validateElement(element, reason, markers);
    }
    afterValidation(root);
    return markers;
}

default void validateElement(GModelElement element, String reason, List<Marker> markers) {
    if (MarkersReason.LIVE.equals(reason)) {
        markers.addAll(doLiveValidation(element));
    } else if (MarkersReason.BATCH.equals(reason)) {
        markers.addAll(doBatchValidation(element));
    } else {
        markers.addAll(doValidationForCustomReason(element, reason));
    }

    if (!element.getChildren().isEmpty()) {
        // Recursive call for each child element
        for (GModelElement childElement : element.getChildren()) {
            validateElement(childElement, reason, markers);
        }
    }
}

default void beforeValidation(final <GModelRoot> root, final String reason) {
  // no op
}
default void afterValidation(final <GModelRoot> root, final String reason) {
  // no op
}

default List<Marker> doLiveValidation(final GModelElement element) {
      return Collections.emptyList();
}
default List<Marker> doBatchValidation(final GModelElement element) {
      return Collections.emptyList();
}
default List<Marker> doValidationForCustomReason(final GModelElement element, final String reason) {
      return Collections.emptyList();
}
}

[tortmayr]

Ah I see, I missed the requirement for the before and after validation hooks and adding them to the official public API definitely makes sense.
However, I see a couple of issues with your current proposal:
Restricting the first argument of validate to the root introduces an API break that potentially affects a lot of adopters.
In addition, it prohibits use cases where only a subset of the graphical model should be validated.
(Or requires additional checks in the doXyzValidation submethods to skip certain elements)

Couldn't we simply move the current behahvior of validate into a new mehtod (e.g. doValidate) and adapt validate to call the hook methods before and after `doValidatre?

I'm thinking of something like this:

public interface ModelValidator {

   default List<Marker> validate(final List<GModelElement> elements, final String reason) {
      beforeValidate(elements, reason);
      List<Marker> markers = doValidate(elements, reason);
      afterValidate(elements, reason);
      return markers;
   }

   default void beforeValidate(final List<GModelElement> elements, final String reason) {
      // no op
   }

   default void afterValidate(final List<GModelElement> elements, final String reason) {
      // no op
   }

   default List<Marker> doValidate(final List<GModelElement> elements, final String reason) {
      List<Marker> markers = new ArrayList<>();

      for (GModelElement element : elements) {
         if (MarkersReason.LIVE.equals(reason)) {
            markers.addAll(doLiveValidation(element));
         } else if (MarkersReason.BATCH.equals(reason)) {
            markers.addAll(doBatchValidation(element));
         } else {
            markers.addAll(doValidationForCustomReason(element, reason));
         }
         if (!element.getChildren().isEmpty()) {
            markers.addAll(doValidate(element.getChildren(), reason));
         }
      }

      return markers;
   }

...
}

WDYT?

[rsoika]

Yes you are absolutely right and I was not happy too with my proposal breaking the existing api.
Your proposal is the right one! I just changed my current impl to this pattern - so it is tested ;-)

What I did not yet understand - independent from the API discussion: how can I detect the effected elements in a live-validation? Currently when I move or add a single element I also get the complete list - which I know myself.

For example, adding a sequence flow into a BPMN element would only need to validate the source and target elements in the live case. So what I would do now, is caching the list of element IDs in the afterValidate method and compare this cached list in the beginValidate method to create a kind of whitlist/blacklist,

[rsoika]

Hi @tortmayr,
finally I developed a complete new Validation API in our BPMN Meta Model, that can be much easier adapted into the GLSP Validation API. And this I think, matches your initial thoughts about validation.

• My Source Model Elements in my BPMN Meta Model are extended with a Validator API.
• Each Source Element is responsible to validate itself against the current model
• Each Source Element holds a Validation Status and the latest List of Markers

During this LIVE-Validation my BPMN Validator...

• asks each source element if it was yet validated (by its status flag).
• if not, the validator calls validate() on the source Element
• and finally fetches the latest list of validation Marker from the element itself.

In case of a BATCH-Validation my BPMN Validator forces the validation of each element independent of its internal state.

This makes it possible to even validate large models with more than 100 elements in less then 20 ms.
And I do no longer need the before/after hooks for my project. But still I think this would be a good extension to the GLSP validation API. And we do not break the API.

Also my question above regarding how to get only the effected elements in a live-validation is now irrelevant. If a new element is added or an Edge connects new elements, my related Source Elements are now reset its internal validation state. And so a LIVE validation will only re-validate the related elements. And I now understand your idea better - GLSP can not know what needs to be re-validated in a LIVE-Validation. As you already wrote in the Documentation only the Server (Source Model) knows the validation status). But still the example code leads the developer into the wrong direction as the example suggest that it is the GNode which need to be validated. And this is not true for more complex model projects.

The new example code maybe can look more like this :

public class CustomModelValidator implements ModelValidator {

    // Do Model validation of a single element in BATCH mode....
    @Override
    public List<Marker> doBatchValidation(final GModelElement element) {
         List<Marker> result = new ArrayList<>();        
        result.add(new Marker("Node", "This graphical element was validated in BATCH mode ", element.getId(),
       MarkerKind.INFO);));
        return result;
    }
    
    // Do Model validation of a single element in LIVE mode....
    @Override
    public List<Marker> doLiveValidation(final GModelElement element) {
        List<Marker> result = new ArrayList<>();        
        result.add(new Marker("Node", "This graphical element was validated in LIVE mode ", element.getId(),
       MarkerKind.INFO);));
        return result;
    }    
 }