Home » Modeling » OCL » Invariants on EStructuralFeatures(Is it possible to define invariants applied to EStructuralFeatures?)
Invariants on EStructuralFeatures [message #1343821] |
Fri, 09 May 2014 13:22 |
Victor Roldan Betancort Messages: 524 Registered: July 2009 |
Senior Member |
|
|
Hi everyone,
after implementing a set of restrictions over our models, I realised org.eclipse.emf.common.util.Diagnostic generated by the validation delegated to org.eclipse.ocl.ecore.delegate.OCLValidationDelegate did not contain certain information some frameworks expect (for instance, error decoration in a form editor for a given EStructuralFeature).
Indeed, the invariant I created was over an EClass, and therefore, the diagnostic returned applies only to our EClass instance. I understand this is the expected behavior. However, it would be desirable being able to define invariants over EStructuralFeature, so at certain point, a diagnostic would tell us something such as "the value of your feature does not complain to invariant XYZ", instead of "your EClass instance does not complain to invariant XYZ".
By looking at the documentation, I can't find a way to achieve this.
Apparently, and focusing only on contraints over EStructuralFeatures, one can use OCLInEcore either to derive them, or calculate its initial value (very cool!).
Is there a way to achieve the described scenario? Is this a missing feature or something that cannot be implemented for some reason?
Best Regards,
Víctor Roldán Betancort.
|
|
|
Re: Invariants on EStructuralFeatures [message #1344010 is a reply to message #1343821] |
Fri, 09 May 2014 15:11 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
Hi
The tutorials explain how to do custom messages, using an OCL expression
to compute the message.
Regards
Ed Willink
On 09/05/2014 14:22, Victor Roldan Betancort wrote:
> Hi everyone,
>
> after implementing a set of restrictions over our models, I realised
> org.eclipse.emf.common.util.Diagnostic generated by the validation
> delegated to org.eclipse.ocl.ecore.delegate.OCLValidationDelegate did
> not contain certain information some frameworks expect (for instance,
> error decoration in a form editor for a given EStructuralFeature).
>
> Indeed, the invariant I created was over an EClass, and therefore, the
> diagnostic returned applies only to our EClass instance. I understand
> this is the expected behavior. However, it would be desirable being
> able to define invariants over EStructuralFeature, so at certain
> point, a diagnostic would tell us something such as "the value of your
> feature does not complain to invariant XYZ", instead of "your EClass
> instance does not complain to invariant XYZ".
>
> By looking at the documentation, I can't find a way to achieve this.
> Apparently, and focusing only on contraints over EStructuralFeatures,
> one can use OCLInEcore either to derive them, or calculate its initial
> value (very cool!).
>
> Is there a way to achieve the described scenario? Is this a missing
> feature or something that cannot be implemented for some reason?
>
> Best Regards,
> Víctor Roldán Betancort.
|
|
|
Re: Invariants on EStructuralFeatures [message #1344331 is a reply to message #1344010] |
Fri, 09 May 2014 18:25 |
Victor Roldan Betancort Messages: 524 Registered: July 2009 |
Senior Member |
|
|
Ed,
I've not being clear enough. I wasn't refering to the customization of the validation messages. A code snippet may clarify this:
diagnostics.add
(createDiagnostic
(Diagnostic.ERROR,
DIAGNOSTIC_SOURCE,
PARAMETER_NAME_MUST_NOT_BE_EMPTY,
"_UI_GenericConstraint_diagnostic",
new Object[] { "name of a parameter must be defined", getObjectLabel(parameter, context) },
new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME },
context));
The Diagnostic instance has an atribute named "data", in the above example corresponds to:
new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME }
Which means that I'm passing to the diagnostic the EClass instance that violates the constraint, and more specifically, the EAttribute that violates it.
org.eclipse.emf.common.util.Diagnostic.getData()
The Diagnostic.data atribute seems to be used by implementations to add information about the diagnostic itself, for instance, some frameworks expect to find here EStructuralFeature instances, which means not only that a certain EClass instance violates a constriant, but also that an specific feature within that EClass is the culprit. This helps to decorate with error markers in UI editors, such as forms.
As reference, you may find several examples in org.eclipse.emf.ecore.util.EcoreValidator
Now, back to OCL. I'm assuming the OCL Validation Delegation does take care of the evaluation of invariants at some point, and creates the Diagnostic instances afterwards (I cant seem to find any evidence of this, though). I'd like to see these Diagnostic instances wrapping the culprit EStructuralFeature so my form editors have a formal reference to the culprit. I'm not looking to show a generic message "your name is invalid", I want my forms to know which EStructuralFeature is invalid, so it can trigger more clever logic, for instance, decorating the input box corresponding to the "name" EAttribute with an error marker.
I hope you have now a clearer picture. The EcoreValidator class should depict better what I want to explain.
Cheers,
Víctor Roldán Betancort.
|
|
|
Re: Invariants on EStructuralFeatures [message #1345997 is a reply to message #1344331] |
Sat, 10 May 2014 11:42 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
HI Victor
Sorry you're limited by the capabilities of EMF delegates and the
UML/OCL inspiration.
EMF's ValidationDelegates supports only EClass constraints and
invariants (implemanted as callable EOperations).
EMF's InvocationDelegates support EOperation bodies
EMF's SettingDelegates support EProperty initilaization
UML/OCL have derived/initial property constraints, but a derived
property constraint is really just a Class invariant that happens to
mention the property as a constrained element. An initial property
constraint is not a constraint at all; it influences the default/initial
value; the specification is not yet precise.
Just look at EcoreValidator; no individual EStructuralFeature constraints.
Of course EStructuralFeature has constraints.
If you look at markers in the Sample Ecore Editor, you get to see then
in pretty much the detail that you require.
o if you have a [10..5] multiplicity, the marker appears on the property.
I just tried it. If you open the Property View, the markers now (Luna
M7) appear in relevant form lines.
So just see how the Sample Ecore Editor works.
Regards
Ed
On 09/05/2014 19:25, Victor Roldan Betancort wrote:
> Ed,
>
> I've not being clear enough. I wasn't refering to the customization of
> the validation messages. A code snippet may clarify this:
>
>
> diagnostics.add
> (createDiagnostic
> (Diagnostic.ERROR,
> DIAGNOSTIC_SOURCE,
> PARAMETER_NAME_MUST_NOT_BE_EMPTY,
> "_UI_GenericConstraint_diagnostic",
> new Object[] { "name of a parameter must be defined",
> getObjectLabel(parameter, context) },
> new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME },
> context));
>
> The Diagnostic instance has an atribute named "data", in the above
> example corresponds to:
> new Object[] { parameter, MyPackage.Literals.NAMED_ELEMENT__NAME }
> Which means that I'm passing to the diagnostic the EClass instance
> that violates the constraint, and more specifically, the EAttribute
> that violates it.
> org.eclipse.emf.common.util.Diagnostic.getData()
> The Diagnostic.data atribute seems to be used by implementations to
> add information about the diagnostic itself, for instance, some
> frameworks expect to find here EStructuralFeature instances, which
> means not only that a certain EClass instance violates a constriant,
> but also that an specific feature within that EClass is the culprit.
> This helps to decorate with error markers in UI editors, such as forms.
>
> As reference, you may find several examples in
> org.eclipse.emf.ecore.util.EcoreValidator
> Now, back to OCL. I'm assuming the OCL Validation Delegation does take
> care of the evaluation of invariants at some point, and creates the
> Diagnostic instances afterwards (I cant seem to find any evidence of
> this, though). I'd like to see these Diagnostic instances wrapping the
> culprit EStructuralFeature so my form editors have a formal reference
> to the culprit. I'm not looking to show a generic message "your name
> is invalid", I want my forms to know which EStructuralFeature is
> invalid, so it can trigger more clever logic, for instance, decorating
> the input box corresponding to the "name" EAttribute with an error
> marker.
>
> I hope you have now a clearer picture. The EcoreValidator class should
> depict better what I want to explain.
>
> Cheers,
> Víctor Roldán Betancort.
|
|
| |
Goto Forum:
Current Time: Tue Mar 19 07:34:56 GMT 2024
Powered by FUDForum. Page generated in 0.02867 seconds
|