As a user, I want to have Grails tooling support in STS (STS-487)

[STS-550] Implement an editor for GSP, Grails' default view technology Created: 08/Oct/09  Updated: 01/Dec/10  Resolved: 19/Jan/10

Status: Resolved
Project: Spring Tool Suite
Component/s: None
Affects Version/s: None
Fix Version/s: Sprint 8, 2.3.1.RELEASE

Type: Sub-task Priority: Major
Reporter: Graeme Rocher Assignee: Andrew Eisenberg (c)
Resolution: Fixed Votes: 37
Labels: None

First Response Date:


A GSP editor should be able to (in order of priority):

  • Support Groovy code inside scriptlets/expressions
  • Complete GSP tags
  • Complete JSP tags (since they are supported inside GSP)

Comment by Andrew Eisenberg (c) [ 03/Nov/09 ]

This feature request is possibly the most complex of all grails feature requests, but it is also one of the most popular. And so it is worth sizing to see how long this would take to finish and if there are any reasonable milestones along the way that can produce useful results.

I should be able to use the StructuredTextEditor (which is what JSP support uses). This will provide simple highlighting and formatting appropriate for generic xml files.

The real JSP/GSP support comes in with the SourceViewer and the SourceViewerConfiguration, which, in the case of JSP, provides all the language specific tags and Java-based formatting and content assist.

The main question (which I do not have a feel for yet), is in order to implement GSP support, how much JSP functionality can be borrowed and how much needs to be recreated from scratch?

With that in mind, here is a more specific list of features:

  1. GSP-specific highlighting
  2. Groovy support inside scripts and expressions. This includes things like:
    1. syntax highlighting
    2. content assist
    3. formatting
    4. navigation
    5. hovers
  3. Content assist for GSP tags
  4. Content assist for JSP tags
  5. Ability to add custom tag libraries
  6. Validation of both xml and groovy

Is there anything I missed?

Given that current support for GSPs is 0, I think it is reasonable to implement a basic GSP editor that has something like the following minimal feature set:

  1. GSP-specific highlighting (ie - highlighting for a fixed set of gsp and jsp)
  2. Basic content assist for these tags (ie- Hippie completion for tags and attributes, with no notion of which tags are appropriate in which locations).
  3. Does not barf on groovy code and maybe supplies simple syntax highlighting
Comment by Graeme Rocher [ 04/Nov/09 ]

I think a first milestone that provides the above mentioned 3 features would be a great first milestone. We can then look at pulling in more features as time goes by.

Another feature to add is that completions should be aware of the returned model. Like if a controller returns a model:

def index = {

The "books" key should appear in the list of completions.

Comment by Mike Miller [ 04/Nov/09 ]

I think I created an entry in the wrong spot in JIRA but being able to click Ctrl+G to trigger Grails from inside the GSP editor would be nice.
Also, some common editor functions like Shift-right and Shift-left for source code - in both GSP as well as .groovy files.

Comment by Dmitry Brin [ 04/Nov/09 ]

Would it be possible to add an ability to step through GSPs in the debug mode and be able to place a break point?

Comment by Graeme Rocher [ 04/Nov/09 ]

Since GSPs compile down to Java byte code and since we track GSP line number mappings in the compiler process this should be possible. Probably non-trivial though

Comment by Andrew Eisenberg (c) [ 08/Nov/09 ]

Basic GSP Editor is committed. Currently, this is mostly a copy of JSP functionality, including formatting and content assist, but instead we plug in groovy syntax highlighting and groovy reconciling.

Comment by Graeme Rocher [ 09/Nov/09 ]

Awesome! So does the Groovy reconciling allow completion? Does it work for both <% %> blocks and ${} expressions? Good job btw.

Comment by Christian Dupuis [ 09/Nov/09 ]

The first-cut of the GSP Editor will make it into today's STS 2.2.1. Stay tuned.

Comment by Andrew Eisenberg (c) [ 09/Nov/09 ]

Awesome! So does the Groovy reconciling allow completion? Does it work for both <% %> blocks and ${} expressions? Good job btw.

JSP-like completion is available only. So, completion proposals will contain getters and setters, rather instead of the properties. Also, completion inside ${} is not supported. As I said, this is a start.

I would like to hear feedback (at this point mostly on the new GSP wizard). For example:

  1. The new GSP wizard contains a set of templates adapted from the new JSP wizard. I am certain that these are not appropriate for GSPs, but I don't know what should take its place.
  2. Are there any inappropriate pieces of text in the wizard?
  3. What is the correct default location for GSPs?
Comment by Ryan Crumley [ 09/Nov/09 ]

I am looking forward to trying out the editor. Having syntax highlighting and better html completion is great even if its not fully understanding of syntax.

If I had a choice I would strongly prefer better code completion and debugging support on the view side in plain groovy than in the gsp's. If you can debug the view and know what is in the model then you can determine what the gsp will render.

Comment by Graeme Rocher [ 10/Nov/09 ]

Hi Andrew,

1. Yeah the templates don't need the <%@ page %> directive at the top, otherwise they're ok
2. Nope looks ok
3. Default location should be grails-app/views but I would say you should make this more intelligent since you have conventions. So for example if you have "TestController" open then the location should be grails-app/views/test and so on

It would be nice to get rid of the "Unknown tag" warnings all over the place when Grails' default tags are found too

Comment by Andrew Eisenberg (c) [ 09/Dec/09 ]

I have support for the very basic tags (eg- if, each, etc). So, now they will not appear as unknown and they will appear in content assist.

Comment by Andrew Eisenberg (c) [ 09/Dec/09 ]

Content assist inside $


is now groovy-aware with full inferencing, etc happening.

This feature and the previous are now available in the latest nightly build of grails tooling.

Comment by Andrew Eisenberg (c) [ 31/Dec/09 ]

Content assist outside of $


tags now has all default, builtin, plugin, and user-defined tags. I do some parsing of the tag body to look for supported attributes, but this is far from complete. The builtin tags (eg- if, else, while...) are fully documented and required attributes are automatically added.

This is not committed yet, but it is working locally. I'll probably commit sometime in early January. At that point, once we are sure that everything is working, I'll close this issue since the editor is mostly feature complete.

However, there is a big piece that is not yet implemented. Once a gsp editor is opened, the tags that it knows about are fixed. So, even if tag libs are changed, plugins added, etc, this will not be reflected in the editor.

Comment by Andrew Eisenberg (c) [ 19/Jan/10 ]

Done. I have now implemented a per-project cache of tag libs that are shared between open gsp editors. This cache is refreshed whenever there is a relevant change to the project's taglibs.

This is committed and regression tests are included. I am now closing this bug since the gsp editor is feature complete. However, there are still areas that need some work, such as making content assist for grails tags have more complete information.

Generated at Sat Mar 25 09:36:15 UTC 2017 using JIRA 6.1.4#6159-sha1:44eaedef2e4a625c6c7183698b2468d4719c20dc.