My poor little computer was at the receiving end of uncharacteristic cursing. This happens when my 'flow' is interrupted too often. Moving between domain classes, controllers and views is rather tedious in Eclipse. So yesterday I did something about it and created some navigation actions, and now I am back in my peaceful coding world.

The actions appear in the Navigation menu, as well as the popup menu in the Groovy editor:



The first action, 'Open Twin' toggles between domain classes and their related controller. The hot key make this very snappy.
The second action, 'Open Views' opens a dialog with a list of views related to the domain or controller class:




In a previous entry, I described how to enable the XML editor for GSPs. If need be I will add more actions to get from GSPs back to their related controller classes.

This is not part of the official GroovyEclipse plugin. I don't know where it fits it - it should be part of GrailsEclipse, but I don't know anything about it. I will have to ask James how that is coming along.

Until then, I created an update site at http://www.rippleinteractive.com/update from which to install the plugin. And if anyone wants to poke around, here is the source.
I'd be curious to know if it works in Windows, I didn't think too hard about path separators.

Have fun.

The Eclipse XML editor works nicely with GSPs. It's not a GSP editor, but it does a few nice things:

• Command+Shift+F formats
• Opening tag completion for html elements, and closing tag completion for any element including taglib elements
  
• Syntax highlighting
• Structure error markers
  

It doesn't however work out of the box. To get it working:

1. Window->Preferences
2. Search for 'Content Types'. In the list navigate to Text->XML
3. Add '*.gsp' to the file associations list

That's it - happy GSP editing. I wonder how difficult it would be to extend the XML editor to be Groovy/Grails aware?

The initial code completion support for GroovyEclipse is complete. As you may have inferred from the banners, this work was made possible by Jay Zimmerman of No Fluff Just Stuff.com - a big thank you to Jay for this short cut to code completion.

I am quite pleased with the result as the available completions exceed what was proposed. It was a case of do more now to do less later. Many classes can be reused in future GroovyEclipse features.

If you can't wait you try things out, the update site for the stable development version is at: http://dist.codehaus.org/groovy/distributions/updateDev/

The following code completions are available:

• complete a local variable
• complete a field
• complete a property
• complete a class name
• complete property expressions, i.e. after the '.'
• complete the default Groovy methods.
• complete category methods inside of 'use' blocks
• 'override method' code assist
• Completions for dynamic methods and properties via an extension point for adding type information - think completion for the very dynamic Grails.

And the best part - type inference! Duck typed variables, fields and return types of methods have their types inferred for simple expressions. Method parameter types are not inferred at this time. Types are inferred on the fly as needed. It would be nice to cache certain results, but this will only happen once GroovyEclipse has a model of the various classes, methods and fields.

The initial scope of the project was to have simple completions e.g. myObject.some_ where the underscore indicates the completion request. With a proper type evaluator more complex completions and inferences would be possible for free. So with a little more work, completions like myObject.doit()[0]._ are possible.

Does it work? As more and more completions were implemented, I started using Groovy to implement any new classes. How many Eclipse based IDEs can say they are implemented in their own language? Well, Java - any more? Proof that Groovy and Java play nicely together.

From now on Java will be used mostly when adding to existing Java code or when performance requires it. Groovy is just too good not to use, especially in the future - maintaining 'pseudo code' is far more fun.

How does this code affect the future?

• There is now a place to start adding inline help.
• Code navigation - many classes used in completion are reusable here. I also get to gleefully destroy the current code which I created during early morning hacking while too tired. I am looking forward to that.
• Hovers with inferred types.
• So much more ...

There are some things to be aware of:

• GroovyEclipse underwent some major changes. Some were to do with packaging - GroovyEclipse is no longer a monolith but a set of plug-ins. Others in core implementation - the building of Groovy source files was rewritten. This squashed many bugs, however there may be some new ones to squash.
• When things don't seem to work, pause a little before asking for a completion. The compiler is not yet incremental, so sometimes it has to catch up to your typing.
• Error recovery handles the case of a dangling '.'. Fix other errors so that a correct AST can be created and then continue coding.
• If you still see problems, please direct them to the eclipse-plugin-dev list on Codehaus.

Well, that's it - an announcement on the groovy user list is imminent. Install, dig in, read some GroovyEclipse docs in Eclipse help.

Info about the completions are available in previous posts:
http://www.rippleinteractive.com/blog/2007/03/07.html
http://www.rippleinteractive.com/blog/2007/03/20.html
http://www.rippleinteractive.com/blog/2007/04/04.html

Any feedback is very welcome at this stage to help polish things.