| Problems with read-only resources in an editing domain [message #423135] |
Tue, 23 September 2008 17:04  |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
As I tell some days ago, I got to load CDOResources from an XMI based
model. So I can open up an editor for an XMIResource and, if a
CDOResource if referenced somewhere (through its URI), is will be loaded
automatically. However, the editor doesn't let me modify the CDOResource
because it's loaded in the EditingDomain's ResourceSet as "read-only".
To determine if a resource is read-only:
- AdapterFactoryEditingDomain. resourceToReadOnlyMap should be populated
with the proper values.
or
- AdapterFactoryEditingDomain.isReadOnly(URI) returns "false".
The first one doesn't look like a feasible option: a generated sample
Ecore editor never modifies the "resourceToReadOnlyMap".
In the case of the second option, isReadOnly(URI) always returns "true"
for a CDOResource URI, which is the expected according to its
implementation:
protected boolean isReadOnlyURI(URI uri)
{
if (uri.isArchive())
{
return isReadOnlyURI(URI.createURI(uri.authority()));
}
return !uri.isPlatformResource() && (uri.isRelative() ||
!uri.isFile());
}
Since CDO uses URI like this:
cdo://1ff5d226-b1f0-40fb-aba2-0c31b38c764f/myResource
This method will never return false for CDO URI:
CDOResources are not an Archive, nor PlatformResources, and neither a File.
How to get a resource not read-only within an editing domain then?
isReadOnlyURI(URI) seems to be married with the idea of files: anything
that is not a file will always be read-only. I don't feel that's always
necessarily true. This situation proves it.
What do you think? Is the criteria defined in isReadOnlyURI() maybe
incomplete?
Maybe I'm missing some point of the "read-only resource" thing...
Your feedback is very much appreciated :)
Regards,
Víctor.
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 1.50087 seconds
] 
Search
Help
Register
Login
Home
