Home » Modeling » GMF (Graphical Modeling Framework) » RE: Boris Blajer "LinkMap constraint not get evaluated at runtime"
| RE: Boris Blajer "LinkMap constraint not get evaluated at runtime" [message #68269] |
Mon, 23 October 2006 17:48  |
Eclipse User |
|
|
|
Originally posted by: greenl.mot.com
What if I need to identify whether a link can be created depend on both
source and target of the link? e.g. Both source and target should have the
same attribute value at runtime, say source.parent == target.parent ?
"Boris Blajer" <boris.blajer@borland.com> wrote in message
news:egvcm1$rgc$1@utils.eclipse.org...
> Hi Green,
>
> LinkMapping constraint is a constraint that allows one to differentiate
> between several element types which are bound to the same domain model
> EClass. E.g., in the MindMap example, there are three links bound to the
> domain EClass Relationship, but their visual aspects are different based
> on
> the value of the feature Relationship::type.
>
> These constraints are rarely, if at all, evaluated at creation time, but
> are
> evaluated by, e.g., XXXCanonicalEditPolicy to find out which element (or
> element with which visualID) to create when an underlying model element is
> created.
>
> In contrast, LinkConstraints element and its direct children, Source End
> Constraint and Target End Constraint are creation constraints. They are
> used
> at creation time to disable creation of links if a link violates any of
> the
> given constraints.
>
> Best regards,
> Boris
>
>
> "Green Law" <greenl@mot.com> wrote in message
> news:egtpcc$395$1@utils.eclipse.org...
>>I found my LinkMap constraint (C1) was not evaluated at runtime, while my
>>Source End Constraint (C2) and Target End Constraint (C3) did get
>>evaluated.
>>
>> I searched the code and found the expression of C1 was copied to a
>> generated file named XXXVisualIDRegistry.java while C2 and C3 was copied
>> to a generated file named XXXBaseItemSemanticEditPolicy.java. I wonder
>> why
>> there are this sort of difference and hope you guys can give me some
>> hints.
>>
>> Thanks,
>> Green
>>
>
>
|
|
|
| Re: Boris Blajer "LinkMap constraint not get evaluated at runtime" [message #68398 is a reply to message #68269] |
Tue, 24 October 2006 05:25  |
| Eclipse User |
|
|
|
Hi Green,
This post might be useful for you.
http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/m sg01225.html
Regards,
/Radek
"Green Law" <greenl@mot.com> wrote in message
news:ehjdc5$vt$1@utils.eclipse.org...
> What if I need to identify whether a link can be created depend on both
> source and target of the link? e.g. Both source and target should have the
> same attribute value at runtime, say source.parent == target.parent ?
>
> "Boris Blajer" <boris.blajer@borland.com> wrote in message
> news:egvcm1$rgc$1@utils.eclipse.org...
>> Hi Green,
>>
>> LinkMapping constraint is a constraint that allows one to differentiate
>> between several element types which are bound to the same domain model
>> EClass. E.g., in the MindMap example, there are three links bound to the
>> domain EClass Relationship, but their visual aspects are different based
>> on
>> the value of the feature Relationship::type.
>>
>> These constraints are rarely, if at all, evaluated at creation time, but
>> are
>> evaluated by, e.g., XXXCanonicalEditPolicy to find out which element (or
>> element with which visualID) to create when an underlying model element
>> is
>> created.
>>
>> In contrast, LinkConstraints element and its direct children, Source End
>> Constraint and Target End Constraint are creation constraints. They are
>> used
>> at creation time to disable creation of links if a link violates any of
>> the
>> given constraints.
>>
>> Best regards,
>> Boris
>>
>>
>> "Green Law" <greenl@mot.com> wrote in message
>> news:egtpcc$395$1@utils.eclipse.org...
>>>I found my LinkMap constraint (C1) was not evaluated at runtime, while my
>>>Source End Constraint (C2) and Target End Constraint (C3) did get
>>>evaluated.
>>>
>>> I searched the code and found the expression of C1 was copied to a
>>> generated file named XXXVisualIDRegistry.java while C2 and C3 was copied
>>> to a generated file named XXXBaseItemSemanticEditPolicy.java. I wonder
>>> why
>>> there are this sort of difference and hope you guys can give me some
>>> hints.
>>>
>>> Thanks,
>>> Green
>>>
>>
>>
>
>
|
|
|
| Re: Boris Blajer "LinkMap constraint not get evaluated at runtime" [message #68407 is a reply to message #68269] |
Tue, 24 October 2006 05:33 |
| Eclipse User |
|
|
|
Hi Green,
In this case, you should use LinkConstraints and define Target End
Constraint. The "self" will refer to the target end, while the predefined
"oppositeEnd" var will refer to the source end. Thus, the OCL should look
something like
self.parent = oppositeEnd.parent
Likewise, you may use Source End Constraint (in this case, "self" will refer
to the source end, "oppositeEnd" will refer to the target end), but you
should be prepared to handle the case when oppositeEnd will be
..oclIsUndefined().
Best regards,
Boris
"Green Law" <greenl@mot.com> wrote in message
news:ehjdc5$vt$1@utils.eclipse.org...
> What if I need to identify whether a link can be created depend on both
> source and target of the link? e.g. Both source and target should have the
> same attribute value at runtime, say source.parent == target.parent ?
>
> "Boris Blajer" <boris.blajer@borland.com> wrote in message
> news:egvcm1$rgc$1@utils.eclipse.org...
>> Hi Green,
>>
>> LinkMapping constraint is a constraint that allows one to differentiate
>> between several element types which are bound to the same domain model
>> EClass. E.g., in the MindMap example, there are three links bound to the
>> domain EClass Relationship, but their visual aspects are different based
>> on
>> the value of the feature Relationship::type.
>>
>> These constraints are rarely, if at all, evaluated at creation time, but
>> are
>> evaluated by, e.g., XXXCanonicalEditPolicy to find out which element (or
>> element with which visualID) to create when an underlying model element
>> is
>> created.
>>
>> In contrast, LinkConstraints element and its direct children, Source End
>> Constraint and Target End Constraint are creation constraints. They are
>> used
>> at creation time to disable creation of links if a link violates any of
>> the
>> given constraints.
>>
>> Best regards,
>> Boris
>>
>>
>> "Green Law" <greenl@mot.com> wrote in message
>> news:egtpcc$395$1@utils.eclipse.org...
>>>I found my LinkMap constraint (C1) was not evaluated at runtime, while my
>>>Source End Constraint (C2) and Target End Constraint (C3) did get
>>>evaluated.
>>>
>>> I searched the code and found the expression of C1 was copied to a
>>> generated file named XXXVisualIDRegistry.java while C2 and C3 was copied
>>> to a generated file named XXXBaseItemSemanticEditPolicy.java. I wonder
>>> why
>>> there are this sort of difference and hope you guys can give me some
>>> hints.
>>>
>>> Thanks,
>>> Green
>>>
>>
>>
>
>
|
|
|
| Re: Boris Blajer "LinkMap constraint not get evaluated at runtime" [message #68493 is a reply to message #68407] |
Tue, 24 October 2006 08:44 |
| Eclipse User |
|
|
|
Originally posted by: greenl.mot.com
This is the exact way to make it work!
Thank you, Boris!
"Boris Blajer" <boris.blajer@borland.com> wrote in message
news:ehkml2$rpv$1@utils.eclipse.org...
> Hi Green,
>
> In this case, you should use LinkConstraints and define Target End
> Constraint. The "self" will refer to the target end, while the predefined
> "oppositeEnd" var will refer to the source end. Thus, the OCL should look
> something like
>
> self.parent = oppositeEnd.parent
>
> Likewise, you may use Source End Constraint (in this case, "self" will
> refer to the source end, "oppositeEnd" will refer to the target end), but
> you should be prepared to handle the case when oppositeEnd will be
> .oclIsUndefined().
>
> Best regards,
> Boris
>
> "Green Law" <greenl@mot.com> wrote in message
> news:ehjdc5$vt$1@utils.eclipse.org...
>> What if I need to identify whether a link can be created depend on both
>> source and target of the link? e.g. Both source and target should have
>> the same attribute value at runtime, say source.parent == target.parent ?
>>
>> "Boris Blajer" <boris.blajer@borland.com> wrote in message
>> news:egvcm1$rgc$1@utils.eclipse.org...
>>> Hi Green,
>>>
>>> LinkMapping constraint is a constraint that allows one to differentiate
>>> between several element types which are bound to the same domain model
>>> EClass. E.g., in the MindMap example, there are three links bound to the
>>> domain EClass Relationship, but their visual aspects are different based
>>> on
>>> the value of the feature Relationship::type.
>>>
>>> These constraints are rarely, if at all, evaluated at creation time, but
>>> are
>>> evaluated by, e.g., XXXCanonicalEditPolicy to find out which element (or
>>> element with which visualID) to create when an underlying model element
>>> is
>>> created.
>>>
>>> In contrast, LinkConstraints element and its direct children, Source End
>>> Constraint and Target End Constraint are creation constraints. They are
>>> used
>>> at creation time to disable creation of links if a link violates any of
>>> the
>>> given constraints.
>>>
>>> Best regards,
>>> Boris
>>>
>>>
>>> "Green Law" <greenl@mot.com> wrote in message
>>> news:egtpcc$395$1@utils.eclipse.org...
>>>>I found my LinkMap constraint (C1) was not evaluated at runtime, while
>>>>my
>>>>Source End Constraint (C2) and Target End Constraint (C3) did get
>>>>evaluated.
>>>>
>>>> I searched the code and found the expression of C1 was copied to a
>>>> generated file named XXXVisualIDRegistry.java while C2 and C3 was
>>>> copied
>>>> to a generated file named XXXBaseItemSemanticEditPolicy.java. I wonder
>>>> why
>>>> there are this sort of difference and hope you guys can give me some
>>>> hints.
>>>>
>>>> Thanks,
>>>> Green
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Boris Blajer "LinkMap constraint not get evaluated at runtime" [message #69495 is a reply to message #68407] |
Wed, 25 October 2006 13:10 |
| Eclipse User |
|
|
|
Originally posted by: greenl.mot.com
Hi, Boris
It seems NodeMapping does not have so called NodeConstraints to help you
identify whether a Node can be created in certain context or not. I write my
OCL constraints in Constraint child of a NodeMapping, but it doesn't work.
Do you have any idea?
Thanks,
Green
"Boris Blajer" <boris.blajer@borland.com> wrote in message
news:ehkml2$rpv$1@utils.eclipse.org...
> Hi Green,
>
> In this case, you should use LinkConstraints and define Target End
> Constraint. The "self" will refer to the target end, while the predefined
> "oppositeEnd" var will refer to the source end. Thus, the OCL should look
> something like
>
> self.parent = oppositeEnd.parent
>
> Likewise, you may use Source End Constraint (in this case, "self" will
> refer to the source end, "oppositeEnd" will refer to the target end), but
> you should be prepared to handle the case when oppositeEnd will be
> .oclIsUndefined().
>
> Best regards,
> Boris
>
> "Green Law" <greenl@mot.com> wrote in message
> news:ehjdc5$vt$1@utils.eclipse.org...
>> What if I need to identify whether a link can be created depend on both
>> source and target of the link? e.g. Both source and target should have
>> the same attribute value at runtime, say source.parent == target.parent ?
>>
>> "Boris Blajer" <boris.blajer@borland.com> wrote in message
>> news:egvcm1$rgc$1@utils.eclipse.org...
>>> Hi Green,
>>>
>>> LinkMapping constraint is a constraint that allows one to differentiate
>>> between several element types which are bound to the same domain model
>>> EClass. E.g., in the MindMap example, there are three links bound to the
>>> domain EClass Relationship, but their visual aspects are different based
>>> on
>>> the value of the feature Relationship::type.
>>>
>>> These constraints are rarely, if at all, evaluated at creation time, but
>>> are
>>> evaluated by, e.g., XXXCanonicalEditPolicy to find out which element (or
>>> element with which visualID) to create when an underlying model element
>>> is
>>> created.
>>>
>>> In contrast, LinkConstraints element and its direct children, Source End
>>> Constraint and Target End Constraint are creation constraints. They are
>>> used
>>> at creation time to disable creation of links if a link violates any of
>>> the
>>> given constraints.
>>>
>>> Best regards,
>>> Boris
>>>
>>>
>>> "Green Law" <greenl@mot.com> wrote in message
>>> news:egtpcc$395$1@utils.eclipse.org...
>>>>I found my LinkMap constraint (C1) was not evaluated at runtime, while
>>>>my
>>>>Source End Constraint (C2) and Target End Constraint (C3) did get
>>>>evaluated.
>>>>
>>>> I searched the code and found the expression of C1 was copied to a
>>>> generated file named XXXVisualIDRegistry.java while C2 and C3 was
>>>> copied
>>>> to a generated file named XXXBaseItemSemanticEditPolicy.java. I wonder
>>>> why
>>>> there are this sort of difference and hope you guys can give me some
>>>> hints.
>>>>
>>>> Thanks,
>>>> Green
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Boris Blajer "LinkMap constraint not get evaluated at runtime" [message #69703 is a reply to message #69495] |
Thu, 26 October 2006 05:17 |
| Eclipse User |
|
|
|
Hi Green,
You are right. NodeMappings do not currently define creation constraints.
Moreover, creation constraints for link operate only with source and target,
not container. Probably, it could make sense to define creation constraints
that could veto the creation of an element based solely on the state of the
container (and therefore be a property of MappingEntry.
Could you please file an enhancement request?
Best regards,
Boris
"Green Law" <greenl@mot.com> wrote in message
news:eho5q5$qt1$1@utils.eclipse.org...
> Hi, Boris
>
> It seems NodeMapping does not have so called NodeConstraints to help you
> identify whether a Node can be created in certain context or not. I write
> my OCL constraints in Constraint child of a NodeMapping, but it doesn't
> work.
>
> Do you have any idea?
>
> Thanks,
> Green
>
> "Boris Blajer" <boris.blajer@borland.com> wrote in message
> news:ehkml2$rpv$1@utils.eclipse.org...
>> Hi Green,
>>
>> In this case, you should use LinkConstraints and define Target End
>> Constraint. The "self" will refer to the target end, while the
>> predefined "oppositeEnd" var will refer to the source end. Thus, the OCL
>> should look something like
>>
>> self.parent = oppositeEnd.parent
>>
>> Likewise, you may use Source End Constraint (in this case, "self" will
>> refer to the source end, "oppositeEnd" will refer to the target end), but
>> you should be prepared to handle the case when oppositeEnd will be
>> .oclIsUndefined().
>>
>> Best regards,
>> Boris
>>
>> "Green Law" <greenl@mot.com> wrote in message
>> news:ehjdc5$vt$1@utils.eclipse.org...
>>> What if I need to identify whether a link can be created depend on both
>>> source and target of the link? e.g. Both source and target should have
>>> the same attribute value at runtime, say source.parent == target.parent
>>> ?
>>>
>>> "Boris Blajer" <boris.blajer@borland.com> wrote in message
>>> news:egvcm1$rgc$1@utils.eclipse.org...
>>>> Hi Green,
>>>>
>>>> LinkMapping constraint is a constraint that allows one to differentiate
>>>> between several element types which are bound to the same domain model
>>>> EClass. E.g., in the MindMap example, there are three links bound to
>>>> the
>>>> domain EClass Relationship, but their visual aspects are different
>>>> based on
>>>> the value of the feature Relationship::type.
>>>>
>>>> These constraints are rarely, if at all, evaluated at creation time,
>>>> but are
>>>> evaluated by, e.g., XXXCanonicalEditPolicy to find out which element
>>>> (or
>>>> element with which visualID) to create when an underlying model element
>>>> is
>>>> created.
>>>>
>>>> In contrast, LinkConstraints element and its direct children, Source
>>>> End
>>>> Constraint and Target End Constraint are creation constraints. They are
>>>> used
>>>> at creation time to disable creation of links if a link violates any of
>>>> the
>>>> given constraints.
>>>>
>>>> Best regards,
>>>> Boris
>>>>
>>>>
>>>> "Green Law" <greenl@mot.com> wrote in message
>>>> news:egtpcc$395$1@utils.eclipse.org...
>>>>>I found my LinkMap constraint (C1) was not evaluated at runtime, while
>>>>>my
>>>>>Source End Constraint (C2) and Target End Constraint (C3) did get
>>>>>evaluated.
>>>>>
>>>>> I searched the code and found the expression of C1 was copied to a
>>>>> generated file named XXXVisualIDRegistry.java while C2 and C3 was
>>>>> copied
>>>>> to a generated file named XXXBaseItemSemanticEditPolicy.java. I wonder
>>>>> why
>>>>> there are this sort of difference and hope you guys can give me some
>>>>> hints.
>>>>>
>>>>> Thanks,
>>>>> Green
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Sun Jul 13 20:47:24 EDT 2025
Powered by FUDForum. Page generated in 0.05340 seconds |
Home