Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » ITraversalStrategy breaking 'validation.constraintBindings' ?

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » ITraversalStrategy breaking 'validation.constraintBindings' ?

Show: Today's Messages :: Show Polls :: Message Navigator

ITraversalStrategy breaking 'validation.constraintBindings' ? [message #22464]

Wed, 15 February 2006 17:38

Radomil Dvorak

Messages: 249
Registered: July 2009

Senior Member

Hi,

I have a usecase declaring constraints targeted to a particular EClass but
requiring additional target refinement

based on the EObject instance state. In other words, not every instance of
that type is the appropriate target.

I have tried to use 'validation.constraintBindings' extension point to

define a <clientContext> with <enablement> or custom <selector> enforcing my
specific condition.

This works, but only partly.

It stops working in case I declare multiple constraints bound in different
client contexts and

these constraints are targeted on EClasses whose instances are in the same
validated sub-tree.

The reason is that the default strategy used by IBatchValidator assumes that
only the root elements of the traversal

may be in different client contexts.

I have found all this clearly described in ITraversalStrategy interface and
I understand the reasons for introducing

these 'optimistic' strategies. What only confused me a bit was that my
EObject was checked

during the validation step but no applicable constraints were found.

Of course, I can provide my own 'pessimistic' strategy and everything works
fine, just with the cost of frequent

re-computing of the client context.

But I still have a feeling that this is not the right solution.

Is there any better way how to achieve this?

Regards,

/Radek

Report message to a moderator

Re: ITraversalStrategy breaking 'validation.constraintBindings' ? [message #22639 is a reply to message #22464]

Wed, 15 February 2006 23:03

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi, Radek,

It may actually be more efficient to simply have your constraints filter out
objects that are not of interest to them (simply returning success) than to
implement a strategy that computes the contexts of every object and finds
the associated bindings. The latter is a lot more work for the VM.

I think that you are trying to apply a finer granularity of classification
of objects with the client contexts than what it was intended for. The
intent of the client context is to determine the "client application" that
"owns" an object in a model, where potentially multiple applications might
be using the same Ecore-defined metamodel in different ways. For example,
multiple applications using the org.eclipse.uml2 metamodel in the same
workbench; one for all-out UML modeling and one for displaying Java
execution traces using sequence diagrams (as in the Hyades profiler).
These applications might have very different requirements for validation of
models: classic well-formedness rules for the modeling application and
performance bottle-neck detection in the profiler.

In your case, you are trying to apply multiple contexts to the same
application. I don't think that will work very well (as you are seeing).

Cheers,

Christian

Radek Dvorak wrote:

> Hi,
>
>
>
> I have a usecase declaring constraints targeted to a particular EClass but
> requiring additional target refinement
>
> based on the EObject instance state. In other words, not every instance of
> that type is the appropriate target.
>
>
>
> I have tried to use 'validation.constraintBindings' extension point to
>
> define a <clientContext> with <enablement> or custom <selector> enforcing
> my specific condition.
>
> This works, but only partly.
>
>
>
> It stops working in case I declare multiple constraints bound in different
> client contexts and
>
> these constraints are targeted on EClasses whose instances are in the same
> validated sub-tree.
>
> The reason is that the default strategy used by IBatchValidator assumes
> that only the root elements of the traversal
>
> may be in different client contexts.
>
>
>
> I have found all this clearly described in ITraversalStrategy interface
> and I understand the reasons for introducing
>
> these 'optimistic' strategies. What only confused me a bit was that my
> EObject was checked
>
> during the validation step but no applicable constraints were found.
>
>
>
> Of course, I can provide my own 'pessimistic' strategy and everything
> works fine, just with the cost of frequent
>
> re-computing of the client context.
>
> But I still have a feeling that this is not the right solution.
>
>
>
> Is there any better way how to achieve this?
>
>
>
> Regards,
>
> /Radek

Report message to a moderator

Re: ITraversalStrategy breaking 'validation.constraintBindings' ? [message #22944 is a reply to message #22639]

Thu, 16 February 2006 14:04

Radomil Dvorak

Messages: 249
Registered: July 2009

Senior Member

Hi Christian,

Thanks for the reply.
Clearly, I had that strange feeling that this would be a misuse of client
contexts for too fine granularity.
I only favoured the declarative way over programming first ;-)
Yes, I was thinking about adding the filtering capability to the constraint
itself but there are some complications.

Just few words to clarify my scenario as it might seem a bit untypical
usecase for EMFT validation.
I want to specify audit constraints on diagram notation model elements in
GMF project.
In order to target these constraints to a specific type of diagram I define
the (root) client context with
custom selector, which binds these constraints only to the required diagram
type.
I think conceptually this fits to the client contexts area well, as all
diagram types use the same Ecore-defined notation
metamodel and represent a self-contained client application with its own
aspects for validation.
The finer granularity here is targeting a diagram notation element
encapsulating specific
bussiness model element mapped for visualization.

As for the filtering aware constraint, I did not want to introduce the
selector condition into the constraint validation
logic defined by the GMF client as such condition rather belongs to
internals and may not be language independent.
Then a better option seems to be providing a filtering adapter constraint
delegating the real constraint.
This is probably not feasible as all declared constraints are bound to
either explicit context or default context if there is one.
It looks like there is nothing like detached constraints whose instances can
be retrieved from the validation framework
programmatically. They also all appear at minimum in the default category.

Would be nice to have analogy of optional (enablement | selector) also in
the constraint descriptor, simply extending the logic implemented
by 'boolean IConstraintDescriptor.targetsTypeOf(EObject eObject)'.
On the other hand I understand that this can be considered a minor usecase.

Regards,
/Radek

"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:dt0bvq$60a$1@utils.eclipse.org...
> Hi, Radek,
>
> It may actually be more efficient to simply have your constraints filter
> out
> objects that are not of interest to them (simply returning success) than
> to
> implement a strategy that computes the contexts of every object and finds
> the associated bindings. The latter is a lot more work for the VM.
>
> I think that you are trying to apply a finer granularity of classification
> of objects with the client contexts than what it was intended for. The
> intent of the client context is to determine the "client application" that
> "owns" an object in a model, where potentially multiple applications might
> be using the same Ecore-defined metamodel in different ways. For example,
> multiple applications using the org.eclipse.uml2 metamodel in the same
> workbench; one for all-out UML modeling and one for displaying Java
> execution traces using sequence diagrams (as in the Hyades profiler).
> These applications might have very different requirements for validation
> of
> models: classic well-formedness rules for the modeling application and
> performance bottle-neck detection in the profiler.
>
> In your case, you are trying to apply multiple contexts to the same
> application. I don't think that will work very well (as you are seeing).
>
> Cheers,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi,
>>
>>
>>
>> I have a usecase declaring constraints targeted to a particular EClass
>> but
>> requiring additional target refinement
>>
>> based on the EObject instance state. In other words, not every instance
>> of
>> that type is the appropriate target.
>>
>>
>>
>> I have tried to use 'validation.constraintBindings' extension point to
>>
>> define a <clientContext> with <enablement> or custom <selector> enforcing
>> my specific condition.
>>
>> This works, but only partly.
>>
>>
>>
>> It stops working in case I declare multiple constraints bound in
>> different
>> client contexts and
>>
>> these constraints are targeted on EClasses whose instances are in the
>> same
>> validated sub-tree.
>>
>> The reason is that the default strategy used by IBatchValidator assumes
>> that only the root elements of the traversal
>>
>> may be in different client contexts.
>>
>>
>>
>> I have found all this clearly described in ITraversalStrategy interface
>> and I understand the reasons for introducing
>>
>> these 'optimistic' strategies. What only confused me a bit was that my
>> EObject was checked
>>
>> during the validation step but no applicable constraints were found.
>>
>>
>>
>> Of course, I can provide my own 'pessimistic' strategy and everything
>> works fine, just with the cost of frequent
>>
>> re-computing of the client context.
>>
>> But I still have a feeling that this is not the right solution.
>>
>>
>>
>> Is there any better way how to achieve this?
>>
>>
>>
>> Regards,
>>
>> /Radek
>

Report message to a moderator

Re: ITraversalStrategy breaking 'validation.constraintBindings' ? [message #23074 is a reply to message #22944]

Thu, 16 February 2006 14:40

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Hi, Radek,

I think I better understand your situation, now (you may be the judge of
that).

Your usage of client contexts, here, does seem quite reasonable, as it
matches exactly the criteria that I outlined vis-a-vis different clients'
usage of a shared metamodel.

You can avoid recomputing the contexts for every element in the sub-tree if
you know how to detect the boundaries between client contexts. For this
purpose, the ITraversalStrategy interface defines an
isClientContextChanged() query method to detect these boundaries. Perhaps
you can implement a custom traversal strategy to implement this query? It
may not be practical to register it statically against the notation
meta-model if it isn't appropriate for every possible GMF client
application, but you can assign it to the IBatchValidator that you use for
auditing.

HTH,

Christian

Radek Dvorak wrote:

> Hi Christian,
>
> Thanks for the reply.
> Clearly, I had that strange feeling that this would be a misuse of client
> contexts for too fine granularity.
> I only favoured the declarative way over programming first ;-)
> Yes, I was thinking about adding the filtering capability to the
> constraint itself but there are some complications.
>
> Just few words to clarify my scenario as it might seem a bit untypical
> usecase for EMFT validation.
> I want to specify audit constraints on diagram notation model elements in
> GMF project.
> In order to target these constraints to a specific type of diagram I
> define the (root) client context with
> custom selector, which binds these constraints only to the required
> diagram type.
> I think conceptually this fits to the client contexts area well, as all
> diagram types use the same Ecore-defined notation
> metamodel and represent a self-contained client application with its own
> aspects for validation.
> The finer granularity here is targeting a diagram notation element
> encapsulating specific
> bussiness model element mapped for visualization.
>
> As for the filtering aware constraint, I did not want to introduce the
> selector condition into the constraint validation
> logic defined by the GMF client as such condition rather belongs to
> internals and may not be language independent.
> Then a better option seems to be providing a filtering adapter constraint
> delegating the real constraint.
> This is probably not feasible as all declared constraints are bound to
> either explicit context or default context if there is one.
> It looks like there is nothing like detached constraints whose instances
> can be retrieved from the validation framework
> programmatically. They also all appear at minimum in the default category.
>
> Would be nice to have analogy of optional (enablement | selector) also in
> the constraint descriptor, simply extending the logic implemented
> by 'boolean IConstraintDescriptor.targetsTypeOf(EObject eObject)'.
> On the other hand I understand that this can be considered a minor
> usecase.
>
> Regards,
> /Radek

<snip>

Report message to a moderator

Re: ITraversalStrategy breaking 'validation.constraintBindings' ? [message #23116 is a reply to message #23074]

Thu, 16 February 2006 16:37

Radomil Dvorak

Messages: 249
Registered: July 2009

Senior Member

Hi Christian,

Thanks for getting me on this direction. I think controlling the client
context switching by
traversal strategy could work for me.

If I got this right, I would switch between contexts for:
1) diagram type specific notation elements with affinity to its bussiness
(visualized) element
(there could be several such client contexts, one per semantic type of
the bussiness element)
2) diagram type specific notation elements only, all handled equally

I also guess that all globally shared validation aspects on diagram notation
elements would be included with each
client context recomputation as well.
That is all I wanted.

Thanks&regards,
/Radek

"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:dt22rr$npk$1@utils.eclipse.org...
>
> Hi, Radek,
>
> I think I better understand your situation, now (you may be the judge of
> that).
>
> Your usage of client contexts, here, does seem quite reasonable, as it
> matches exactly the criteria that I outlined vis-a-vis different clients'
> usage of a shared metamodel.
>
> You can avoid recomputing the contexts for every element in the sub-tree
> if
> you know how to detect the boundaries between client contexts. For this
> purpose, the ITraversalStrategy interface defines an
> isClientContextChanged() query method to detect these boundaries. Perhaps
> you can implement a custom traversal strategy to implement this query? It
> may not be practical to register it statically against the notation
> meta-model if it isn't appropriate for every possible GMF client
> application, but you can assign it to the IBatchValidator that you use for
> auditing.
>
> HTH,
>
> Christian
>
>
> Radek Dvorak wrote:
>
>> Hi Christian,
>>
>> Thanks for the reply.
>> Clearly, I had that strange feeling that this would be a misuse of client
>> contexts for too fine granularity.
>> I only favoured the declarative way over programming first ;-)
>> Yes, I was thinking about adding the filtering capability to the
>> constraint itself but there are some complications.
>>
>> Just few words to clarify my scenario as it might seem a bit untypical
>> usecase for EMFT validation.
>> I want to specify audit constraints on diagram notation model elements in
>> GMF project.
>> In order to target these constraints to a specific type of diagram I
>> define the (root) client context with
>> custom selector, which binds these constraints only to the required
>> diagram type.
>> I think conceptually this fits to the client contexts area well, as all
>> diagram types use the same Ecore-defined notation
>> metamodel and represent a self-contained client application with its own
>> aspects for validation.
>> The finer granularity here is targeting a diagram notation element
>> encapsulating specific
>> bussiness model element mapped for visualization.
>>
>> As for the filtering aware constraint, I did not want to introduce the
>> selector condition into the constraint validation
>> logic defined by the GMF client as such condition rather belongs to
>> internals and may not be language independent.
>> Then a better option seems to be providing a filtering adapter constraint
>> delegating the real constraint.
>> This is probably not feasible as all declared constraints are bound to
>> either explicit context or default context if there is one.
>> It looks like there is nothing like detached constraints whose instances
>> can be retrieved from the validation framework
>> programmatically. They also all appear at minimum in the default
>> category.
>>
>> Would be nice to have analogy of optional (enablement | selector) also in
>> the constraint descriptor, simply extending the logic implemented
>> by 'boolean IConstraintDescriptor.targetsTypeOf(EObject eObject)'.
>> On the other hand I understand that this can be considered a minor
>> usecase.
>>
>> Regards,
>> /Radek
>
> <snip>
>

Report message to a moderator

Re: ITraversalStrategy breaking 'validation.constraintBindings' ? [message #23197 is a reply to message #23116]

Thu, 16 February 2006 17:39

Eclipse User

Originally posted by: cdamus.ca.ibm.com

Radek Dvorak wrote:

> Hi Christian,
>
> Thanks for getting me on this direction. I think controlling the client
> context switching by
> traversal strategy could work for me.

Good! I hope it does.

> If I got this right, I would switch between contexts for:
> 1) diagram type specific notation elements with affinity to its bussiness
> (visualized) element
> (there could be several such client contexts, one per semantic type of
> the bussiness element)

Hopefully, for this case, the structure of the business model will imply
continuity of contexts so that you don't end up recomputing the contexts
frequently.

> 2) diagram type specific notation elements only, all handled equally
>
> I also guess that all globally shared validation aspects on diagram
> notation elements would be included with each
> client context recomputation as well.

They should be, because every recomputation of contexts is "clean" (from
scratch).

> That is all I wanted.

Good luck with it. Do follow up again if you run into more snags (esp. of
the performance variety).

cW

>
> Thanks&regards,
> /Radek
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:dt22rr$npk$1@utils.eclipse.org...
>>
>> Hi, Radek,
>>
>> I think I better understand your situation, now (you may be the judge of
>> that).
>>
>> Your usage of client contexts, here, does seem quite reasonable, as it
>> matches exactly the criteria that I outlined vis-a-vis different clients'
>> usage of a shared metamodel.
>>
>> You can avoid recomputing the contexts for every element in the sub-tree
>> if
>> you know how to detect the boundaries between client contexts. For this
>> purpose, the ITraversalStrategy interface defines an
>> isClientContextChanged() query method to detect these boundaries.
>> Perhaps
>> you can implement a custom traversal strategy to implement this query?
>> It may not be practical to register it statically against the notation
>> meta-model if it isn't appropriate for every possible GMF client
>> application, but you can assign it to the IBatchValidator that you use
>> for auditing.
>>
>> HTH,
>>
>> Christian
>>

<snip>

Report message to a moderator