Home » Modeling » EMF » change generated Validator to ensure that referenced features are valid, too
| change generated Validator to ensure that referenced features are valid, too [message #1076463] |
Wed, 31 July 2013 12:37  |
 Franz Thiele
Messages: 7
Registered: July 2013 |
Junior Member |
|
|
Hello,
let's say I generate a model, edit and editor plugin from the annotated java interface A below, which is part of a much larger package. The default behaviour of the generated Validator is that A can be valid although the referenced B and Cs (which are contained elsewhere) are invalid. I would like to ensure in the validation that all referenced features must be valid, too. Is this possible?
I would like to change this behaviour somewhere in the code once, not for all of my classes again and again. I have a few hundred classes A, B, C , ..., which are all derived from some common (abstract) base class.
How can I make the Validator check that all referenced (not necessarily contained) features are valid?
Here is the example code:
/**
* @model annotation="http://www.eclipse.org/emf/2002/Ecore constraints='MyConstraint'"
*/
public interface A {
/**
* @model containment="false"
*/
public B getB();
/**
* @model type="C" containment="false"
*/
public List getCs();
}
And another question, independent from the validation thing:
Suppose I define an "interface A2 extends A", where I would like to provide lower and upper bounds to getCs(). If I declare getCs() again in A2 with "lower" and "upper" annotations, I get an error message "There may not be two features named 'cs'". Is it possible to change the multiplicity in a derived class?
Thank you
Franz
|
|
|
| Re: change generated Validator to ensure that referenced features are valid, too [message #1076484 is a reply to message #1076463] |
Wed, 31 July 2013 13:10  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Franz,
Comments below.
On 31/07/2013 2:37 PM, Franz Thiele wrote:
> Hello,
> let's say I generate a model, edit and editor plugin from the
> annotated java interface A below, which is part of a much larger
> package. The default behaviour of the generated Validator is that A
> can be valid although the referenced B and Cs (which are contained
> elsewhere) are invalid. I would like to ensure in the validation that
> all referenced features must be valid, too. Is this possible?
The validator only walks the containment tree to invoke validations for
each contained object.
>
> I would like to change this behaviour somewhere in the code once, not
> for all of my classes again and again. I have a few hundred classes A,
> B, C , ..., which are all derived from some common (abstract) base class.
> How can I make the Validator check that all referenced (not
> necessarily contained) features are valid?
Of course you'd need to be very careful about that because you'd not
ever want to validate something twice and if you made validation
traverse non-containment references you could end up visiting the same
object more than once...
And I'm a bit confused about the actual use case. If B is invalid or
one of the Cs is invalid, does that make A invalid? I suppose not?
How are you invoking validation? Just on A?
I don't think you should try to change how the generated validator
visits objects one approach you might take is as follows. Specialize
org.eclipse.emf.edit.ui.action.ValidateAction.updateSelection(IStructuredSelection)
to determine the collection of objects you want validated given a
collection of actual selected objects. Look closely at the existing
implementation to ensure you follow the same approach. Note in
particular how
org.eclipse.emf.ecore.util.EcoreUtil.filterDescendants(Collection<?
extends EObject>) is called to ensure that the same object isn't
validated more than once. Note that you can use things like
EObject.eAllContents to visit all children generically and you can use
EObject.eCrossReferences to visit all references objects genericall, so
in combination of those two things, you could generically add all
reachable objects; you'll want to be careful that avoid any kind of
infinite recursion...
>
> Here is the example code:
>
> /** * @model annotation="http://www.eclipse.org/emf/2002/Ecore
> constraints='MyConstraint'"
> */
> public interface A {
> /** * @model containment="false"
> */
> public B getB();
>
> /** * @model type="C" containment="false"
> */
> public List getCs();
> }
>
> And another question, independent from the validation thing:
> Suppose I define an "interface A2 extends A", where I would like to
> provide lower and upper bounds to getCs(). If I declare getCs() again
> in A2 with "lower" and "upper" annotations, I get an error message
> "There may not be two features named 'cs'". Is it possible to change
> the multiplicity in a derived class?
No. But of course you can define a named constraint on A2 that would
implement such additional checking.
>
> Thank you
> Franz
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: change generated Validator to ensure that referenced features are valid, too [message #1076507 is a reply to message #1076484] |
Wed, 31 July 2013 13:55 |
Franz Thiele
Messages: 7
Registered: July 2013 |
Junior Member |
|
|
Ed Merks wrote on Wed, 31 July 2013 09:10Franz,
And I'm a bit confused about the actual use case. If B is invalid or
one of the Cs is invalid, does that make A invalid? I suppose not?
How are you invoking validation? Just on A?
In fact, if B or any of the Cs is invalid, A should be shown as invalid.
The use case is the following: I have a somewhat complicated tree of objects, where some (like A) depend on others (like B, C), be it containment or not. A is notified of any change of B and Cs, and as soon as A's information is complete (including valid B and Cs), it will execute further actions.
There is a second way of invoking validation - when the user chooses the "Validate" action from the context menu on an A, it should indicate whether the B and Cs are invalid.
I will check your suggestions using updateSelection() and filterDescendants() and see if I can use them for my purpose.
Thanks
Franz
|
|
|
| Re: change generated Validator to ensure that referenced features are valid, too [message #1076579 is a reply to message #1076507] |
Wed, 31 July 2013 15:47 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Franz,
Comments below.
On 31/07/2013 3:55 PM, Franz Thiele wrote:
> Ed Merks wrote on Wed, 31 July 2013 09:10
>> Franz,
>> And I'm a bit confused about the actual use case. If B is invalid or
>> one of the Cs is invalid, does that make A invalid? I suppose not?
>>
>> How are you invoking validation? Just on A?
>
> In fact, if B or any of the Cs is invalid, A should be shown as invalid.
That seems odd...
> The use case is the following: I have a somewhat complicated tree of
> objects, where some (like A) depend on others (like B, C), be it
> containment or not. A is notified of any change of B and Cs, and as
> soon as A's information is complete (including valid B and Cs), it
> will execute further actions.
Of course you can check the validity of any object(s) any time you want...
> There is a second way of invoking validation - when the user chooses
> the "Validate" action from the context menu on an A, it should
> indicate whether the B and Cs are invalid.
That still seems odd... Even if they were containment references you'd
not get that behavior. With the new to EMF 2.9 decorator support:
http://ed-merks.blogspot.de/2013/01/decorating-with-emf.html
the decorations propagate up the tree, but the actual diagnostic are
specific to the object with the actual problem...
>
> I will check your suggestions using updateSelection() and
> filterDescendants() and see if I can use them for my purpose.
Maybe the new decorator support is helpful for your purposes as well...
>
> Thanks
> Franz
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: change generated Validator to ensure that referenced features are valid, too [message #1076632 is a reply to message #1076579] |
Wed, 31 July 2013 17:15 |
Franz Thiele
Messages: 7
Registered: July 2013 |
Junior Member |
|
|
Ed Merks wrote on Wed, 31 July 2013 11:47
On 31/07/2013 3:55 PM, Franz Thiele wrote:
> Ed Merks wrote on Wed, 31 July 2013 09:10
>> Franz,
>> And I'm a bit confused about the actual use case. If B is invalid or
>> one of the Cs is invalid, does that make A invalid? I suppose not?
>>
>> How are you invoking validation? Just on A?
>
> In fact, if B or any of the Cs is invalid, A should be shown as invalid.
That seems odd...
Please explain, why this seems odd. After reading about your recursive decorators, my use case seems a generalization of those decorators: while I assume that the decorators propagate only markers for contained invalid features up the tree, I need a very similar mechanism that also propagates the markers for non-contained invalid features by following their inverse references.
The reason for the non-containment references is that the same instance B may be referenced by two different instances of A. If an instance B changes, all A's that reference this B, need to react.
Thanks
Franz
|
|
|
| Re: change generated Validator to ensure that referenced features are valid, too [message #1076679 is a reply to message #1076632] |
Wed, 31 July 2013 18:33 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Franz,
Comments below.
On 31/07/2013 7:15 PM, Franz Thiele wrote:
> Ed Merks wrote on Wed, 31 July 2013 11:47
>> On 31/07/2013 3:55 PM, Franz Thiele wrote:
>> > Ed Merks wrote on Wed, 31 July 2013 09:10
>> >> Franz,
>> >> And I'm a bit confused about the actual use case. If B is invalid
>> or >> one of the Cs is invalid, does that make A invalid? I suppose not?
>> >>
>> >> How are you invoking validation? Just on A?
>> >
>> > In fact, if B or any of the Cs is invalid, A should be shown as
>> invalid.
>> That seems odd...
>
> Please explain, why this seems odd.
Consider something like Java. You use class B and C in some other class
A. B and C have errors, but those errors don't show up also as errors
in C where you use A and B, they only show up in A and B because that's
where the error. So in your example, there's nothing the user can do
to fix a problem in A because the problems that are in B and C and
that's where the user's attention needs to be directed to make changes
to make B and C valid.
> After reading about your recursive decorators, my use case seems a
> generalization of those decorators: while I assume that the decorators
> propagate only markers for contained invalid features up the tree, I
> need a very similar mechanism that also propagates the markers for
> non-contained invalid features by following their inverse references.
That will even work if you show B and C as children in your tree, but if
they're not, the user needs to find B and C to fix them so that's where
the markers need to be.
>
> The reason for the non-containment references is that the same
> instance B may be referenced by two different instances of A.
Yes, that makes sense.
> If an instance B changes, all A's that reference this B, need to react.
But if the problem is that B itself is invalid, only B needs attention
and fixing that will fix the only problem that exists.
In any case, perhaps you've describe the problem is such an abstract way
that it's hard to concretely understand how a sea of problem indicators
for all As (perhaps there are a thousand of them) that use a single
invalid B will help direct the user to the one and only problem in B
itself that needs fixing. How the validation information is used to
decorate a tree is completely orthogonal to how many errors there are,
so perhaps you're mixing the to issues. It's not entirely clear...
>
> Thanks
> Franz
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 20:49:50 GMT 2024
Powered by FUDForum. Page generated in 0.03128 seconds |
] 
Search
Help
Register
Login
Home
