-
|
I am implementing the new Validation API in my project. We have this discussion regarding BATCH and LIVE validation. I think I understand the concepts how to validate now pretty well. But I observe another issue. It looks like GLSP caches - or not clears - marker lists. In the following example I load a model with two errors. During load the 1st LIVE validation is triggered and the markers are displayed immediately on the elements and in the problem view.
In the next example, I load the same model (1st LIVE Validation) and click on the validation button in the Tool Palette (1st BATCH Validation). And now the markers are duplicated as you can see in the problem view. Even if I connect the two elements (2nd LIVE validation) only 2 of the 4 markers are cleared. So it looks like my diagram still have problems.
This looks to me that internally there are two marker lists hold by GLSP. For my understanding a BATCH Validation should clear all existing markers before. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
Hi @rsoika, I don't know the exact reasoning behind that maybe @planger has more insights on that topic. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the idea behind that is to have a distinct set of rules for live validation and batch validation. This way, each validation rule is executed only once for the scope you want to run the validation (live or batch). Thus, when a batch validation is triggered, all markers of previous batch validations are cleared. When a live validation is triggered, all markers of the previous live validation are cleared. But they do not impact each other. Otherwise, if an adopter doesn't make sure to invoke all live validation rules also from the batch validation, we would loose markers. So I'd suggest to not run the live validation checks in the course of a batch validation, but only the expensive additional rules. |
Beta Was this translation helpful? Give feedback.
-
|
@planger , OK understood, and in deed I have really a use for this too: In our Open-BPMN-Meta Project we have implemented a general core-validation mechanism that is completely independent from GLSP. This validation mechanism is called in LIVE-Mode. We check only simple BPMN rules on a concrete element, like:
This validation is very fast and uses an internal caching mode bound to the meta-model. And on the other side in Open-BPMN we have an extension mechanism hat allows adopters to extend the behavior for BPMN elements. We use this in our Imixs-BPMN Version. And for Imixs-Workflow models need to be validated in a more complex way. For example each event-element has an public ID that need to be unique in the context of the associated Task Element. This is not a general BPMN rule but specific for Imixs-Worklow. The validation is very complex - and so the BATCH Validation is the perfect place for that kind of rules! And so it shows once again that GLSP is simply the perfect framework :-) |
Beta Was this translation helpful? Give feedback.
Yes, the idea behind that is to have a distinct set of rules for live validation and batch validation. This way, each validation rule is executed only once for the scope you want to run the validation (live or batch). Thus, when a batch validation is triggered, all markers of previous batch validations are cleared. When a live validation is triggered, all markers of the previous live validation are cleared. But they do not impact each other.
Otherwise, if an adopter doesn't make sure to invoke all live validation rules also from the batch validation, we would loose markers.
If the framework would enforce this (ie running all live validation rules on batch validation request), we would ess…