Home » Modeling » EMF » uri fragments vs. ID's in serialized Non-Containment references
|
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #392656 is a reply to message #392648] |
Wed, 04 May 2005 10:47   |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040408070904010000050902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mark,
All I can really suggest it to debug the behavior of this method in
ResourceImpl as it interprets the fragment path:
protected EObject getEObject(List uriFragmentPath)
The steps in the path are of the form
<feature-name>[.<index-in-many-valued-feature>], so they shouldn't be
qualified with prefixes.
In the latest code, the fragment is computed by XMLHelperImpl like this:
protected String getURIFragment(Resource containingResource,
EObject object)
{
String result = containingResource.getURIFragment(object);
if (result.charAt(0) != '/')
{
String query = getURIFragmentQuery(containingResource, object);
if (query != null)
{
result += "?" + query + "?";
}
}
return result;
}
So the resource containing the referenced object determines the fragment
via its implementation of getURIFragment, which returns an ID if there
is one:
public String getURIFragment(EObject eObject)
{
String id = EcoreUtil.getID(eObject);
if (id != null)
{
return id;
}
...
(This ResourceImpl method is overridden in XMLResourceImpl to also
consider extrinsic IDs, i.e., IDs not modeled as attributes on the
instances.)
Mark Diggory wrote:
> I'm having some problems getting my model to resolve non-containment
> references that are uri fragments, ID's work great, but fragments
> fail. For example I have the following 2 references, the first works
> correctly, the second doesn't.
>
> <outline:reference>file:/C:/workspace/Test%20Project/test.xml#V13 </outline:reference>
>
>
> <outline:reference> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </outline:reference>
>
>
> I know that the path exists in my model and serialized xml. The only
> thing I havn't tried is attempting some sort of namespacing/prefixing
> on the elements. IE.
>
> #/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
>
> Is there something obvious I'm missing? I know the resource is already
> loaded for the first reference.
>
> Also, Is there any way I can force the containment references to use
> fragments instead of ID's?
>
> thanks,
> Mark Diggory
--------------040408070904010000050902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark,<br>
<br>
All I can really suggest it to debug the behavior of this method in
ResourceImpl as it interprets the fragment path:<br>
<blockquote>protected EObject getEObject(List uriFragmentPath)<br>
</blockquote>
The steps in the path are of the form
<feature-name>[.<index-in-many-valued-f eature>], so they
shouldn't be qualified with prefixes. <br>
<br>
In the latest code, the fragment is computed by XMLHelperImpl like this:<br>
<blockquote><small> protected String getURIFragment(Resource
containingResource, EObject object)</small><br>
<small> {</small><br>
<small> String result = containingResource.getURIFragment(object);</small><br>
<small> if (result.charAt(0) != '/')</small><br>
<small> {</small><br>
<small> String query = getURIFragmentQuery(containingResource,
object);</small><br>
<small> if (query != null)</small><br>
<small> {</small><br>
<small> result += "?" + query + "?";</small><br>
<small> }</small><br>
<small> }</small><br>
<small> return result;</small><br>
<small> }</small><br>
</blockquote>
So the resource containing the referenced object determines the
fragment via its implementation of getURIFragment, which returns an ID
if there is one:<br>
<blockquote><small> public String getURIFragment(EObject eObject)<br>
{<br>
String id = EcoreUtil.getID(eObject);<br>
if (id != null)<br>
{<br>
return id;<br>
}<br>
...</small><br>
</blockquote>
(This ResourceImpl method is overridden in XMLResourceImpl to also
consider extrinsic IDs, i.e., IDs not modeled as attributes on the
instances.)<br>
<br>
<br>
Mark Diggory wrote:
<blockquote cite="midd59h30$tbu$1@news.eclipse.org" type="cite">I'm
having some problems getting my model to resolve non-containment
references that are uri fragments, ID's work great, but fragments fail.
For example I have the following 2 references, the first works
correctly, the second doesn't.
<br>
<br>
<outline:reference><a class="moz-txt-link-freetext" href="file:/C:/workspace/Test%20Project/test.xml#V13">file:/C:/workspace/Test%20Project/test.xml#V13 </a></outline:reference>
<br>
<br>
<outline:reference><a class="moz-txt-link-freetext" href=" file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 "> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </a></outline:reference>
<br>
<br>
I know that the path exists in my model and serialized xml. The only
thing I havn't tried is attempting some sort of namespacing/prefixing
on the elements. IE.
<br>
<br>
#/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
<br>
<br>
Is there something obvious I'm missing? I know the resource is already
loaded for the first reference.
<br>
<br>
Also, Is there any way I can force the containment references to use
fragments instead of ID's?
<br>
<br>
thanks,
<br>
Mark Diggory
<br>
</blockquote>
<br>
</body>
</html>
--------------040408070904010000050902--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #392659 is a reply to message #392656] |
Wed, 04 May 2005 14:30 |
Mark Diggory
Messages: 202
Registered: July 2009 |
Senior Member |
|
|
Ed, I'm not really doing anything weird here. I simply have the below
references in my resource, the implementations of my resource are what
is generated by EMF codegen.
It seems find the DocumentRoot of the resource in getEObject(List
uriFragmentPath), but throws an exception when navigating into the
fragment further.
the fragment path looks like:
[, @codeBook.0, @stdyDscr.0, @citation.0, @titlStmt.0, @titl.0]
After stepping through the code, it appears that I get a runtime
exception here for the CodeBookImpl object in the ResourceSet:
> public static EObject resolve(EObject proxy, ResourceSet resourceSet)
> {
> URI proxyURI = ((InternalEObject)proxy).eProxyURI();
> if (proxyURI != null)
> {
> try
> {
> EObject resolvedObject = null;
>
> if (resourceSet != null)
> {
> resolvedObject = resourceSet.getEObject(proxyURI, true);
> }
> else
> {
> EPackage ePackage = EPackage.Registry.INSTANCE.getEPackage(proxyURI.trimFragment ().toString());
> if (ePackage != null)
> {
> Resource resource = ePackage.eResource();
> if (resource != null)
> {
> resolvedObject = resource.getEObject(proxyURI.fragment().toString());
> }
> }
> }
>
> if (resolvedObject != null && resolvedObject != proxy)
> {
> return resolve(resolvedObject, resourceSet);
> }
> }
> catch (RuntimeException exception)
> {
> // Failure to resolve is ignored.
> }
> }
> return proxy;
> }
Note, both resources are loaded using the EditingDomain provided by the
Editor.
-Mark
Ed Merks wrote:
> Mark,
>
> All I can really suggest it to debug the behavior of this method in
> ResourceImpl as it interprets the fragment path:
>
> protected EObject getEObject(List uriFragmentPath)
>
> The steps in the path are of the form
> <feature-name>[.<index-in-many-valued-feature>], so they shouldn't be
> qualified with prefixes.
>
> In the latest code, the fragment is computed by XMLHelperImpl like this:
>
> protected String getURIFragment(Resource containingResource,
> EObject object)
> {
> String result = containingResource.getURIFragment(object);
> if (result.charAt(0) != '/')
> {
> String query = getURIFragmentQuery(containingResource, object);
> if (query != null)
> {
> result += "?" + query + "?";
> }
> }
> return result;
> }
>
> So the resource containing the referenced object determines the fragment
> via its implementation of getURIFragment, which returns an ID if there
> is one:
>
> public String getURIFragment(EObject eObject)
> {
> String id = EcoreUtil.getID(eObject);
> if (id != null)
> {
> return id;
> }
> ...
>
> (This ResourceImpl method is overridden in XMLResourceImpl to also
> consider extrinsic IDs, i.e., IDs not modeled as attributes on the
> instances.)
>
>
> Mark Diggory wrote:
>
>> I'm having some problems getting my model to resolve non-containment
>> references that are uri fragments, ID's work great, but fragments
>> fail. For example I have the following 2 references, the first works
>> correctly, the second doesn't.
>>
>> <outline:reference>file:/C:/workspace/Test%20Project/test.xml#V13 </outline:reference>
>>
>>
>> <outline:reference> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </outline:reference>
>>
>>
>> I know that the path exists in my model and serialized xml. The only
>> thing I havn't tried is attempting some sort of namespacing/prefixing
>> on the elements. IE.
>>
>> #/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
>>
>> Is there something obvious I'm missing? I know the resource is already
>> loaded for the first reference.
>>
>> Also, Is there any way I can force the containment references to use
>> fragments instead of ID's?
>>
>> thanks,
>> Mark Diggory
>
>
|
|
|
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #392660 is a reply to message #392659] |
Wed, 04 May 2005 14:43 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030401080302000803000407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mark,
I can debug a test case if I have it, or I can indicate where you need
to look to debug it yourself, which I tried to do. But showing me code
that I wrote myself won't help at all. ;-) Showing a stack trace likely
would...
Given that you've told me there is a document root, I'm suspicious that
@codeBook.0 shouldn't be just @codeBook without the .0. If there is an
..<index>, the result of eGetting the feature will be cast to a list, and
the document root can only have one child element, so this sounds wrong:
public EObject eObjectForURIFragmentSegment(String uriFragmentSegment)
{
* int dotIndex = uriFragmentSegment.indexOf(".");
if (dotIndex == -1)*
{
String name = uriFragmentSegment.substring(1);
EStructuralFeature eStructuralFeature =
eClass().getEStructuralFeature(name);
if (eStructuralFeature == null)
{
throw new IllegalArgumentException("The feature '" + name +
"' is not a valid feature");
}
return (EObject)eGet(eStructuralFeature, false);
}
else
{
String name = uriFragmentSegment.substring(1, dotIndex);
EStructuralFeature eStructuralFeature =
eClass().getEStructuralFeature(name);
if (eStructuralFeature == null)
{
throw new IllegalArgumentException("The feature '" + name +
"' is not a valid feature");
}
* EList eList = (EList)eGet(eStructuralFeature, false);*
Mark Diggory wrote:
> Ed, I'm not really doing anything weird here. I simply have the below
> references in my resource, the implementations of my resource are what
> is generated by EMF codegen.
>
> It seems find the DocumentRoot of the resource in getEObject(List
> uriFragmentPath), but throws an exception when navigating into the
> fragment further.
>
> the fragment path looks like:
>
> [, @codeBook.0, @stdyDscr.0, @citation.0, @titlStmt.0, @titl.0]
> After stepping through the code, it appears that I get a runtime
> exception here for the CodeBookImpl object in the ResourceSet:
>
>> public static EObject resolve(EObject proxy, ResourceSet resourceSet)
>> {
>> URI proxyURI = ((InternalEObject)proxy).eProxyURI();
>> if (proxyURI != null)
>> {
>> try
>> {
>> EObject resolvedObject = null;
>>
>> if (resourceSet != null)
>> {
>> resolvedObject = resourceSet.getEObject(proxyURI, true);
>> }
>> else
>> {
>> EPackage ePackage =
>> EPackage.Registry.INSTANCE.getEPackage(proxyURI.trimFragment ().toString());
>>
>> if (ePackage != null)
>> {
>> Resource resource = ePackage.eResource();
>> if (resource != null)
>> {
>> resolvedObject =
>> resource.getEObject(proxyURI.fragment().toString());
>> }
>> }
>> }
>>
>> if (resolvedObject != null && resolvedObject != proxy)
>> {
>> return resolve(resolvedObject, resourceSet);
>> }
>> }
>> catch (RuntimeException exception)
>> {
>> // Failure to resolve is ignored.
>> }
>> }
>> return proxy;
>> }
>
>
>
>
> Note, both resources are loaded using the EditingDomain provided by
> the Editor.
>
> -Mark
>
> Ed Merks wrote:
>
>> Mark,
>>
>> All I can really suggest it to debug the behavior of this method in
>> ResourceImpl as it interprets the fragment path:
>>
>> protected EObject getEObject(List uriFragmentPath)
>>
>> The steps in the path are of the form
>> <feature-name>[.<index-in-many-valued-feature>], so they shouldn't be
>> qualified with prefixes.
>> In the latest code, the fragment is computed by XMLHelperImpl like this:
>>
>> protected String getURIFragment(Resource containingResource,
>> EObject object)
>> {
>> String result = containingResource.getURIFragment(object);
>> if (result.charAt(0) != '/')
>> {
>> String query = getURIFragmentQuery(containingResource,
>> object);
>> if (query != null)
>> {
>> result += "?" + query + "?";
>> }
>> }
>> return result;
>> }
>>
>> So the resource containing the referenced object determines the
>> fragment via its implementation of getURIFragment, which returns an
>> ID if there is one:
>>
>> public String getURIFragment(EObject eObject)
>> {
>> String id = EcoreUtil.getID(eObject);
>> if (id != null)
>> {
>> return id;
>> }
>> ...
>>
>> (This ResourceImpl method is overridden in XMLResourceImpl to also
>> consider extrinsic IDs, i.e., IDs not modeled as attributes on the
>> instances.)
>>
>>
>> Mark Diggory wrote:
>>
>>> I'm having some problems getting my model to resolve non-containment
>>> references that are uri fragments, ID's work great, but fragments
>>> fail. For example I have the following 2 references, the first works
>>> correctly, the second doesn't.
>>>
>>> <outline:reference>file:/C:/workspace/Test%20Project/test.xml#V13 </outline:reference>
>>>
>>>
>>> <outline:reference> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </outline:reference>
>>>
>>>
>>> I know that the path exists in my model and serialized xml. The only
>>> thing I havn't tried is attempting some sort of
>>> namespacing/prefixing on the elements. IE.
>>>
>>> #/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
>>>
>>> Is there something obvious I'm missing? I know the resource is
>>> already loaded for the first reference.
>>>
>>> Also, Is there any way I can force the containment references to use
>>> fragments instead of ID's?
>>>
>>> thanks,
>>> Mark Diggory
>>
>>
>>
--------------030401080302000803000407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark,<br>
<br>
I can debug a test case if I have it, or I can indicate where you need
to look to debug it yourself, which I tried to do. But showing me code
that I wrote myself won't help at all. ;-) Showing a stack trace
likely would...<br>
<br>
Given that you've told me there is a document root, I'm suspicious that
@codeBook.0 shouldn't be just @codeBook without the .0. If there is an
..<index>, the result of eGetting the feature will be cast to a
list, and the document root can only have one child element, so this
sounds wrong:<br>
<br>
<blockquote><small> public EObject eObjectForURIFragmentSegment(String
uriFragmentSegment)</small><br>
<small> {</small><br>
<b><small> int dotIndex = uriFragmentSegment.indexOf(".");</small><br>
<small> if (dotIndex == -1)</small></b><br>
<small> {</small><br>
<small> String name = uriFragmentSegment.substring(1);</small><br>
<small> EStructuralFeature eStructuralFeature =
eClass().getEStructuralFeature(name);</small><br>
<small> if (eStructuralFeature == null)</small><br>
<small> {</small><br>
<small> throw new IllegalArgumentException("The feature '" +
name + "' is not a valid feature");</small><br>
<small> }</small><br>
<small> return (EObject)eGet(eStructuralFeature, false);</small><br>
<small> }</small><br>
<small> else</small><br>
<small> {</small><br>
<small> String name = uriFragmentSegment.substring(1, dotIndex);</small><br>
<small> EStructuralFeature eStructuralFeature =
eClass().getEStructuralFeature(name);</small><br>
<small> if (eStructuralFeature == null)</small><br>
<small> {</small><br>
<small> throw new IllegalArgumentException("The feature '" +
name + "' is not a valid feature");</small><br>
<small> }</small><br>
<b><small> EList eList = (EList)eGet(eStructuralFeature, false);</small></b><br>
</blockquote>
<br>
<br>
Mark Diggory wrote:
<blockquote cite="mid4278DC9F.4010909@apache.org" type="cite">Ed, I'm
not really doing anything weird here. I simply have the below
references in my resource, the implementations of my resource are what
is generated by EMF codegen.
<br>
<br>
It seems find the DocumentRoot of the resource in getEObject(List
uriFragmentPath), but throws an exception when navigating into the
fragment further.
<br>
<br>
the fragment path looks like:
<br>
<br>
[, @codeBook.0, @stdyDscr.0, @citation.0, @titlStmt.0, @titl.0]
<br>
After stepping through the code, it appears that I get a runtime
exception here for the CodeBookImpl object in the ResourceSet:
<br>
<br>
<blockquote type="cite">public static EObject resolve(EObject proxy,
ResourceSet resourceSet)
<br>
{
<br>
URI proxyURI = ((InternalEObject)proxy).eProxyURI();
<br>
if (proxyURI != null)
<br>
{
<br>
try
<br>
{
<br>
EObject resolvedObject = null;
<br>
<br>
if (resourceSet != null)
<br>
{
<br>
resolvedObject = resourceSet.getEObject(proxyURI, true);
<br>
}
<br>
else
<br>
{
<br>
EPackage ePackage =
EPackage.Registry.INSTANCE.getEPackage(proxyURI.trimFragment ().toString());
<br>
if (ePackage != null)
<br>
{
<br>
Resource resource = ePackage.eResource();
<br>
if (resource != null)
<br>
{
<br>
resolvedObject =
resource.getEObject(proxyURI.fragment().toString());
<br>
}
<br>
}
<br>
}
<br>
<br>
if (resolvedObject != null && resolvedObject != proxy)
<br>
{
<br>
return resolve(resolvedObject, resourceSet);
<br>
}
<br>
}
<br>
catch (RuntimeException exception)
<br>
{
<br>
// Failure to resolve is ignored.
<br>
}
<br>
}
<br>
return proxy;
<br>
}
<br>
</blockquote>
<br>
<br>
<br>
Note, both resources are loaded using the EditingDomain provided by the
Editor.
<br>
<br>
-Mark
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Mark,
<br>
<br>
All I can really suggest it to debug the behavior of this method in
ResourceImpl as it interprets the fragment path:
<br>
<br>
protected EObject getEObject(List uriFragmentPath)
<br>
<br>
The steps in the path are of the form
<feature-name>[.<index-in-many-valued-f eature>], so they
shouldn't be qualified with prefixes. <br>
In the latest code, the fragment is computed by XMLHelperImpl like
this:
<br>
<br>
protected String getURIFragment(Resource containingResource,
<br>
EObject object)
<br>
{
<br>
String result = containingResource.getURIFragment(object);
<br>
if (result.charAt(0) != '/')
<br>
{
<br>
String query = getURIFragmentQuery(containingResource,
object);
<br>
if (query != null)
<br>
{
<br>
result += "?" + query + "?";
<br>
}
<br>
}
<br>
return result;
<br>
}
<br>
<br>
So the resource containing the referenced object determines the
fragment via its implementation of getURIFragment, which returns an ID
if there is one:
<br>
<br>
public String getURIFragment(EObject eObject)
<br>
{
<br>
String id = EcoreUtil.getID(eObject);
<br>
if (id != null)
<br>
{
<br>
return id;
<br>
}
<br>
...
<br>
<br>
(This ResourceImpl method is overridden in XMLResourceImpl to also
consider extrinsic IDs, i.e., IDs not modeled as attributes on the
instances.)
<br>
<br>
<br>
Mark Diggory wrote:
<br>
<br>
<blockquote type="cite">I'm having some problems getting my model
to resolve non-containment references that are uri fragments, ID's work
great, but fragments fail. For example I have the following 2
references, the first works correctly, the second doesn't.
<br>
<br>
<outline:reference><a class="moz-txt-link-freetext" href="file:/C:/workspace/Test%20Project/test.xml#V13">file:/C:/workspace/Test%20Project/test.xml#V13 </a></outline:reference>
<br>
<br>
<outline:reference><a class="moz-txt-link-freetext" href=" file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 "> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </a></outline:reference>
<br>
<br>
I know that the path exists in my model and serialized xml. The only
thing I havn't tried is attempting some sort of namespacing/prefixing
on the elements. IE.
<br>
<br>
#/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
<br>
<br>
Is there something obvious I'm missing? I know the resource is already
loaded for the first reference.
<br>
<br>
Also, Is there any way I can force the containment references to use
fragments instead of ID's?
<br>
<br>
thanks,
<br>
Mark Diggory
<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------030401080302000803000407--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #392664 is a reply to message #392660] |
Wed, 04 May 2005 18:02 |
Mark Diggory
Messages: 202
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Given that you've told me there is a document root, I'm suspicious that
> @codeBook.0 shouldn't be just @codeBook without the .0. If there is an
> ..<index>, the result of eGetting the feature will be cast to a list,
> and the document root can only have one child element, so this sounds wrong:
>
Apparently this was the issue. I was able to get at a number of the
proxies after doing this. I have to review all my paths and correct them.
That I have to reference codeBook differently because it can't occur
more than once is a little quirky from a syntax point of view.
In XPath, "//codeBook[0]" and "//codeBook" return the same if I only
have one codeBook element. While I know these fragments are much
different than xpath, it still seems wise approach the same logic, is
"//@codeBook.0" really that logically different from "//@codeBook" in
the case that it occurs only once? In fact, the opposite case is very
confusing, if I have more than one instance, what does my reference
return? I.E.
//@codeBook/@stdyDscr
If I have one stdyDscr (but stdyDscr can occur more than once), do I get
back the stdyDscr or do I get a List with one element? This is where the
concept of "NodeSets" in XSLT becomes very attractive. I get back a
NodeSet, it can contain one or many nodes.
//@codeBook/@stdyDscr.0
Its very clear I get back the first element, whether theres one or many.
My point is that instead of just referencing the generic modeled
relationship (a reference), I'm dealing with EMF/ecore implementation
details in my paths that have to do more with the internal nature of
that reference.
Again, many thanks for your most excellent help.
-Mark
|
|
|
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #392668 is a reply to message #392660] |
Wed, 04 May 2005 20:49 |
Mark Diggory
Messages: 202
Registered: July 2009 |
Senior Member |
|
|
I have another question to throw your way. How to I reference 'all'
occurrences of a reference that is of type "many" can I use
"#//@codeBook/@stdyDscr" to return all the stdyDscr if I have multiple
stdyDscr children?
-Mark
Ed Merks wrote:
> Mark,
>
> I can debug a test case if I have it, or I can indicate where you need
> to look to debug it yourself, which I tried to do. But showing me code
> that I wrote myself won't help at all. ;-) Showing a stack trace likely
> would...
>
> Given that you've told me there is a document root, I'm suspicious that
> @codeBook.0 shouldn't be just @codeBook without the .0. If there is an
> ..<index>, the result of eGetting the feature will be cast to a list,
> and the document root can only have one child element, so this sounds wrong:
>
> public EObject eObjectForURIFragmentSegment(String uriFragmentSegment)
> {
> * int dotIndex = uriFragmentSegment.indexOf(".");
> if (dotIndex == -1)*
> {
> String name = uriFragmentSegment.substring(1);
> EStructuralFeature eStructuralFeature =
> eClass().getEStructuralFeature(name);
> if (eStructuralFeature == null)
> {
> throw new IllegalArgumentException("The feature '" + name +
> "' is not a valid feature");
> }
> return (EObject)eGet(eStructuralFeature, false);
> }
> else
> {
> String name = uriFragmentSegment.substring(1, dotIndex);
> EStructuralFeature eStructuralFeature =
> eClass().getEStructuralFeature(name);
> if (eStructuralFeature == null)
> {
> throw new IllegalArgumentException("The feature '" + name +
> "' is not a valid feature");
> }
> * EList eList = (EList)eGet(eStructuralFeature, false);*
>
>
>
> Mark Diggory wrote:
>
>> Ed, I'm not really doing anything weird here. I simply have the below
>> references in my resource, the implementations of my resource are what
>> is generated by EMF codegen.
>>
>> It seems find the DocumentRoot of the resource in getEObject(List
>> uriFragmentPath), but throws an exception when navigating into the
>> fragment further.
>>
>> the fragment path looks like:
>>
>> [, @codeBook.0, @stdyDscr.0, @citation.0, @titlStmt.0, @titl.0]
>> After stepping through the code, it appears that I get a runtime
>> exception here for the CodeBookImpl object in the ResourceSet:
>>
>>> public static EObject resolve(EObject proxy, ResourceSet resourceSet)
>>> {
>>> URI proxyURI = ((InternalEObject)proxy).eProxyURI();
>>> if (proxyURI != null)
>>> {
>>> try
>>> {
>>> EObject resolvedObject = null;
>>>
>>> if (resourceSet != null)
>>> {
>>> resolvedObject = resourceSet.getEObject(proxyURI, true);
>>> }
>>> else
>>> {
>>> EPackage ePackage =
>>> EPackage.Registry.INSTANCE.getEPackage(proxyURI.trimFragment ().toString());
>>>
>>> if (ePackage != null)
>>> {
>>> Resource resource = ePackage.eResource();
>>> if (resource != null)
>>> {
>>> resolvedObject =
>>> resource.getEObject(proxyURI.fragment().toString());
>>> }
>>> }
>>> }
>>>
>>> if (resolvedObject != null && resolvedObject != proxy)
>>> {
>>> return resolve(resolvedObject, resourceSet);
>>> }
>>> }
>>> catch (RuntimeException exception)
>>> {
>>> // Failure to resolve is ignored.
>>> }
>>> }
>>> return proxy;
>>> }
>>
>>
>>
>>
>> Note, both resources are loaded using the EditingDomain provided by
>> the Editor.
>>
>> -Mark
>>
>> Ed Merks wrote:
>>
>>> Mark,
>>>
>>> All I can really suggest it to debug the behavior of this method in
>>> ResourceImpl as it interprets the fragment path:
>>>
>>> protected EObject getEObject(List uriFragmentPath)
>>>
>>> The steps in the path are of the form
>>> <feature-name>[.<index-in-many-valued-feature>], so they shouldn't be
>>> qualified with prefixes.
>>> In the latest code, the fragment is computed by XMLHelperImpl like this:
>>>
>>> protected String getURIFragment(Resource containingResource,
>>> EObject object)
>>> {
>>> String result = containingResource.getURIFragment(object);
>>> if (result.charAt(0) != '/')
>>> {
>>> String query = getURIFragmentQuery(containingResource,
>>> object);
>>> if (query != null)
>>> {
>>> result += "?" + query + "?";
>>> }
>>> }
>>> return result;
>>> }
>>>
>>> So the resource containing the referenced object determines the
>>> fragment via its implementation of getURIFragment, which returns an
>>> ID if there is one:
>>>
>>> public String getURIFragment(EObject eObject)
>>> {
>>> String id = EcoreUtil.getID(eObject);
>>> if (id != null)
>>> {
>>> return id;
>>> }
>>> ...
>>>
>>> (This ResourceImpl method is overridden in XMLResourceImpl to also
>>> consider extrinsic IDs, i.e., IDs not modeled as attributes on the
>>> instances.)
>>>
>>>
>>> Mark Diggory wrote:
>>>
>>>> I'm having some problems getting my model to resolve non-containment
>>>> references that are uri fragments, ID's work great, but fragments
>>>> fail. For example I have the following 2 references, the first works
>>>> correctly, the second doesn't.
>>>>
>>>> <outline:reference>file:/C:/workspace/Test%20Project/test.xml#V13 </outline:reference>
>>>>
>>>>
>>>> <outline:reference> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </outline:reference>
>>>>
>>>>
>>>> I know that the path exists in my model and serialized xml. The only
>>>> thing I havn't tried is attempting some sort of
>>>> namespacing/prefixing on the elements. IE.
>>>>
>>>> #/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
>>>>
>>>> Is there something obvious I'm missing? I know the resource is
>>>> already loaded for the first reference.
>>>>
>>>> Also, Is there any way I can force the containment references to use
>>>> fragments instead of ID's?
>>>>
>>>> thanks,
>>>> Mark Diggory
>>>
>>>
>>>
>
|
|
|
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #392669 is a reply to message #392668] |
Wed, 04 May 2005 21:06 |
Mark Diggory
Messages: 202
Registered: July 2009 |
Senior Member |
|
|
Let me try to clarify this further. It was incorrect to sate the
"reference" is "many", the actual reference can only have one instance
(one path) per parent object. IE
<outline:ref href="#//@codeBook/@stdyDscr"/>
The question is: Can I have that single reference return a list of
EObjects instead of an EObject like the syntax above might suggest.
-Mark
Mark Diggory wrote:
> I have another question to throw your way. How to I reference 'all'
> occurrences of a reference that is of type "many" can I use
> "#//@codeBook/@stdyDscr" to return all the stdyDscr if I have multiple
> stdyDscr children?
>
> -Mark
>
> Ed Merks wrote:
>
>> Mark,
>>
>> I can debug a test case if I have it, or I can indicate where you need
>> to look to debug it yourself, which I tried to do. But showing me
>> code that I wrote myself won't help at all. ;-) Showing a stack trace
>> likely would...
>>
>> Given that you've told me there is a document root, I'm suspicious
>> that @codeBook.0 shouldn't be just @codeBook without the .0. If there
>> is an ..<index>, the result of eGetting the feature will be cast to a
>> list, and the document root can only have one child element, so this
>> sounds wrong:
>>
>> public EObject eObjectForURIFragmentSegment(String
>> uriFragmentSegment)
>> {
>> * int dotIndex = uriFragmentSegment.indexOf(".");
>> if (dotIndex == -1)*
>> {
>> String name = uriFragmentSegment.substring(1);
>> EStructuralFeature eStructuralFeature =
>> eClass().getEStructuralFeature(name);
>> if (eStructuralFeature == null)
>> {
>> throw new IllegalArgumentException("The feature '" + name +
>> "' is not a valid feature");
>> }
>> return (EObject)eGet(eStructuralFeature, false);
>> }
>> else
>> {
>> String name = uriFragmentSegment.substring(1, dotIndex);
>> EStructuralFeature eStructuralFeature =
>> eClass().getEStructuralFeature(name);
>> if (eStructuralFeature == null)
>> {
>> throw new IllegalArgumentException("The feature '" + name +
>> "' is not a valid feature");
>> }
>> * EList eList = (EList)eGet(eStructuralFeature, false);*
>>
>>
>>
>> Mark Diggory wrote:
>>
>>> Ed, I'm not really doing anything weird here. I simply have the below
>>> references in my resource, the implementations of my resource are
>>> what is generated by EMF codegen.
>>>
>>> It seems find the DocumentRoot of the resource in getEObject(List
>>> uriFragmentPath), but throws an exception when navigating into the
>>> fragment further.
>>>
>>> the fragment path looks like:
>>>
>>> [, @codeBook.0, @stdyDscr.0, @citation.0, @titlStmt.0, @titl.0]
>>> After stepping through the code, it appears that I get a runtime
>>> exception here for the CodeBookImpl object in the ResourceSet:
>>>
>>>> public static EObject resolve(EObject proxy, ResourceSet resourceSet)
>>>> {
>>>> URI proxyURI = ((InternalEObject)proxy).eProxyURI();
>>>> if (proxyURI != null)
>>>> {
>>>> try
>>>> {
>>>> EObject resolvedObject = null;
>>>>
>>>> if (resourceSet != null)
>>>> {
>>>> resolvedObject = resourceSet.getEObject(proxyURI, true);
>>>> }
>>>> else
>>>> {
>>>> EPackage ePackage =
>>>> EPackage.Registry.INSTANCE.getEPackage(proxyURI.trimFragment ().toString());
>>>>
>>>> if (ePackage != null)
>>>> {
>>>> Resource resource = ePackage.eResource();
>>>> if (resource != null)
>>>> {
>>>> resolvedObject =
>>>> resource.getEObject(proxyURI.fragment().toString());
>>>> }
>>>> }
>>>> }
>>>>
>>>> if (resolvedObject != null && resolvedObject != proxy)
>>>> {
>>>> return resolve(resolvedObject, resourceSet);
>>>> }
>>>> }
>>>> catch (RuntimeException exception)
>>>> {
>>>> // Failure to resolve is ignored.
>>>> }
>>>> }
>>>> return proxy;
>>>> }
>>>
>>>
>>>
>>>
>>>
>>> Note, both resources are loaded using the EditingDomain provided by
>>> the Editor.
>>>
>>> -Mark
>>>
>>> Ed Merks wrote:
>>>
>>>> Mark,
>>>>
>>>> All I can really suggest it to debug the behavior of this method in
>>>> ResourceImpl as it interprets the fragment path:
>>>>
>>>> protected EObject getEObject(List uriFragmentPath)
>>>>
>>>> The steps in the path are of the form
>>>> <feature-name>[.<index-in-many-valued-feature>], so they shouldn't
>>>> be qualified with prefixes.
>>>> In the latest code, the fragment is computed by XMLHelperImpl like
>>>> this:
>>>>
>>>> protected String getURIFragment(Resource containingResource,
>>>> EObject object)
>>>> {
>>>> String result = containingResource.getURIFragment(object);
>>>> if (result.charAt(0) != '/')
>>>> {
>>>> String query = getURIFragmentQuery(containingResource,
>>>> object);
>>>> if (query != null)
>>>> {
>>>> result += "?" + query + "?";
>>>> }
>>>> }
>>>> return result;
>>>> }
>>>>
>>>> So the resource containing the referenced object determines the
>>>> fragment via its implementation of getURIFragment, which returns an
>>>> ID if there is one:
>>>>
>>>> public String getURIFragment(EObject eObject)
>>>> {
>>>> String id = EcoreUtil.getID(eObject);
>>>> if (id != null)
>>>> {
>>>> return id;
>>>> }
>>>> ...
>>>>
>>>> (This ResourceImpl method is overridden in XMLResourceImpl to also
>>>> consider extrinsic IDs, i.e., IDs not modeled as attributes on the
>>>> instances.)
>>>>
>>>>
>>>> Mark Diggory wrote:
>>>>
>>>>> I'm having some problems getting my model to resolve
>>>>> non-containment references that are uri fragments, ID's work great,
>>>>> but fragments fail. For example I have the following 2 references,
>>>>> the first works correctly, the second doesn't.
>>>>>
>>>>> <outline:reference>file:/C:/workspace/Test%20Project/test.xml#V13 </outline:reference>
>>>>>
>>>>>
>>>>> <outline:reference> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </outline:reference>
>>>>>
>>>>>
>>>>> I know that the path exists in my model and serialized xml. The
>>>>> only thing I havn't tried is attempting some sort of
>>>>> namespacing/prefixing on the elements. IE.
>>>>>
>>>>> #/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
>>>>>
>>>>> Is there something obvious I'm missing? I know the resource is
>>>>> already loaded for the first reference.
>>>>>
>>>>> Also, Is there any way I can force the containment references to
>>>>> use fragments instead of ID's?
>>>>>
>>>>> thanks,
>>>>> Mark Diggory
>>>>
>>>>
>>>>
>>>>
>>
|
|
|
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #392675 is a reply to message #392669] |
Thu, 05 May 2005 11:19 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Mark,
No. When used in the context of a reference to another object, the
fragment path is expected to resolve to a single EObject. It was only
really ever intended for that one purpose.
Mark Diggory wrote:
> Let me try to clarify this further. It was incorrect to sate the
> "reference" is "many", the actual reference can only have one instance
> (one path) per parent object. IE
>
> <outline:ref href="#//@codeBook/@stdyDscr"/>
>
> The question is: Can I have that single reference return a list of
> EObjects instead of an EObject like the syntax above might suggest.
>
> -Mark
>
> Mark Diggory wrote:
>
>> I have another question to throw your way. How to I reference 'all'
>> occurrences of a reference that is of type "many" can I use
>> "#//@codeBook/@stdyDscr" to return all the stdyDscr if I have
>> multiple stdyDscr children?
>>
>> -Mark
>>
>> Ed Merks wrote:
>>
>>> Mark,
>>>
>>> I can debug a test case if I have it, or I can indicate where you
>>> need to look to debug it yourself, which I tried to do. But showing
>>> me code that I wrote myself won't help at all. ;-) Showing a stack
>>> trace likely would...
>>>
>>> Given that you've told me there is a document root, I'm suspicious
>>> that @codeBook.0 shouldn't be just @codeBook without the .0. If
>>> there is an ..<index>, the result of eGetting the feature will be
>>> cast to a list, and the document root can only have one child
>>> element, so this sounds wrong:
>>>
>>> public EObject eObjectForURIFragmentSegment(String
>>> uriFragmentSegment)
>>> {
>>> * int dotIndex = uriFragmentSegment.indexOf(".");
>>> if (dotIndex == -1)*
>>> {
>>> String name = uriFragmentSegment.substring(1);
>>> EStructuralFeature eStructuralFeature =
>>> eClass().getEStructuralFeature(name);
>>> if (eStructuralFeature == null)
>>> {
>>> throw new IllegalArgumentException("The feature '" + name +
>>> "' is not a valid feature");
>>> }
>>> return (EObject)eGet(eStructuralFeature, false);
>>> }
>>> else
>>> {
>>> String name = uriFragmentSegment.substring(1, dotIndex);
>>> EStructuralFeature eStructuralFeature =
>>> eClass().getEStructuralFeature(name);
>>> if (eStructuralFeature == null)
>>> {
>>> throw new IllegalArgumentException("The feature '" + name +
>>> "' is not a valid feature");
>>> }
>>> * EList eList = (EList)eGet(eStructuralFeature, false);*
>>>
>>>
>>>
>>> Mark Diggory wrote:
>>>
>>>> Ed, I'm not really doing anything weird here. I simply have the
>>>> below references in my resource, the implementations of my resource
>>>> are what is generated by EMF codegen.
>>>>
>>>> It seems find the DocumentRoot of the resource in getEObject(List
>>>> uriFragmentPath), but throws an exception when navigating into the
>>>> fragment further.
>>>>
>>>> the fragment path looks like:
>>>>
>>>> [, @codeBook.0, @stdyDscr.0, @citation.0, @titlStmt.0, @titl.0]
>>>> After stepping through the code, it appears that I get a runtime
>>>> exception here for the CodeBookImpl object in the ResourceSet:
>>>>
>>>>> public static EObject resolve(EObject proxy, ResourceSet resourceSet)
>>>>> {
>>>>> URI proxyURI = ((InternalEObject)proxy).eProxyURI();
>>>>> if (proxyURI != null)
>>>>> {
>>>>> try
>>>>> {
>>>>> EObject resolvedObject = null;
>>>>>
>>>>> if (resourceSet != null)
>>>>> {
>>>>> resolvedObject = resourceSet.getEObject(proxyURI, true);
>>>>> }
>>>>> else
>>>>> {
>>>>> EPackage ePackage =
>>>>> EPackage.Registry.INSTANCE.getEPackage(proxyURI.trimFragment ().toString());
>>>>>
>>>>> if (ePackage != null)
>>>>> {
>>>>> Resource resource = ePackage.eResource();
>>>>> if (resource != null)
>>>>> {
>>>>> resolvedObject =
>>>>> resource.getEObject(proxyURI.fragment().toString());
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> if (resolvedObject != null && resolvedObject != proxy)
>>>>> {
>>>>> return resolve(resolvedObject, resourceSet);
>>>>> }
>>>>> }
>>>>> catch (RuntimeException exception)
>>>>> {
>>>>> // Failure to resolve is ignored.
>>>>> }
>>>>> }
>>>>> return proxy;
>>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Note, both resources are loaded using the EditingDomain provided by
>>>> the Editor.
>>>>
>>>> -Mark
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Mark,
>>>>>
>>>>> All I can really suggest it to debug the behavior of this method
>>>>> in ResourceImpl as it interprets the fragment path:
>>>>>
>>>>> protected EObject getEObject(List uriFragmentPath)
>>>>>
>>>>> The steps in the path are of the form
>>>>> <feature-name>[.<index-in-many-valued-feature>], so they shouldn't
>>>>> be qualified with prefixes.
>>>>> In the latest code, the fragment is computed by XMLHelperImpl like
>>>>> this:
>>>>>
>>>>> protected String getURIFragment(Resource containingResource,
>>>>> EObject object)
>>>>> {
>>>>> String result = containingResource.getURIFragment(object);
>>>>> if (result.charAt(0) != '/')
>>>>> {
>>>>> String query = getURIFragmentQuery(containingResource,
>>>>> object);
>>>>> if (query != null)
>>>>> {
>>>>> result += "?" + query + "?";
>>>>> }
>>>>> }
>>>>> return result;
>>>>> }
>>>>>
>>>>> So the resource containing the referenced object determines the
>>>>> fragment via its implementation of getURIFragment, which returns
>>>>> an ID if there is one:
>>>>>
>>>>> public String getURIFragment(EObject eObject)
>>>>> {
>>>>> String id = EcoreUtil.getID(eObject);
>>>>> if (id != null)
>>>>> {
>>>>> return id;
>>>>> }
>>>>> ...
>>>>>
>>>>> (This ResourceImpl method is overridden in XMLResourceImpl to also
>>>>> consider extrinsic IDs, i.e., IDs not modeled as attributes on the
>>>>> instances.)
>>>>>
>>>>>
>>>>> Mark Diggory wrote:
>>>>>
>>>>>> I'm having some problems getting my model to resolve
>>>>>> non-containment references that are uri fragments, ID's work
>>>>>> great, but fragments fail. For example I have the following 2
>>>>>> references, the first works correctly, the second doesn't.
>>>>>>
>>>>>> <outline:reference>file:/C:/workspace/Test%20Project/test.xml#V13 </outline:reference>
>>>>>>
>>>>>>
>>>>>> <outline:reference> file:/C:/workspace/Test%20Project/test.xml#//@codeBook.0/@st dyDscr.0/@citation.0/@titlStmt.0/@titl.0 </outline:reference>
>>>>>>
>>>>>>
>>>>>> I know that the path exists in my model and serialized xml. The
>>>>>> only thing I havn't tried is attempting some sort of
>>>>>> namespacing/prefixing on the elements. IE.
>>>>>>
>>>>>> #/@ddi:codeBook.0/@ddi:stdyDscr.0/@ddi:citation.0
>>>>>>
>>>>>> Is there something obvious I'm missing? I know the resource is
>>>>>> already loaded for the first reference.
>>>>>>
>>>>>> Also, Is there any way I can force the containment references to
>>>>>> use fragments instead of ID's?
>>>>>>
>>>>>> thanks,
>>>>>> Mark Diggory
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: uri fragments vs. ID's in serialized Non-Containment references [message #1008275 is a reply to message #1008103] |
Sat, 09 February 2013 10:09 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Roza,
Comments below.
On 09/02/2013 1:28 AM, Roza Ghamari wrote:
>
> Hi,
>
> I think my question is kind of related to this discussion. I saw that
> you (Ed Mark) mentioned that the items that are in a list are
> referenced by their index and not by the ID.
They're referenced by the ID if they have one. Also, on a containment
reference (on any reference actually, but for serialization it's most
useful for containment references) you can define in your Ecore model
eKeys for the reference, i.e., the combination of the referenced
EClass's EAttributes that uniquely identify an instance within that one
containment references list of referenced EObjects.
> The problem I have is that my files can be edited separately so this
> indices can change, and I need to be able to reference an object in a
> list by its ID.
Or by something that makes it unique within that one list.
> Is there any way to do this? i.e. to always have the eProxyURI
> reference an object (either single or multiple) by its ID?
Yes, you can define an EAttribute to be an ID, but using
EReference.eKeys might be better. It's hard to manage ID uniqueness...
> Thanks for your help in advance,
> Roza
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Tue Apr 16 07:52:10 GMT 2024
Powered by FUDForum. Page generated in 0.26034 seconds |
] 
Search
Help
Register
Login
Home
