Home » Modeling » TMF (Xtext) » Refactoring nested elements/references
|
| Re: Refactoring nested elements/references [message #892448 is a reply to message #892381] |
Thu, 28 June 2012 09:00   |
|
Did you implement the refactoring on your own? Refactoring support is
already there in Xtext 2.x and above to address excatly this problem via
LTK.
Please have a look at the RenameRefactoringFragment in you mwe2 file.
Cheers,
Holger
Am 28.06.12 01:21, schrieb Mary Komor:
> Hi,
>
> I feel like I have been chasing my tail for a while now and hope to get
> some pointers here...
>
> I have refactor/rename working nicely for the most part. However, I have
> this scenario which I haven't managed to figure out yet:
>
> Consider a case similar to Java/C++ method -- a method contains a list
> of statements (expressions). In the case of a recursive method, a
> statement within that method references the method. The source URI
> fragment for the statement that makes the recursive call contains the
> method name in it. When the method is renamed, the following happens:
>
> 1. Find the target element (method). Check.
> 2. Find all references (statement containing reference to method). Check.
> 3. Rename declaration (method renamed). Check.
> 3. Update references - Failed! The reason being that the referring
> element/statement can no longer be found because the method has already
> been renamed.
>
> Am I missing something obvious here? I shouldn't need to put all the
> statements within the method into the "dependents" list, should I?
>
> Thanks!
>
> Mary
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
| |
| Re: Refactoring nested elements/references [message #892780 is a reply to message #892481] |
Fri, 29 June 2012 15:49 |
 Mary Komor
Messages: 61
Registered: July 2009 |
Member |
|
|
Maybe I'm missing something... let me try to explain my case again..
So, in the RenamedElementTracker, I do see...
- renamed element (say, MethodA) and the URI (say, /fragment/path/MethodA)
- find references to target element (say, a statement within Method that
makes a recursive call to MethodA)
note that the source URI for the statement is
/fragment/path/MethodA/statement.0
- apply declaration refactoring
- recalculate the URI for the renamed element (say, new URI for the method
is /fragment/path/MethodB)
- update references -- this fails because in order to update the reference,
it first tries to find the reference (the statement within the method). But
that fails because the source URI for the statement contains the old method
name -- /fragment/path/MethodA/statement.0
"Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
news:jshhg1$ki4$1@xxxxxxxxe.org...
> This is exactly the purpose of the
> org.eclipse.xtext.ui.refactoring.impl.RenamedElementTracker:
>
> -Sample a list of renamed elements and their URIs
> -Apply the declaration refactoring
> -recalculate the URIs for the renamed elements
>
> The resulting URI to URI map is used in the IReferenceUpdater.
>
>
>
> Am 28.06.12 01:21, schrieb Mary Komor:
>> Hi,
>>
>> I feel like I have been chasing my tail for a while now and hope to get
>> some pointers here...
>>
>> I have refactor/rename working nicely for the most part. However, I have
>> this scenario which I haven't managed to figure out yet:
>>
>> Consider a case similar to Java/C++ method -- a method contains a list
>> of statements (expressions). In the case of a recursive method, a
>> statement within that method references the method. The source URI
>> fragment for the statement that makes the recursive call contains the
>> method name in it. When the method is renamed, the following happens:
>>
>> 1. Find the target element (method). Check.
>> 2. Find all references (statement containing reference to method). Check.
>> 3. Rename declaration (method renamed). Check.
>> 3. Update references - Failed! The reason being that the referring
>> element/statement can no longer be found because the method has already
>> been renamed.
>>
>> Am I missing something obvious here? I shouldn't need to put all the
>> statements within the method into the "dependents" list, should I?
>>
>> Thanks!
>>
>> Mary
>
>
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
|
|
|
| Re: Refactoring nested elements/references [message #892944 is a reply to message #892780] |
Mon, 02 July 2012 06:01 |
Jan Koehnlein
Messages: 760
Registered: July 2009
Location: Hamburg |
Senior Member |
|
|
That's because you implemented the IRenameElemenStrategy wrong:
You have to modify the semantic element directly, like calling setName()
on it. The tracker keeps a ref to this element when renaming it. It's
the only chance it has to find it again. If that's not possible in your
case, you have to implement your own tracker, or fix the rename strategy.
Am 29.06.12 17:49, schrieb Mary Komor:
> Maybe I'm missing something... let me try to explain my case again..
>
> So, in the RenamedElementTracker, I do see...
>
> - renamed element (say, MethodA) and the URI (say, /fragment/path/MethodA)
>
> - find references to target element (say, a statement within Method that
> makes a recursive call to MethodA)
> note that the source URI for the statement is
> /fragment/path/MethodA/statement.0
>
> - apply declaration refactoring
>
> - recalculate the URI for the renamed element (say, new URI for the
> method is /fragment/path/MethodB)
>
> - update references -- this fails because in order to update the
> reference, it first tries to find the reference (the statement within
> the method). But that fails because the source URI for the statement
> contains the old method name -- /fragment/path/MethodA/statement.0
>
>
>
> "Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
> news:jshhg1$ki4$1@xxxxxxxxe.org...
>> This is exactly the purpose of the
>> org.eclipse.xtext.ui.refactoring.impl.RenamedElementTracker:
>>
>> -Sample a list of renamed elements and their URIs
>> -Apply the declaration refactoring
>> -recalculate the URIs for the renamed elements
>>
>> The resulting URI to URI map is used in the IReferenceUpdater.
>>
>>
>>
>> Am 28.06.12 01:21, schrieb Mary Komor:
>>> Hi,
>>>
>>> I feel like I have been chasing my tail for a while now and hope to get
>>> some pointers here...
>>>
>>> I have refactor/rename working nicely for the most part. However, I have
>>> this scenario which I haven't managed to figure out yet:
>>>
>>> Consider a case similar to Java/C++ method -- a method contains a list
>>> of statements (expressions). In the case of a recursive method, a
>>> statement within that method references the method. The source URI
>>> fragment for the statement that makes the recursive call contains the
>>> method name in it. When the method is renamed, the following happens:
>>>
>>> 1. Find the target element (method). Check.
>>> 2. Find all references (statement containing reference to method).
>>> Check.
>>> 3. Rename declaration (method renamed). Check.
>>> 3. Update references - Failed! The reason being that the referring
>>> element/statement can no longer be found because the method has already
>>> been renamed.
>>>
>>> Am I missing something obvious here? I shouldn't need to put all the
>>> statements within the method into the "dependents" list, should I?
>>>
>>> Thanks!
>>>
>>> Mary
>>
>>
>> --
>> Need professional support for Eclipse Modeling?
>> Go visit: http://xtext.itemis.com
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: Refactoring nested elements/references [message #898638 is a reply to message #892944] |
Fri, 27 July 2012 00:09 |
Mary Komor
Messages: 61
Registered: July 2009 |
Member |
|
|
The problem was with my customization to the IDependentElementsCalculator --
I was not calculating all the dependents correctly. I have now fixed the
problem and it is working well. Thanks!
Mary
"Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
news:jsrdf8$r3$1@xxxxxxxxe.org...
> That's because you implemented the IRenameElemenStrategy wrong:
> You have to modify the semantic element directly, like calling setName()
> on it. The tracker keeps a ref to this element when renaming it. It's the
> only chance it has to find it again. If that's not possible in your case,
> you have to implement your own tracker, or fix the rename strategy.
>
> Am 29.06.12 17:49, schrieb Mary Komor:
>> Maybe I'm missing something... let me try to explain my case again..
>>
>> So, in the RenamedElementTracker, I do see...
>>
>> - renamed element (say, MethodA) and the URI (say,
>> /fragment/path/MethodA)
>>
>> - find references to target element (say, a statement within Method that
>> makes a recursive call to MethodA)
>> note that the source URI for the statement is
>> /fragment/path/MethodA/statement.0
>>
>> - apply declaration refactoring
>>
>> - recalculate the URI for the renamed element (say, new URI for the
>> method is /fragment/path/MethodB)
>>
>> - update references -- this fails because in order to update the
>> reference, it first tries to find the reference (the statement within
>> the method). But that fails because the source URI for the statement
>> contains the old method name -- /fragment/path/MethodA/statement.0
>>
>>
>>
>> "Jan Koehnlein" <jan.koehnlein@xxxxxxxx> wrote in message
>> news:jshhg1$ki4$1@xxxxxxxxe.org...
>>> This is exactly the purpose of the
>>> org.eclipse.xtext.ui.refactoring.impl.RenamedElementTracker:
>>>
>>> -Sample a list of renamed elements and their URIs
>>> -Apply the declaration refactoring
>>> -recalculate the URIs for the renamed elements
>>>
>>> The resulting URI to URI map is used in the IReferenceUpdater.
>>>
>>>
>>>
>>> Am 28.06.12 01:21, schrieb Mary Komor:
>>>> Hi,
>>>>
>>>> I feel like I have been chasing my tail for a while now and hope to get
>>>> some pointers here...
>>>>
>>>> I have refactor/rename working nicely for the most part. However, I
>>>> have
>>>> this scenario which I haven't managed to figure out yet:
>>>>
>>>> Consider a case similar to Java/C++ method -- a method contains a list
>>>> of statements (expressions). In the case of a recursive method, a
>>>> statement within that method references the method. The source URI
>>>> fragment for the statement that makes the recursive call contains the
>>>> method name in it. When the method is renamed, the following happens:
>>>>
>>>> 1. Find the target element (method). Check.
>>>> 2. Find all references (statement containing reference to method).
>>>> Check.
>>>> 3. Rename declaration (method renamed). Check.
>>>> 3. Update references - Failed! The reason being that the referring
>>>> element/statement can no longer be found because the method has already
>>>> been renamed.
>>>>
>>>> Am I missing something obvious here? I shouldn't need to put all the
>>>> statements within the method into the "dependents" list, should I?
>>>>
>>>> Thanks!
>>>>
>>>> Mary
>>>
>>>
>>> --
>>> Need professional support for Eclipse Modeling?
>>> Go visit: http://xtext.itemis.com
>>
>
>
> --
> Need professional support for Eclipse Modeling?
> Go visit: http://xtext.itemis.com
|
|
|
Goto Forum:
Current Time: Fri Apr 19 07:14:22 GMT 2024
Powered by FUDForum. Page generated in 0.03260 seconds |
] 
Search
Help
Register
Login
Home
