Property constraint violation error
While customizing the "name" field , have you come across a error "Property constraint violation"
on the empty name field?
written your own error messages in the "typesystem" aspect, but still
this error message takes precedence and takes all attention?
What is a Name Property?
Name Property is the most used variable while developing with MPS. MPS provides a Interface called INamedConcept or IValidNamedConcept and some more similar interfaces which implements the "name" property with well defined behaviour.
These comes very handy and all we have to do is to define a concept, allow the concept, implementing any of the interface which implemented name property and thats it. Its a plug and play to use the name and its associated validations.
there are times where we want to customize name behavior keeping some of
the existing features intact. So we implement the inbuilt interface and also we would
override some validations which we want to customize.
While this error is being faced, you could also
face some inconsistencies in the empty validations and also some annoying
behavior while trying to delete the name value.
Check if any of the concept used in the concept-in-focus causing error, or one of its superconcepts has already implemented some interface which implemented 'name'
have recently migrated from 2019.1 to further MPS versions and if you have your
concept extending "Chunk" concept, then you could see here that Chunk
implemented IIdentifierNamedConcept and which in turn implemented
INamedConcept, which will have set of constraint rule for the name property.
These rules are inherited and that is why you see "Property constraint violation error" despite having your own custom error message. But you can override them in your concept.
of the above case, all you have to do is, create a "constraint"
aspect for your concept and create a "Property constraint rule" like
Sometimes even this may not resolve the issue for you. Because <always> might actually mean <inherited from superconcept>. So MPS will look for a explicit "return true" in this case.
Thus setting the rule like above, will allow you
to do the customization of existing properties the way you require and not
inhering from the superconcept's implementation, thus eliminating the error.