Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tigerstripe-dev] Refactoring API
Title: 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

Back to the top