Home » Modeling » GMF (Graphical Modeling Framework) » UUIDConstraint
| UUIDConstraint [message #193105] |
Tue, 17 June 2008 15:01  |
Eclipse User |
|
|
|
Originally posted by: laurent.legoff.geensys.com
Hi,
I have problem with this mandatory constraint defined in
gmf.runtime.emf.core.
First if I didn't use GMF at all but have gmf installed in my workspace,
the model validation return error constraint, because my objects in my
model doesn't have constant id or uuid.
Second we will use GMF and we will use it on our developpement with
CommonNavigator and the EMF transaction (workspace implementation). We
will use a global TransactionalEditingDomain, that have to be the gmf
implementation if we want to use diagram, this is a big dependency to
have in our implementation. The problem is :
the file format of our model is frozen (xml files validated by a
standardized xsd), and if we look at this UUIDConstraint I can see that
gmf core impose a big constraint that all object of a model instance
must have a unique id (an id that never change).
Actually we cannot return a UUID for all objects in a model.
How can we use gmf with a model that haven't uuid?
Why this uuid constraint ?
what happens when getId of XMLResource return a variable id (typically a
reference calculated with the concatenation of name of the aggregate tree)?
Actually we prototype an editor with a global EditingDomain, this in
facts implies that GMF editor doesn't need to load any kink of model
resource (because resources are already loaded and a diagram can display
information of n resources).
How can I solve these problems ?
cordially,
laurent
|
|
|
| Re: UUIDConstraint [message #193365 is a reply to message #193105] |
Wed, 18 June 2008 23:18  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Laurent,
Domain models themselves shouldn't be required to have a unique ID. I
know the GMF editor for Ecore works well and Ecore doesn't specify IDs...
Laurent Le Goff wrote:
> Hi,
> I have problem with this mandatory constraint defined in
> gmf.runtime.emf.core.
>
> First if I didn't use GMF at all but have gmf installed in my
> workspace, the model validation return error constraint, because my
> objects in my model doesn't have constant id or uuid.
>
>
> Second we will use GMF and we will use it on our developpement with
> CommonNavigator and the EMF transaction (workspace implementation). We
> will use a global TransactionalEditingDomain, that have to be the gmf
> implementation if we want to use diagram, this is a big dependency to
> have in our implementation. The problem is :
> the file format of our model is frozen (xml files validated by a
> standardized xsd), and if we look at this UUIDConstraint I can see
> that gmf core impose a big constraint that all object of a model
> instance must have a unique id (an id that never change).
>
> Actually we cannot return a UUID for all objects in a model.
>
> How can we use gmf with a model that haven't uuid?
>
> Why this uuid constraint ?
>
> what happens when getId of XMLResource return a variable id (typically
> a reference calculated with the concatenation of name of the aggregate
> tree)?
>
> Actually we prototype an editor with a global EditingDomain, this in
> facts implies that GMF editor doesn't need to load any kink of model
> resource (because resources are already loaded and a diagram can
> display information of n resources).
>
> How can I solve these problems ?
>
> cordially,
>
> laurent
|
|
|
| Re: UUIDConstraint [message #193458 is a reply to message #193365] |
Thu, 19 June 2008 08:19 |
| Eclipse User |
|
|
|
Originally posted by: laurent.legoff.geensys.com
Thank you Ed :-),
now what can I do for unchecking this UUIDConstraint from my model
validation. This rule has been configure as mandatory in the
gmf.runtime.ecore plugin.
In our Activator start method we wrote this to avoid this rule:
ConstraintRegistry.getInstance().addConstraintListener(new
IConstraintListener() {
public void constraintChanged(ConstraintChangeEvent event) {
IConstraintDescriptor icd = event.getConstraint();
if
(icd.getId().equals("org.eclipse.gmf.runtime.emf.core.UUIDConstraint ")){
//$NON-NLS-1$
if (event.getEventType() == ConstraintChangeEventType.REGISTERED ||
event.getEventType() == ConstraintChangeEventType.ENABLED) {
icd.setEnabled(false);
}
}
}
});
Do you solve this problem with you Ecore GMF editor ?
laurent
Ed Merks a écrit :
> Laurent,
>
> Domain models themselves shouldn't be required to have a unique ID. I
> know the GMF editor for Ecore works well and Ecore doesn't specify IDs...
>
>
> Laurent Le Goff wrote:
>> Hi,
>> I have problem with this mandatory constraint defined in
>> gmf.runtime.emf.core.
>>
>> First if I didn't use GMF at all but have gmf installed in my
>> workspace, the model validation return error constraint, because my
>> objects in my model doesn't have constant id or uuid.
>>
>>
>> Second we will use GMF and we will use it on our developpement with
>> CommonNavigator and the EMF transaction (workspace implementation). We
>> will use a global TransactionalEditingDomain, that have to be the gmf
>> implementation if we want to use diagram, this is a big dependency to
>> have in our implementation. The problem is :
>> the file format of our model is frozen (xml files validated by a
>> standardized xsd), and if we look at this UUIDConstraint I can see
>> that gmf core impose a big constraint that all object of a model
>> instance must have a unique id (an id that never change).
>>
>> Actually we cannot return a UUID for all objects in a model.
>>
>> How can we use gmf with a model that haven't uuid?
>>
>> Why this uuid constraint ?
>>
>> what happens when getId of XMLResource return a variable id (typically
>> a reference calculated with the concatenation of name of the aggregate
>> tree)?
>>
>> Actually we prototype an editor with a global EditingDomain, this in
>> facts implies that GMF editor doesn't need to load any kink of model
>> resource (because resources are already loaded and a diagram can
>> display information of n resources).
>>
>> How can I solve these problems ?
>>
>> cordially,
>>
>> laurent
|
|
|
| Re: UUIDConstraint [message #193672 is a reply to message #193458] |
Thu, 19 June 2008 12:33 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Laurent,
I didn't write the Ecore Tools editor; I just use it and enjoy it. So
I'm not sure what steps they took to avoid this issue. The constraint
itself is a bit odd given that it doesn't actually do what the name
implies. It only ensures that each ID within the same resource is unique.
Are you sure some plugin.xml registration or something like that is not
turning it on and you couldn't tweak it there?
Laurent Le Goff wrote:
> Thank you Ed :-),
>
> now what can I do for unchecking this UUIDConstraint from my model
> validation. This rule has been configure as mandatory in the
> gmf.runtime.ecore plugin.
> In our Activator start method we wrote this to avoid this rule:
>
>
> ConstraintRegistry.getInstance().addConstraintListener(new
> IConstraintListener() {
> public void constraintChanged(ConstraintChangeEvent event) {
> IConstraintDescriptor icd = event.getConstraint();
> if
> (icd.getId().equals("org.eclipse.gmf.runtime.emf.core.UUIDConstraint ")){
> //$NON-NLS-1$
> if (event.getEventType() ==
> ConstraintChangeEventType.REGISTERED || event.getEventType() ==
> ConstraintChangeEventType.ENABLED) {
> icd.setEnabled(false);
> }
> }
> }
> });
>
>
> Do you solve this problem with you Ecore GMF editor ?
>
> laurent
>
>
> Ed Merks a écrit :
>> Laurent,
>>
>> Domain models themselves shouldn't be required to have a unique ID.
>> I know the GMF editor for Ecore works well and Ecore doesn't specify
>> IDs...
>>
>>
>> Laurent Le Goff wrote:
>>> Hi,
>>> I have problem with this mandatory constraint defined in
>>> gmf.runtime.emf.core.
>>>
>>> First if I didn't use GMF at all but have gmf installed in my
>>> workspace, the model validation return error constraint, because my
>>> objects in my model doesn't have constant id or uuid.
>>>
>>>
>>> Second we will use GMF and we will use it on our developpement with
>>> CommonNavigator and the EMF transaction (workspace implementation).
>>> We will use a global TransactionalEditingDomain, that have to be the
>>> gmf implementation if we want to use diagram, this is a big
>>> dependency to have in our implementation. The problem is :
>>> the file format of our model is frozen (xml files validated by a
>>> standardized xsd), and if we look at this UUIDConstraint I can see
>>> that gmf core impose a big constraint that all object of a model
>>> instance must have a unique id (an id that never change).
>>>
>>> Actually we cannot return a UUID for all objects in a model.
>>>
>>> How can we use gmf with a model that haven't uuid?
>>>
>>> Why this uuid constraint ?
>>>
>>> what happens when getId of XMLResource return a variable id
>>> (typically a reference calculated with the concatenation of name of
>>> the aggregate tree)?
>>>
>>> Actually we prototype an editor with a global EditingDomain, this in
>>> facts implies that GMF editor doesn't need to load any kink of model
>>> resource (because resources are already loaded and a diagram can
>>> display information of n resources).
>>>
>>> How can I solve these problems ?
>>>
>>> cordially,
>>>
>>> laurent
|
|
|
| Re: UUIDConstraint [message #193720 is a reply to message #193672] |
Thu, 19 June 2008 14:36 |
| Eclipse User |
|
|
|
Originally posted by: laurent.legoff.geensys.com
Ed Merks a écrit :
> Laurent,
>
> I didn't write the Ecore Tools editor; I just use it and enjoy it. So
> I'm not sure what steps they took to avoid this issue. The constraint
> itself is a bit odd given that it doesn't actually do what the name
> implies. It only ensures that each ID within the same resource is unique.
> Are you sure some plugin.xml registration or something like that is not
> turning it on and you couldn't tweak it there?
Yes, it is declare in plugin.xml, but I don't think modify standard GMF
plugin is very nice. If we begin to do this we'll never declare bugs in
eclipse.org and we open a private bugzilla for gmf support ;-).
cheers
laurent
>
>
> Laurent Le Goff wrote:
>> Thank you Ed :-),
>>
>> now what can I do for unchecking this UUIDConstraint from my model
>> validation. This rule has been configure as mandatory in the
>> gmf.runtime.ecore plugin.
>> In our Activator start method we wrote this to avoid this rule:
>>
>>
>> ConstraintRegistry.getInstance().addConstraintListener(new
>> IConstraintListener() {
>> public void constraintChanged(ConstraintChangeEvent event) {
>> IConstraintDescriptor icd = event.getConstraint();
>> if
>> (icd.getId().equals("org.eclipse.gmf.runtime.emf.core.UUIDConstraint ")){
>> //$NON-NLS-1$
>> if (event.getEventType() ==
>> ConstraintChangeEventType.REGISTERED || event.getEventType() ==
>> ConstraintChangeEventType.ENABLED) {
>> icd.setEnabled(false);
>> }
>> }
>> }
>> });
>>
>>
>> Do you solve this problem with you Ecore GMF editor ?
>>
>> laurent
>>
>>
>> Ed Merks a écrit :
>>> Laurent,
>>>
>>> Domain models themselves shouldn't be required to have a unique ID.
>>> I know the GMF editor for Ecore works well and Ecore doesn't specify
>>> IDs...
>>>
>>>
>>> Laurent Le Goff wrote:
>>>> Hi,
>>>> I have problem with this mandatory constraint defined in
>>>> gmf.runtime.emf.core.
>>>>
>>>> First if I didn't use GMF at all but have gmf installed in my
>>>> workspace, the model validation return error constraint, because my
>>>> objects in my model doesn't have constant id or uuid.
>>>>
>>>>
>>>> Second we will use GMF and we will use it on our developpement with
>>>> CommonNavigator and the EMF transaction (workspace implementation).
>>>> We will use a global TransactionalEditingDomain, that have to be the
>>>> gmf implementation if we want to use diagram, this is a big
>>>> dependency to have in our implementation. The problem is :
>>>> the file format of our model is frozen (xml files validated by a
>>>> standardized xsd), and if we look at this UUIDConstraint I can see
>>>> that gmf core impose a big constraint that all object of a model
>>>> instance must have a unique id (an id that never change).
>>>>
>>>> Actually we cannot return a UUID for all objects in a model.
>>>>
>>>> How can we use gmf with a model that haven't uuid?
>>>>
>>>> Why this uuid constraint ?
>>>>
>>>> what happens when getId of XMLResource return a variable id
>>>> (typically a reference calculated with the concatenation of name of
>>>> the aggregate tree)?
>>>>
>>>> Actually we prototype an editor with a global EditingDomain, this in
>>>> facts implies that GMF editor doesn't need to load any kink of model
>>>> resource (because resources are already loaded and a diagram can
>>>> display information of n resources).
>>>>
>>>> How can I solve these problems ?
>>>>
>>>> cordially,
>>>>
>>>> laurent
|
|
| |
| Re: UUIDConstraint [message #193792 is a reply to message #193720] |
Thu, 19 June 2008 16:10 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Laurent,
Yes, that would be bad to change. I thought maybe it would be in the
generated plugins. Someone knowledgeable needs to comment on this...
Or you need to have a close look at the Ecore Tools editor or the sample
Ecore graphical editor in GMF...
Laurent Le Goff wrote:
> Ed Merks a écrit :
>> Laurent,
>>
>> I didn't write the Ecore Tools editor; I just use it and enjoy it.
>> So I'm not sure what steps they took to avoid this issue. The
>> constraint itself is a bit odd given that it doesn't actually do what
>> the name implies. It only ensures that each ID within the same
>> resource is unique.
>> Are you sure some plugin.xml registration or something like that is
>> not turning it on and you couldn't tweak it there?
> Yes, it is declare in plugin.xml, but I don't think modify standard
> GMF plugin is very nice. If we begin to do this we'll never declare
> bugs in eclipse.org and we open a private bugzilla for gmf support ;-).
>
> cheers
> laurent
>
>>
>>
>> Laurent Le Goff wrote:
>>> Thank you Ed :-),
>>>
>>> now what can I do for unchecking this UUIDConstraint from my model
>>> validation. This rule has been configure as mandatory in the
>>> gmf.runtime.ecore plugin.
>>> In our Activator start method we wrote this to avoid this rule:
>>>
>>>
>>> ConstraintRegistry.getInstance().addConstraintListener(new
>>> IConstraintListener() {
>>> public void constraintChanged(ConstraintChangeEvent event) {
>>> IConstraintDescriptor icd = event.getConstraint();
>>> if
>>> (icd.getId().equals("org.eclipse.gmf.runtime.emf.core.UUIDConstraint ")){
>>> //$NON-NLS-1$
>>> if (event.getEventType() ==
>>> ConstraintChangeEventType.REGISTERED || event.getEventType() ==
>>> ConstraintChangeEventType.ENABLED) {
>>> icd.setEnabled(false);
>>> }
>>> }
>>> }
>>> });
>>>
>>>
>>> Do you solve this problem with you Ecore GMF editor ?
>>>
>>> laurent
>>>
>>>
>>> Ed Merks a écrit :
>>>> Laurent,
>>>>
>>>> Domain models themselves shouldn't be required to have a unique
>>>> ID. I know the GMF editor for Ecore works well and Ecore doesn't
>>>> specify IDs...
>>>>
>>>>
>>>> Laurent Le Goff wrote:
>>>>> Hi,
>>>>> I have problem with this mandatory constraint defined in
>>>>> gmf.runtime.emf.core.
>>>>>
>>>>> First if I didn't use GMF at all but have gmf installed in my
>>>>> workspace, the model validation return error constraint, because
>>>>> my objects in my model doesn't have constant id or uuid.
>>>>>
>>>>>
>>>>> Second we will use GMF and we will use it on our developpement
>>>>> with CommonNavigator and the EMF transaction (workspace
>>>>> implementation). We will use a global TransactionalEditingDomain,
>>>>> that have to be the gmf implementation if we want to use diagram,
>>>>> this is a big dependency to have in our implementation. The
>>>>> problem is :
>>>>> the file format of our model is frozen (xml files validated by a
>>>>> standardized xsd), and if we look at this UUIDConstraint I can see
>>>>> that gmf core impose a big constraint that all object of a model
>>>>> instance must have a unique id (an id that never change).
>>>>>
>>>>> Actually we cannot return a UUID for all objects in a model.
>>>>>
>>>>> How can we use gmf with a model that haven't uuid?
>>>>>
>>>>> Why this uuid constraint ?
>>>>>
>>>>> what happens when getId of XMLResource return a variable id
>>>>> (typically a reference calculated with the concatenation of name
>>>>> of the aggregate tree)?
>>>>>
>>>>> Actually we prototype an editor with a global EditingDomain, this
>>>>> in facts implies that GMF editor doesn't need to load any kink of
>>>>> model resource (because resources are already loaded and a diagram
>>>>> can display information of n resources).
>>>>>
>>>>> How can I solve these problems ?
>>>>>
>>>>> cordially,
>>>>>
>>>>> laurent
|
|
|
| Re: UUIDConstraint [message #193799 is a reply to message #193745] |
Thu, 19 June 2008 16:15 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Alex,
Sorry, I need to refresh before I post replies.
Alex Shatalin wrote:
> Hello Laurent,
>
>
>> Yes, it is declare in plugin.xml, but I don't think modify standard
>> GMF plugin is very nice. If we begin to do this we'll never declare
>> bugs in eclipse.org and we open a private bugzilla for gmf support
>> ;-).
> AFAIU, the problem is in your model
What do you think the problem is?
> constraitn itself looks reasonable for me (Ed, please correct me if
> I'm wrong). See part of the UUIDConstraint class:
>
> EObject target = ctx.getTarget();
> Resource resource = target.eResource();
>
> if (!(resource instanceof XMLResource))
> return ctx.createSuccessStatus();
>
> // Fail constraint if target is the key of an eObject to ID map entry,
> // but not the value of an ID to eObject map entry.
> XMLResource xmlResource = (XMLResource) resource;
> String id = xmlResource.getID(target);
This might return null. It's not calling getFragment which would always
return a result and returns the ID if there is an ID.
>
> EObject eObject = xmlResource.getEObject(id);
It's only checking the ID is unique within the resource but the comment
says and the name implies that it checks that the ID is universally unique.
If ID is null this will return null and then I think this will complain
because target != null. So effectively this constraint is forcing each
object to have an ID. If this is always applied to the domain model,
that seems wrong to me. Not all domains should be forced to define an ID.
> if (eObject != target) {
> return ctx.createFailureStatus(new Object[]
> {getEObjectLabel(target)});
> }
>
> -----------------
> Alex Shatalin
>
>
|
|
| |
| Re: UUIDConstraint [message #193822 is a reply to message #193799] |
Thu, 19 June 2008 18:10 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-vmtskdEzLPO2kAQWVxxB
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Ed, Alex, Laurent,
I know something of the history of this constraint.
The purpose of this constraint (despite its name) is to ensure that no
object in an ID-based XMLResource is "shadowed" or "unreferenceable"
because of multiple objects having the same "x[sm]i:id" attribute value
in the same resource. It isn't concerned with more general URI
fragments.
When multiple objects have the same ID, then the ID occurs multiple
times as a value in the EObject-to-ID map. However, looking objects up
by ID can only find one of these objects because the ID-to-EObject map
necessarily only contains the ID once. So, this constraint points the
user to those elements that are "shadowed."
In the case that a resource does not use IDs or has some subset of
objects that don't have IDs, then looking up such an object in the
EObject-to-ID map should return null. Looking up null in the
ID-to-EObject map would be expected to return null, also. So, then,
clearly eObject != null causes a failure.
To fix this problem, I think it is only necessary that if looking up the
ID returns null, then nothing further should be done because when there
is no ID there cannot be any shadowing.
Cheers,
Christian
On Thu, 2008-06-19 at 12:15 -0400, Ed Merks wrote:
> Alex,
>
> Sorry, I need to refresh before I post replies.
>
>
> Alex Shatalin wrote:
> > Hello Laurent,
> >
> >
> >> Yes, it is declare in plugin.xml, but I don't think modify standard
> >> GMF plugin is very nice. If we begin to do this we'll never declare
> >> bugs in eclipse.org and we open a private bugzilla for gmf support
> >> ;-).
> > AFAIU, the problem is in your model
> What do you think the problem is?
> > constraitn itself looks reasonable for me (Ed, please correct me if
> > I'm wrong). See part of the UUIDConstraint class:
> >
> > EObject target = ctx.getTarget();
> > Resource resource = target.eResource();
> >
> > if (!(resource instanceof XMLResource))
> > return ctx.createSuccessStatus();
> >
> > // Fail constraint if target is the key of an eObject to ID map entry,
> > // but not the value of an ID to eObject map entry.
> > XMLResource xmlResource = (XMLResource) resource;
> > String id = xmlResource.getID(target);
> This might return null. It's not calling getFragment which would always
> return a result and returns the ID if there is an ID.
> >
> > EObject eObject = xmlResource.getEObject(id);
> It's only checking the ID is unique within the resource but the comment
> says and the name implies that it checks that the ID is universally unique.
>
> If ID is null this will return null and then I think this will complain
> because target != null. So effectively this constraint is forcing each
> object to have an ID. If this is always applied to the domain model,
> that seems wrong to me. Not all domains should be forced to define an ID.
> > if (eObject != target) {
> > return ctx.createFailureStatus(new Object[]
> > {getEObjectLabel(target)});
> > }
> >
> > -----------------
> > Alex Shatalin
> >
> >
--=-vmtskdEzLPO2kAQWVxxB
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Ed, Alex, Laurent,<BR>
<BR>
I know something of the history of this constraint.<BR>
<BR>
The purpose of this constraint (despite its name) is to ensure that no object in an ID-based XMLResource is "shadowed" or "unreferenceable" because of multiple objects having the same "x[sm]i:id" attribute value in the same resource. It isn't concerned with more general URI fragments.<BR>
<BR>
When multiple objects have the same ID, then the ID occurs multiple times as a value in the EObject-to-ID map. However, looking objects up by ID can only find one of these objects because the ID-to-EObject map necessarily only contains the ID once. So, this constraint points the user to those elements that are "shadowed."<BR>
<BR>
In the case that a resource does not use IDs or has some subset of objects that don't have IDs, then looking up such an object in the EObject-to-ID map should return null. Looking up null in the ID-to-EObject map would be expected to return null, also. So, then, clearly eObject != null causes a failure.<BR>
<BR>
To fix this problem, I think it is only necessary that if looking up the ID returns null, then nothing further should be done because when there is no ID there cannot be any shadowing.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Thu, 2008-06-19 at 12:15 -0400, Ed Merks wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Alex,</FONT>
<FONT COLOR="#000000">Sorry, I need to refresh before I post replies.</FONT>
<FONT COLOR="#000000">Alex Shatalin wrote:</FONT>
<FONT COLOR="#000000">> Hello Laurent,</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">>> Yes, it is declare in plugin.xml, but I don't think modify standard</FONT>
<FONT COLOR="#000000">>> GMF plugin is very nice. If we begin to do this we'll never declare</FONT>
<FONT COLOR="#000000">>> bugs in eclipse.org and we open a private bugzilla for gmf support</FONT>
<FONT COLOR="#000000">>> ;-).</FONT>
<FONT COLOR="#000000">> AFAIU, the problem is in your model</FONT>
<FONT COLOR="#000000">What do you think the problem is?</FONT>
<FONT COLOR="#000000">> constraitn itself looks reasonable for me (Ed, please correct me if </FONT>
<FONT COLOR="#000000">> I'm wrong). See part of the UUIDConstraint class:</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> EObject target = ctx.getTarget();</FONT>
<FONT COLOR="#000000">> Resource resource = target.eResource();</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> if (!(resource instanceof XMLResource))</FONT>
<FONT COLOR="#000000">> return ctx.createSuccessStatus();</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> // Fail constraint if target is the key of an eObject to ID map entry,</FONT>
<FONT COLOR="#000000">> // but not the value of an ID to eObject map entry.</FONT>
<FONT COLOR="#000000">> XMLResource xmlResource = (XMLResource) resource;</FONT>
<FONT COLOR="#000000">> String id = xmlResource.getID(target);</FONT>
<FONT COLOR="#000000">This might return null. It's not calling getFragment which would always </FONT>
<FONT COLOR="#000000">return a result and returns the ID if there is an ID.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> EObject eObject = xmlResource.getEObject(id);</FONT>
<FONT COLOR="#000000">It's only checking the ID is unique within the resource but the comment </FONT>
<FONT COLOR="#000000">says and the name implies that it checks that the ID is universally unique.</FONT>
<FONT COLOR="#000000">If ID is null this will return null and then I think this will complain </FONT>
<FONT COLOR="#000000">because target != null. So effectively this constraint is forcing each </FONT>
<FONT COLOR="#000000">object to have an ID. If this is always applied to the domain model, </FONT>
<FONT COLOR="#000000">that seems wrong to me. Not all domains should be forced to define an ID.</FONT>
<FONT COLOR="#000000">> if (eObject != target) {</FONT>
<FONT COLOR="#000000">> return ctx.createFailureStatus(new Object[] </FONT>
<FONT COLOR="#000000">> {getEObjectLabel(target)});</FONT>
<FONT COLOR="#000000">> }</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> -----------------</FONT>
<FONT COLOR="#000000">> Alex Shatalin</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">></FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-vmtskdEzLPO2kAQWVxxB--
|
|
| |
| Re: UUIDConstraint [message #193955 is a reply to message #193903] |
Fri, 20 June 2008 13:08 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-6eY7BbxtEjrerA0hcOlR
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Alex,
I suspect that GMF defines this constraint for itself because of the
run-time's ingrained assumption that the semantic model uses IDs. I
know, for example, that the copy/paste stuff requires this. I think
there is movement away from this assumption, though, generally ...
right?
I wouldn't really want to provide this constraint in the EMF Validation
Framework component, if that's what you had in mind. I don't want to
get into the business of providing stock constraints. Perhaps it would
be more appropriate for the GMF tooling to generate this constraint
(optionally) for GMF editors that use IDs?
cW
On Fri, 2008-06-20 at 10:54 +0000, Alex Shatalin wrote:
> Hello Christian,
>
> BTW, what do you think about moving this constraint to any other plugin (making
> it not a part of GMF, but better a part of EMFT)? For me it looks like generic
> EMF-oriented constraint..
>
> -----------------
> Alex Shatalin
>
>
--=-6eY7BbxtEjrerA0hcOlR
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Alex,<BR>
<BR>
I suspect that GMF defines this constraint for itself because of the run-time's ingrained assumption that the semantic model uses IDs. I know, for example, that the copy/paste stuff requires this. I think there is movement away from this assumption, though, generally ... right?<BR>
<BR>
I wouldn't really want to provide this constraint in the EMF Validation Framework component, if that's what you had in mind. I don't want to get into the business of providing stock constraints. Perhaps it would be more appropriate for the GMF tooling to generate this constraint (optionally) for GMF editors that use IDs?<BR>
<BR>
cW<BR>
<BR>
<BR>
On Fri, 2008-06-20 at 10:54 +0000, Alex Shatalin wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hello Christian,</FONT>
<FONT COLOR="#000000">BTW, what do you think about moving this constraint to any other plugin (making </FONT>
<FONT COLOR="#000000">it not a part of GMF, but better a part of EMFT)? For me it looks like generic </FONT>
<FONT COLOR="#000000">EMF-oriented constraint..</FONT>
<FONT COLOR="#000000">-----------------</FONT>
<FONT COLOR="#000000">Alex Shatalin</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-6eY7BbxtEjrerA0hcOlR--
|
|
|
| Re: UUIDConstraint [message #194062 is a reply to message #193955] |
Mon, 23 June 2008 09:40 |
| Eclipse User |
|
|
|
Originally posted by: laurent.legoff.geensys.com
Should I open a bug or not ? if yes, where in gmf, in emft bugzilla?
did you make some changes somewhere?
thanks for support.
Laurent.
Christian W. Damus a écrit :
> Hi, Alex,
>
> I suspect that GMF defines this constraint for itself because of the
> run-time's ingrained assumption that the semantic model uses IDs. I
> know, for example, that the copy/paste stuff requires this. I think
> there is movement away from this assumption, though, generally ... right?
>
> I wouldn't really want to provide this constraint in the EMF Validation
> Framework component, if that's what you had in mind. I don't want to
> get into the business of providing stock constraints. Perhaps it would
> be more appropriate for the GMF tooling to generate this constraint
> (optionally) for GMF editors that use IDs?
>
> cW
>
>
> On Fri, 2008-06-20 at 10:54 +0000, Alex Shatalin wrote:
>> Hello Christian,
>>
>> BTW, what do you think about moving this constraint to any other plugin (making
>> it not a part of GMF, but better a part of EMFT)? For me it looks like generic
>> EMF-oriented constraint..
>>
>> -----------------
>> Alex Shatalin
>>
>>
|
|
|
| Re: UUIDConstraint [message #194119 is a reply to message #194062] |
Mon, 23 June 2008 12:45 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Laurent,
I'd suggest opening a GMF bugzilla since the constraint as it is written
needs to be fixed. If folks want to move the constraint elsewhere,
that's a separate discussion.
I'm personally not happy with an over reliance on UUIDs. Certainly
UUIDs have some very nice properties that make them attractive, but
their serialization is like an eye chart and a UUID has an overhead of
approximately 170 bytes per object which for many models make them the
dominant footprint cost. So the nice characteristics they support are
offset by some not so nice ones..
Laurent Le Goff wrote:
> Should I open a bug or not ? if yes, where in gmf, in emft bugzilla?
> did you make some changes somewhere?
>
> thanks for support.
>
> Laurent.
>
>
> Christian W. Damus a écrit :
>> Hi, Alex,
>>
>> I suspect that GMF defines this constraint for itself because of the
>> run-time's ingrained assumption that the semantic model uses IDs. I
>> know, for example, that the copy/paste stuff requires this. I think
>> there is movement away from this assumption, though, generally ...
>> right?
>>
>> I wouldn't really want to provide this constraint in the EMF
>> Validation Framework component, if that's what you had in mind. I
>> don't want to get into the business of providing stock constraints.
>> Perhaps it would be more appropriate for the GMF tooling to generate
>> this constraint (optionally) for GMF editors that use IDs?
>>
>> cW
>>
>>
>> On Fri, 2008-06-20 at 10:54 +0000, Alex Shatalin wrote:
>>> Hello Christian,
>>>
>>> BTW, what do you think about moving this constraint to any other
>>> plugin (making it not a part of GMF, but better a part of EMFT)? For
>>> me it looks like generic EMF-oriented constraint..
>>>
>>> -----------------
>>> Alex Shatalin
>>>
>>>
|
|
|
| Re: UUIDConstraint [message #194141 is a reply to message #194119] |
Mon, 23 June 2008 14:34 |
| Eclipse User |
|
|
|
Originally posted by: laurent.legoff.geensys.com
thanks,
here it is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=238118
Ed Merks a écrit :
> Laurent,
>
> I'd suggest opening a GMF bugzilla since the constraint as it is written
> needs to be fixed. If folks want to move the constraint elsewhere,
> that's a separate discussion.
> I'm personally not happy with an over reliance on UUIDs. Certainly
> UUIDs have some very nice properties that make them attractive, but
> their serialization is like an eye chart and a UUID has an overhead of
> approximately 170 bytes per object which for many models make them the
> dominant footprint cost. So the nice characteristics they support are
> offset by some not so nice ones..
>
>
> Laurent Le Goff wrote:
>> Should I open a bug or not ? if yes, where in gmf, in emft bugzilla?
>> did you make some changes somewhere?
>>
>> thanks for support.
>>
>> Laurent.
>>
>>
>> Christian W. Damus a écrit :
>>> Hi, Alex,
>>>
>>> I suspect that GMF defines this constraint for itself because of the
>>> run-time's ingrained assumption that the semantic model uses IDs. I
>>> know, for example, that the copy/paste stuff requires this. I think
>>> there is movement away from this assumption, though, generally ...
>>> right?
>>>
>>> I wouldn't really want to provide this constraint in the EMF
>>> Validation Framework component, if that's what you had in mind. I
>>> don't want to get into the business of providing stock constraints.
>>> Perhaps it would be more appropriate for the GMF tooling to generate
>>> this constraint (optionally) for GMF editors that use IDs?
>>>
>>> cW
>>>
>>>
>>> On Fri, 2008-06-20 at 10:54 +0000, Alex Shatalin wrote:
>>>> Hello Christian,
>>>>
>>>> BTW, what do you think about moving this constraint to any other
>>>> plugin (making it not a part of GMF, but better a part of EMFT)? For
>>>> me it looks like generic EMF-oriented constraint..
>>>>
>>>> -----------------
>>>> Alex Shatalin
>>>>
>>>>
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 02:56:44 GMT 2024
Powered by FUDForum. Page generated in 0.04409 seconds |
] 
Search
Help
Register
Login
Home
