Re: Outline view for Groovy DSL

Hi Maxime,

What I'd recommend doing first is checking out the Groovy source code
and directly changing the getAdapter method in the GroovyEditor class.

Alternatively, you can create your own editor that subclasses the
GroovyEditor and then also create your own editor extension in a
custom plugin. This would be a way to test out your idea. If this is
something that is workable, then we can incorporate it directly into
Groovy-Eclipse.

More importantly, though, I'm not sure if overriding this method is
the best way to go. There is a method called setOutlinePageInput
declared in JavaEditor. Perhaps overriding this method will get you
what you need. I *think* what you need to do is call setInput on some
sort of mock IJavaElement that you create and where you populate the
getChildren method. (This is just an idea and I don't know if it will
work.)

Let me know if you are going to explore this further and we can discuss more.

Re: Outline view for Groovy DSL

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts
in the outline view, but it would also be nice to expose an extension
point so that third party plugins can provide their own
JavaOutlinePage input.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

Re: Outline view for Groovy DSL

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

RE: Outline view for Groovy DSL

I achieve to develop the extension point, and to test it for my Jspresso DSL :

I tried to take in mind your previous mail instructions … here is some answers :

1.The groovy editor checks all extenders… the first one that returns an outline page will win... by default (of course) the standard outline page is used.

2.The extender receives the IProject and the GroovyCompilationUnit.

3.I added some abstract IJavaElement sub classes… The outline extenders should only inherit this classes and add some methods :

a.OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree…

b.OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view…

c.OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels …(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)

4.Here is a first patch proposal… will you give me some feedback first or do you prefer that I attach it directly to the Jira ?

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

I achieve to develop the extension point, and to test it for my Jspresso DSL :

I tried to take in mind your previous mail instructions … here is some answers :

1.The groovy editor checks all extenders… the first one that returns an outline page will win... by default (of course) the standard outline page is used.

2.The extender receives the IProject and the GroovyCompilationUnit.

3.I added some abstract IJavaElement sub classes… The outline extenders should only inherit this classes and add some methods :

a.OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree…

b.OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view…

c.OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels …(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)

4.Here is a first patch proposal… will you give me some feedback first or do you prefer that I attach it directly to the Jira ?

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

I achieve to develop the extension point, and to test it for my Jspresso DSL :

I tried to take in mind your previous mail instructions … here is some answers :

1.The groovy editor checks all extenders… the first one that returns an outline page will win... by default (of course) the standard outline page is used.

2.The extender receives the IProject and the GroovyCompilationUnit.

3.I added some abstract IJavaElement sub classes… The outline extenders should only inherit this classes and add some methods :

a.OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree…

b.OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view…

c.OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels …(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)

4.Here is a first patch proposal… will you give me some feedback first or do you prefer that I attach it directly to the Jira ?

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

Re: Outline view for Groovy DSL

Thanks for this. Can you please attach your patch to the jira? Please create it as a single .patch file with a patch root as the workspace (doing it this way makes the patch directly apply-able through mylyn). I'll go have a look at it then.

I achieve to develop the extension point, and to test it for my Jspresso DSL :

I tried to take in mind your previous mail instructions … here is some answers :

1.The groovy editor checks all extenders… the first one that returns an outline page will win... by default (of course) the standard outline page is used.

2.The extender receives the IProject and the GroovyCompilationUnit.

3.I added some abstract IJavaElement sub classes… The outline extenders should only inherit this classes and add some methods :

a.OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree…

b.OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view…

c.OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels …
(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)

4.Here is a first patch proposal… will you give me some feedback first or do you prefer that I attach it directly to the Jira ?

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

Thanks for this. Can you please attach your patch to the jira? Please create it as a single .patch file with a patch root as the workspace (doing it this way makes the patch directly apply-able through mylyn). I'll go have a look at it then.

I achieve to develop the extension point, and to test it for my Jspresso DSL :

I tried to take in mind your previous mail instructions … here is some answers :

1.The groovy editor checks all extenders… the first one that returns an outline page will win... by default (of course) the standard outline page is used.

2.The extender receives the IProject and the GroovyCompilationUnit.

3.I added some abstract IJavaElement sub classes… The outline extenders should only inherit this classes and add some methods :

a.OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree…

b.OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view…

c.OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels …(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)

4.Here is a first patch proposal… will you give me some feedback first or do you prefer that I attach it directly to the Jira ?

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

Thanks for this. Can you please attach your patch to the jira? Please create it as a single .patch file with a patch root as the workspace (doing it this way makes the patch directly apply-able through mylyn). I'll go have a look at it then.

I achieve to develop the extension point, and to test it for my Jspresso DSL :

I tried to take in mind your previous mail instructions … here is some answers :

1.The groovy editor checks all extenders… the first one that returns an outline page will win... by default (of course) the standard outline page is used.

2.The extender receives the IProject and the GroovyCompilationUnit.

3.I added some abstract IJavaElement sub classes… The outline extenders should only inherit this classes and add some methods :

a.OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree…

b.OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view…

c.OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels …
(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)

4.Here is a first patch proposal… will you give me some feedback first or do you prefer that I attach it directly to the Jira ?

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.

Re: Outline view for Groovy DSL

- if there is no extenders then the outline contains the classical methods (main, etc.)

- if there is one extenders that should create an outline O1 then the created outline is an O1 instance.

- if there is two declared extenders, the first one wins.

2) test the outline content.

Let's say we have a test extender that produces an outline that contains a tree of OTypes that should be synchronized with groovy methods and inline methods. Each node contains also OMethod and OField sub nodes linked to the groovy...

Thanks for this. Can you please attach your patch to the jira? Please create it as a single .patch file with a patch root as the workspace (doing it this way makes the patch directly apply-able through mylyn). I'll go have a look at it then.

I achieve to develop the extension point, and to test it for my Jspresso DSL :

I tried to take in mind your previous mail instructions … here is some answers :

1.The groovy editor checks all extenders… the first one that returns an outline page will win... by default (of course) the standard outline page is used.

2.The extender receives the IProject and the GroovyCompilationUnit.

3.I added some abstract IJavaElement sub classes… The outline extenders should only inherit this classes and add some methods :

a.OCompilationUnit.refreshChildren : this method will allow the extender to build and refresh the IOJavaElement tree…

b.OCompilationUnit.getChildrenAt(int caretOffset) : this method is used to synchronize the Editor view with the outline view…

c.OMethod.getElementNameNode, OMethod.getReturnTypeName, OType.getElementNameNode : those methods will determine the outline lines labels …
(I have’nt yet implemented a OField classe because I did’nt need it for Jsoresso, but I will do it later)

4.Here is a first patch proposal… will you give me some feedback first or do you prefer that I attach it directly to the Jira ?

No, it's not too complicated and you can copy the code used for other extension points inside of Groovy-Eclipse (such as HighlightingExtenderRegistry), but there are some things that you would need to think about:

1. There may be multiple extenders, how will they interact? If you make sure that each extender registers for a particular file type (or some other reasonable thing), then there would be little chance that one extender would interfere with another.

2. The groovy editor will need to be able to efficiently determine which extension to use. This is related to the previous comment.

3. It would be nice if extenders wouldn't have to create their own subclass of ITypeRoot. I think that MockTypeRoot (or something more appropriately named) should be part of Groovy-Eclipse, but that it should expose callbacks that extenders should use to create children. Similarly, instead of requiring extenders to sub-class SourceMethod (or SourceField), Groovy-Eclipse should provide default implementations with similar callbacks.

4. It would be easiest to manage the code if you were to create a patch based off of what is currently in trunk and then attach it to the jira:

That's very cool. I'll take a look at this on Monday. Can you post your sample code to the jira issue I raised earlier?

There are some questions that I have and would need to discuss before moving ahead with this. But, if the patch is well coded and has some tests, then we can definitely incorporate this into the code-base.

At a minimum, Groovy-Eclipse should be able to augment Groovy scripts in the outline view, but it would also be nice to expose an extension point so that third party plugins can provide their own JavaOutlinePage input.