| forcing emf to save object ref as @ [message #255715] |
Wed, 07 May 2008 21:38  |
Eclipse User |
|
|
|
Originally posted by: devquestions.gmail.com
Hello Frens,
while analyzing the xmi objects saved using XMIResourceImpl , i see that ,
the local object references are referred using the class type and their
relative order in the xml.
Example
sqlobjects="//@MyClassType1.0/@SQLObjects.15" etc
However, the objects below SQLObjects are referred using names
Eg:
level="//@Inputlayers.0/@SQLObjects.15/Month Level".
Is there a way to force XMIResourceImpl to always save using class type
and relative order in the xml document ?
|
|
|
| Re: forcing emf to save object ref as @ [message #255727 is a reply to message #255715] |
Wed, 07 May 2008 21:44  |
| Eclipse User |
|
|
|
Originally posted by: codeslave.ca.ibm.com
Sounds like a great question for the EMF newsgroup. Copying it there.
dev wrote:
> Hello Frens,
>
> while analyzing the xmi objects saved using XMIResourceImpl , i see that
> , the local object references are referred using the class type and
> their relative order in the xml.
> Example
>
> sqlobjects="//@MyClassType1.0/@SQLObjects.15" etc
>
> However, the objects below SQLObjects are referred using names
>
> Eg:
> level="//@Inputlayers.0/@SQLObjects.15/Month Level".
> Is there a way to force XMIResourceImpl to always save using class type
> and relative order in the xml document ?
>
>
|
|
|
| Re: forcing emf to save object ref as @ [message #255739 is a reply to message #255727] |
Wed, 07 May 2008 22:13 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
EModelElementImpl.eURIFragmentSegment/eObjectForURIFragmentS egment has
a good example of how to specialize a fragment segment's syntax. It's
important to ensure that things like "/", "@", ":", "#" and " " don't
appear in the segment. It's also possible to use EReference.eKeys to
pick attributes in the referenced EClass that uniquely identify the
value. You'd get syntax like @feature[key='value'] for such segments;
the value will be encoded to avoid bad characters...
Nick Boldt wrote:
> Sounds like a great question for the EMF newsgroup. Copying it there.
>
> dev wrote:
>> Hello Frens,
>>
>> while analyzing the xmi objects saved using XMIResourceImpl , i see
>> that , the local object references are referred using the class type
>> and their relative order in the xml.
>> Example
>>
>> sqlobjects="//@MyClassType1.0/@SQLObjects.15" etc
>>
>> However, the objects below SQLObjects are referred using names
>>
>> Eg:
>> level="//@Inputlayers.0/@SQLObjects.15/Month Level".
>> Is there a way to force XMIResourceImpl to always save using class
>> type and relative order in the xml document ?
>>
>>
|
|
|
| Re: forcing emf to save object ref as @ [message #255742 is a reply to message #255739] |
Thu, 08 May 2008 00:29 |
| Eclipse User |
|
|
|
Originally posted by: devquestions.gmail.com
Hi Nick,
Thanks for the note. But I am sorry I do not understand what you are
saying.
the fragment segment ("//@SQLObjects.15/Month Level") was generated from
XMLResourceImpl. I did not make any changes to it, so I expect that
XMLResourceImpl should load the objects it saved, however the xml objects
do not get loaded , on load I get
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
reference '//@SQLObjects.15/Month'. exception.
I do not see this error when i name object Month_Level instead of "Month
Level"
Notice that in the exception the uri fragment is truncated after space. On
tracing the code I found out that the method setValueFromId(EObject
object, EReference eReference, String ids) in the class
org.eclipse.emf.ecore.xmi.impl.XMLHandler
does this truncation.
In this scenario I am not sure what I am doing wrong. "Month Level" is
just an emf object attribute name, it is not even a class name. Are you
saying that emf object attributes cannot use space in them ?
Thanks !
|
|
|
| Re: forcing emf to save object ref as @ [message #255745 is a reply to message #255742] |
Thu, 08 May 2008 01:23 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Comments below.
dev wrote:
>
> Hi Nick,
>
> Thanks for the note. But I am sorry I do not understand what you are
> saying.
> the fragment segment ("//@SQLObjects.15/Month Level") was generated
> from XMLResourceImpl.
That's not the form it would generate by default. Each segment would be
of the form @<featureName>[.<index>].
> I did not make any changes to it, so I expect that XMLResourceImpl
> should load the objects it saved, however the xml objects do not get
> loaded , on load I get
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
> reference '//@SQLObjects.15/Month'. exception.
It certainly looks as if someone made changes to id
> I do not see this error when i name object Month_Level instead of
> "Month Level"
Which model is this? If this is a model someone else implemented,
they'll need to fix how they specialized the code to produce this form.
>
> Notice that in the exception the uri fragment is truncated after space.
Yes, I see that.
> On tracing the code I found out that the method
> setValueFromId(EObject object, EReference eReference, String ids) in
> the class org.eclipse.emf.ecore.xmi.impl.XMLHandler
> does this truncation.
It does indeed, as it will always do when it sees a space.
>
> In this scenario I am not sure what I am doing wrong.
The code that produces a fragment based on some value of the model that
allows spaces is not doing such a good job.
> "Month Level" is just an emf object attribute name, it is not even a
> class name.
EMF includes the @ character in front of all the feature names, and
feature names aren't allowed to have spaces, so I'm a little confused.
> Are you saying that emf object attributes cannot use space in them ?
Definitely the name of an EAttribute may not contain a space. Ecore
model instances are validated and report that as an error. Somehow I
get the impression this is the value of data in your instance and that
you're using a model that's specialized the code inappropriately. Which
model is involved?
>
> Thanks !
>
|
|
|
Powered by
FUDForum. Page generated in 0.26884 seconds
] 
Search
Help
Register
Login
Home
