Home » Modeling » EMF » [EMF] [Validation] Possible bug in getTraversalStrategy method
|
| Re: [EMF] [Validation] Possible bug in getTraversalStrategy method [message #1508491 is a reply to message #1508424] |
Fri, 12 December 2014 13:08   |
|
Hi, Leonid,
This was, indeed, the original intention of the "traversal strategies":
that they handle a metamodel's peculiar needs. The expectation is
that the root of the content tree indicates the metamodel to which a
model generally conforms (in the case that it actually has
non-homogeneous content). The idea was to avoid computing traversal
strategies on every object during a traversal, as otherwise it would
open up possibilities for conflicts: what if we miss an object that
one strategy would have covered because we switched to another? Or
what if we covered an object multiple times because traversals from
different objects reached it?
So, I could say it is a bug and it is the intended behaviour, but it
may not be the most desirable behaviour. Probably there is still room
for determining junction points in a content tree where content from
different metamodels is mixed (something not unlike the "trigger
points" and "possible children" concepts in the Common Navigator
Framework) and where it is appropriate to switch traversal strategies.
IMHO, it is almost never inappropriate to file a bugzilla request.
Especially if it is accompanied by a well-considered contribution of
code. :-)
Cheers,
Christian
On 2014-12-12 11:52:37 +0000, Leonid Ripeynih said:
> Hello!
> I'm trying to contribute a special traversal strategy for some of my
> EObjects. I have provided an extension to '' extension point, but
> contributed strategy did not getting invoked. I looked into the source
> code of TraversalStrategyManager and found a following fragment:
>
>
> public ITraversalStrategy getTraversalStrategy(EObject eObject) {
> EObject root = EcoreUtil.getRootContainer(eObject);
> String nsUri = root.eClass().getEPackage().getNsURI();
> return getDescriptor(nsUri).getStrategy(root);
> }
>
>
> It seems to me it contains a bug - getStrategy should be called with
> passed eObject, as a descriptor contains a mapping between eClass and
> traversal strategy. As of now it always returns traversal strategy for
> hierarchy root.
> The question is - is it a bug, or desired behavior? Should I file
> bugzilla on it?
>
> Thanks in advance for you attention.
|
|
|
| Re: [EMF] [Validation] Possible bug in getTraversalStrategy method [message #1508538 is a reply to message #1508491] |
Fri, 12 December 2014 13:53 |
 Leonid Ripeynih
Messages: 150
Registered: February 2012 |
Senior Member |
|
|
Christian, thank you for your answer!
Can you please, give me a suggestion on how to handle the following use-case with validation framework:
I have a model with a model-specific notation of include. It looks something like this (XML syntax):
<root>
<object id="1"/>
<includes>
<include uri='path/to/included/model.xml'/>
<include uri='path/to/included/model2.xml'/>
</includes>
</root>
As you can see, model can include another model (and model can be included in multiple aggregates).
Then validating such a model, root should be validated along with includes - so initially i thought on plugging-in custom traversal strategy for <includes> element - which will return the included resource contents, and not the include elements themselves. Alternative approach, which I'm considering right now - is pre-iterating over a model, collecting all includes, resolving it, and passing the resulting list of resources to validation framework. The downside of this approach, is that it requires a custom preparation, and I cannot just grab selected (for example) object and pass it to valuator - I need to prepare the validation scope myself. Is it how it's supposed to be, or is there a more elegant solution?
[Updated on: Fri, 12 December 2014 13:54] Report message to a moderator |
|
|
| Re: [EMF] [Validation] Possible bug in getTraversalStrategy method [message #1508592 is a reply to message #1508538] |
Fri, 12 December 2014 14:40 |
|
Hi, Leonid,
It is definitely not intended that clients of validation should have to
worry about where to find elements to be included in the validation
operation: that's precisely why we have the traversal strategy
mechanism. :-) After all, the "client" could just be a plug-in that
contributes a "Validate" context menu action globally, without any
awareness of what kinds of models it operates on.
The canonical use case for traversal strategy in the beginning was
stereotype applications in UML models: they are not in the same tree
as the UML content, but when validating a UML element, the expectation
is that its stereotype applications would be validated, too. So, a
traversal strategy for UML includes the stereotype applications of each
element that it visits in the tree being validated.
Can you not associate a traversal strategy with the <root> element,
which then can be aware of the includes to reach into the referenced
resources? This strategy would just implement the usual recursive
descent for other objects, with a special case for the <include>.
HTH,
Christian
On 2014-12-12 13:53:51 +0000, Leonid Ripeynih said:
> Christian, thank you for your answer!
>
> Can you please, give me a suggestion on how to handle the following
> use-case with validation framework:
> I have a model with a model-specific notation of include. It looks
> something like this (XML syntax):
>
> [/code]
> <root>
> <object id="1"/>
> <includes>
> <include uri='path/to/included/model.xml'/>
> <include uri='path/to/included/model2.xml'/>
> </includes>
> </root>
> [/code]
>
> As you can see, model can include another model (and model can be
> included in multiple aggregates).
> Then validating such a model, root should be validated along with
> includes - so initially i thought on plugging-in custom traversal
> strategy for <includes> element - which will return the included
> resource contents, and not the include elements themselves. Alternative
> approach, which I'm considering right now - is pre-iterating over a
> model, collecting all includes, resolving it, and passing the resulting
> list of resources to validation framework. The downside of this
> approach, is that it requires a custom preparation, and I cannot just
> grab selected (for example) object and pass it to valuator - I need to
> prepare the validation scope myself. Is it how it's supposed to be, or
> is there a more elegant solution?
|
|
|
Goto Forum:
Current Time: Thu Apr 25 08:12:57 GMT 2024
Powered by FUDForum. Page generated in 0.03289 seconds |
] 
Search
Help
Register
Login
Home
