| Refactor : File move/rename [message #414107] |
Thu, 25 October 2007 04:04  |
Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi,
We use granular EMF XML files - one per top level object. We treat a
workspace resource (just like a Java file) and we want to support refactor
whereby the user can rename or move an XML file.
If the EObject in that XML file is referenced by EObjects in other XML
files, we need to update the references to that object.
I see two major options - using the cross-reference map reset (unset->set)
every reference to objects in the new file or do it without EMF just by
progamatically editing the XML files. Actually, the latter seems a lot
simpler.
Has anyone encountered/solved this before or know of another approach?
Many thanks,
Andy
|
|
|
| Re: Refactor : File move/rename [message #414114 is a reply to message #414107] |
Thu, 25 October 2007 10:25  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030908010602080708010008
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Andy,
Comments below.
Andy Steady wrote:
> Hi,
>
> We use granular EMF XML files - one per top level object. We treat a
> workspace resource (just like a Java file) and we want to support
> refactor whereby the user can rename or move an XML file.
You need to be able to find all references to the things being renamed.
>
> If the EObject in that XML file is referenced by EObjects in other XML
> files, we need to update the references to that object.
Yep.
>
> I see two major options - using the cross-reference map reset
> (unset->set) every reference to objects in the new file or do it
> without EMF just by progamatically editing the XML files. Actually,
> the latter seems a lot simpler.
That seems like overkill. For the latter approach, this option can be
very useful since all cross resource references will be recorded as XML
entities at the start of the document and one could literally just
change the resource pointed to by the entity.
/**
* A {@link ResourceEntityHandler} value that will be used during
load to record entity definitions
* and during save to encode cross document reference URIs as
entities;
* the default value is null, in which case entities will not be
defined at all.
* DOM does not support creating entities in the document type
declaration,
* so this option does nothing when converting directly to DOM.
* @see ResourceEntityHandlerImpl
*/
String OPTION_RESOURCE_ENTITY_HANDLER = "RESOURCE_ENTITY_HANDLER";
However, if you are loading the resources to find the cross references
in the first place, just change the URI of the moved resource to be the
URI of the new location and then save the referencing resource. Even if
the resource has already moved, you could define a URI mapping in the
resource set's URI converter that redirects the old URI to the new URI,
load all the referencing resources ensuring all proxies are resolved
(EcoreUtil.resolveAll) and hence redirected to the new location, and
then save the referencing resources.
>
> Has anyone encountered/solved this before or know of another approach?
You really should not need to change each reference. Playing with the
resource URIs themselves and with mappings for them should suffice.
>
> Many thanks,
>
> Andy
>
--------------030908010602080708010008
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andy,<br>
<br>
Comments below.<br>
<br>
<br>
Andy Steady wrote:
<blockquote
cite="mid:2365cf9df28bab8f06a613f849fd6884$1@www.eclipse.org"
type="cite">Hi,
<br>
<br>
We use granular EMF XML files - one per top level object. We treat a
workspace resource (just like a Java file) and we want to support
refactor whereby the user can rename or move an XML file.
<br>
</blockquote>
You need to be able to find all references to the things being renamed.<br>
<blockquote
cite="mid:2365cf9df28bab8f06a613f849fd6884$1@www.eclipse.org"
type="cite"><br>
If the EObject in that XML file is referenced by EObjects in other XML
files, we need to update the references to that object.
<br>
</blockquote>
Yep.<br>
<blockquote
cite="mid:2365cf9df28bab8f06a613f849fd6884$1@www.eclipse.org"
type="cite"><br>
I see two major options - using the cross-reference map reset
(unset->set) every reference to objects in the new file or do it
without EMF just by progamatically editing the XML files. Actually, the
latter seems a lot simpler.
<br>
</blockquote>
That seems like overkill.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Refactor : File move/rename [message #414136 is a reply to message #414114] |
Thu, 25 October 2007 17:24 |
| Eclipse User |
|
|
|
Originally posted by: andrew_steady.hotmail.com
Hi Ed,
Thanks for your ideas ... hurrah its working!
Took me a while to get it working as I hadn't done an ECoreUtil.resolveAll
*before* my refactor so all the referencing objects simply loaded
unresolved proxies after the refactor during their save, but now I do its
working.
Thanks again Ed... really.
Andy
Ed Merks wrote:
> Andy,
> Comments below.
> Andy Steady wrote:
>> Hi,
>>
>> We use granular EMF XML files - one per top level object. We treat a
>> workspace resource (just like a Java file) and we want to support
>> refactor whereby the user can rename or move an XML file.
> You need to be able to find all references to the things being renamed.
>>
>> If the EObject in that XML file is referenced by EObjects in other XML
>> files, we need to update the references to that object.
> Yep.
>>
>> I see two major options - using the cross-reference map reset
>> (unset->set) every reference to objects in the new file or do it
>> without EMF just by progamatically editing the XML files. Actually,
>> the latter seems a lot simpler.
> That seems like overkill. For the latter approach, this option can be
> very useful since all cross resource references will be recorded as XML
> entities at the start of the document and one could literally just
> change the resource pointed to by the entity.
> /**
> * A {@link ResourceEntityHandler} value that will be used during
> load to record entity definitions
> * and during save to encode cross document reference URIs as
> entities;
> * the default value is null, in which case entities will not be
> defined at all.
> * DOM does not support creating entities in the document type
> declaration,
> * so this option does nothing when converting directly to DOM.
> * @see ResourceEntityHandlerImpl
> */
> String OPTION_RESOURCE_ENTITY_HANDLER = "RESOURCE_ENTITY_HANDLER";
> However, if you are loading the resources to find the cross references
> in the first place, just change the URI of the moved resource to be the
> URI of the new location and then save the referencing resource. Even if
> the resource has already moved, you could define a URI mapping in the
> resource set's URI converter that redirects the old URI to the new URI,
> load all the referencing resources ensuring all proxies are resolved
> (EcoreUtil.resolveAll) and hence redirected to the new location, and
> then save the referencing resources.
>>
>> Has anyone encountered/solved this before or know of another approach?
> You really should not need to change each reference. Playing with the
> resource URIs themselves and with mappings for them should suffice.
>>
>> Many thanks,
>>
>> Andy
>>
|
|
|
Powered by
FUDForum. Page generated in 0.03643 seconds
] 
Search
Help
Register
Login
Home
