Re: [tigerstripe-dev] Refactoring API

[Eric Dillon <erdillon@xxxxxxxxx>]

Hi Yuri,

With your fix, everything seems to be now working properly... I'm testing
some more :-).

Eric


On 6/5/08 3:49 AM, "Yuri Strot" <yuri@xxxxxxxxx> wrote:

> 
> Hi Eric,
> 
> thanks a lot, situation that you described is a TAF bug and I've added it
> here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=235762.
> You really needn't care about have your refactored URI children or not because
> if there are no children you will have:
> 
> changed(oldUri, newUri, true) = changed(oldUri, newUri, false)
> 
> I'll close this bug in the nearest time.
> 
> --
> Best regards,
> Yuri Strot
> 
> ----- Original Message -----
> From: Eric Dillon <erdillon@xxxxxxxxx>
> To: Tigerstripe developers list <tigerstripe-dev@xxxxxxxxxxx>, Eric Dillon
> <erdillon@xxxxxxxxx>, Andrey Platov <andrey@xxxxxxxxx>
> Sent: Thu, 5 Jun 2008 00:16:59 +0700 (NOVST)
> Subject: Re: [tigerstripe-dev] Refactoring API
> 
> All right, I gave it a shot.
> What I did is that I set the ³affectChildren boolean² to true. This works
> now fine for an Artifact being renamed (i.e. All annotations on its
> attributes are moved properly).
> But when I rename an Attribute (with the boolean set to true) it doesn¹t
> work. In other word, if the URI has no children I currently need to set the
> boolean to false for it to work.
> I would expect that setting to ³true² should account for the fact that no
> children are there to be affected and perform the right logic no matter
> what?
> 
> Let me know what you think.
> Eric
> 
> 
> On 6/4/08 8:14 AM, "Eric Dillon" <erdillon@xxxxxxxxx> wrote:
> 
>> Yes, this sounds good. It seems the Hierarchical URI case is generic enough
>> that the TAF should cover it. As for other cases, it think this should be the
>> responsibility of the client indeed and the mechanism you mention here should
>> work.
>> 
>> I¹ll try Yuri¹s implementation today.
>> 
>> Let¹s talk some more on the phone about this.
>> 
>> Eric
>> 
>> 
>> On 6/4/08 12:05 AM, "Andrey Platov" <andrey@xxxxxxxxx> wrote:
>> 
>>> Hi Eric,
>>> 
>>> Thanks for pointing to the problem :) Initially we did not put any semantic
>>> into URI, however it looks like we shall have at least hierarchical URIs as
>>> an option. 
>>> 
>>> What we'd like to propose for currently releasing version is to add boolean
>>> "affectChildren" parameter to both "delete" and "change" methods, which when
>>> true will perform required operation on all the children in the hierarchy.
>>> 
>>> Yuri will provide implementation this morning assuming explicitly
>>> hierarchical URI formats like scheme,segments,fragment. For more complex
>>> cases (when clients only knows about URI structure) in future TAF may allow
>>> clients to provide a kind of IURIChildrenProvider instances (which will
>>> return children URIs for particular one) - something like JFace content
>>> providers, and other helper structures allowing to perform refactoring for
>>> URIs with unknown (to TAF) structure... But let's leave this for future.
>>> 
>>> Do you think something like this will work for now?
>>> 
>>> Kind Regards,
>>> Andrey
>>> 
>>> ----- Original Message -----
>>> From: "Eric Dillon" <erdillon@xxxxxxxxx>
>>> To: "Tigerstripe developers list" <tigerstripe-dev@xxxxxxxxxxx>, "Andrey
>>> Platov" <andrey@xxxxxxxxx>
>>> Sent: Wednesday, June 4, 2008 5:29:08 AM GMT +06:00 Almaty, Novosibirsk
>>> Subject: Re: [tigerstripe-dev] Refactoring API
>>> 
>>> Re: [tigerstripe-dev] Refactoring API Hi Andrey,
>>> 
>>> Ok, so I¹ve hooked up Tigerstripe notifications to the refactoring support,
>>> and I¹ve been doing a bit of testing/playing.
>>> On simple cases, things work, but then on the ³interesting case² :-) things
>>> don¹t work.
>>> 
>>> In particular, let¹s say I have an annotation on an artifact, and on an
>>> attribute of that artifact. That means I have annotations on:
>>> 
>>> tigerstripe:/Foo/com.mycompany.Artifact
>>> tigerstripe:/Foo/com.mycompany.Artifact#attr
>>> 
>>> Now, if I rename the attribute from ³attr² to ³attr2² everything is fine
>>> (the
>>> simple case).
>>> If I remove the Artifact to ³Artifact2², I end up with annotations on
>>> 
>>> tigerstripe:/Foo/com.mycompany.Artifact2
>>> tigerstripe:/Foo/com.mycompany.Artifact#attr (<--- not Artifact2#attr),
>>> which
>>> object doesn¹t exist anymore as attr is now in Artifact2.
>>> 
>>> Even worse, what if I rename the project to ³Foo2²?
>>> 
>>> What is the best way to handle this? These URIs are all Hierarchical, so is
>>> there a way to get all annotations for a ³partial² URI? Should the framework
>>> be handling the containment, or should the client do it?
>>> 
>>> Note that I¹m realizing that our URIs should look like:
>>> tigerstripe:/Foo/com/mycompany/Artifact2#attr so the containment is truly
>>> explicit... Then the TAF might be able to deal with it? (Scheme +
>>> segments[4]
>>> + fragment)
>>> 
>>> Eric
>>> 
>>> On 6/3/08 6:14 AM, "Andrey Platov" <andrey@xxxxxxxxx> wrote:
>>> 
>>>> Hi folks,
>>>> 
>>>> Initial API to support refactoring is done and pretty simple, see:
>>>> http://wiki.eclipse.org/Howto:_Register_Refactoring_Support
>>>> 
>>>> Kind Regards,
>>>> Andrey
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> tigerstripe-dev mailing list
>>>> tigerstripe-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev
>>>> 
>>>> 
>>>> 
>>> _______________________________________________
>>> tigerstripe-dev mailing list
>>> tigerstripe-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev
> 
>