Details

    • Type: Sub-task Sub-task
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Sprint 8, 2.3.1.RELEASE
    • Component/s: None
    • Labels:
      None

      Description

      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)

        Activity

        Graeme Rocher made changes -
        Field Original Value New Value
        Fix Version/s Sprint 4 [ 10365 ]
        Fix Version/s 2.2.0.RELEASE [ 10332 ]
        Christian Dupuis made changes -
        Fix Version/s 2.2.0.RELEASE [ 10332 ]
        Fix Version/s Sprint 4 [ 10365 ]
        Fix Version/s 2.2.1.RELEASE [ 10441 ]
        Fix Version/s Sprint 5 [ 10440 ]
        Hide
        Andrew Eisenberg (c) added a comment -

        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
        Show
        Andrew Eisenberg (c) added a comment - 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: GSP-specific highlighting Groovy support inside scripts and expressions. This includes things like: syntax highlighting content assist formatting navigation hovers Content assist for GSP tags Content assist for JSP tags Ability to add custom tag libraries 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: GSP-specific highlighting (ie - highlighting for a fixed set of gsp and jsp) Basic content assist for these tags (ie- Hippie completion for tags and attributes, with no notion of which tags are appropriate in which locations). Does not barf on groovy code and maybe supplies simple syntax highlighting
        Andrew Eisenberg (c) made changes -
        Assignee Andrew Eisenberg [ aeisenberg ]
        Christian Dupuis made changes -
        Fix Version/s Sprint 6 [ 10442 ]
        Fix Version/s Sprint 5 [ 10440 ]
        Hide
        Graeme Rocher added a comment -

        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 = {
             [books:Book.list()]
        }
        

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

        Show
        Graeme Rocher added a comment - 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 = { [books:Book.list()] } The "books" key should appear in the list of completions.
        Hide
        Mike Miller added a comment -

        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.

        Show
        Mike Miller added a comment - 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.
        Hide
        Dmitry Brin added a comment -

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

        Show
        Dmitry Brin added a comment - Would it be possible to add an ability to step through GSPs in the debug mode and be able to place a break point?
        Hide
        Graeme Rocher added a comment -

        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

        Show
        Graeme Rocher added a comment - 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
        Hide
        Andrew Eisenberg (c) added a comment -

        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.

        Show
        Andrew Eisenberg (c) added a comment - 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.
        Andrew Eisenberg (c) made changes -
        Status To Do [ 10003 ] In Progress [ 3 ]
        Andrew Eisenberg (c) made changes -
        Priority Minor [ 9 ] Major [ 6 ]
        Hide
        Graeme Rocher added a comment -

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

        Show
        Graeme Rocher added a comment - Awesome! So does the Groovy reconciling allow completion? Does it work for both <% %> blocks and ${} expressions? Good job btw.
        Hide
        Christian Dupuis added a comment -

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

        Show
        Christian Dupuis added a comment - The first-cut of the GSP Editor will make it into today's STS 2.2.1. Stay tuned.
        Christian Dupuis made changes -
        Fix Version/s 2.2.1.RELEASE [ 10441 ]
        Hide
        Andrew Eisenberg (c) added a comment -

        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?
        Show
        Andrew Eisenberg (c) added a comment - 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: 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. Are there any inappropriate pieces of text in the wizard? What is the correct default location for GSPs?
        Hide
        Ryan Crumley added a comment -

        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.

        Show
        Ryan Crumley added a comment - 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.
        Hide
        Graeme Rocher added a comment -

        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

        Show
        Graeme Rocher added a comment - 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
        Christian Dupuis made changes -
        Fix Version/s 2.3.0.RELEASE [ 10484 ]
        Christian Dupuis made changes -
        Fix Version/s Sprint 7 [ 10482 ]
        Fix Version/s Sprint 6 [ 10442 ]
        Christian Dupuis made changes -
        Fix Version/s Sprint 7 [ 10482 ]
        Fix Version/s Sprint 8 [ 10483 ]
        Hide
        Andrew Eisenberg (c) added a comment -

        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.

        Show
        Andrew Eisenberg (c) added a comment - 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.
        Hide
        Andrew Eisenberg (c) added a comment -

        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.

        Show
        Andrew Eisenberg (c) added a comment - 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.
        Christian Dupuis made changes -
        Fix Version/s 2.3.1.RELEASE [ 10526 ]
        Fix Version/s Sprint 8 [ 10483 ]
        Fix Version/s 2.3.0.RELEASE [ 10484 ]
        Christian Dupuis made changes -
        Fix Version/s Sprint 8 [ 10483 ]
        Hide
        Andrew Eisenberg (c) added a comment -

        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.

        Show
        Andrew Eisenberg (c) added a comment - 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.
        Hide
        Andrew Eisenberg (c) added a comment -

        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.

        Show
        Andrew Eisenberg (c) added a comment - 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.
        Andrew Eisenberg (c) made changes -
        Ranking 330000000
        Original Estimate 0h [ 0 ]
        Remaining Estimate 0h [ 0 ]
        Andrew Eisenberg (c) made changes -
        Status In Progress [ 3 ] Done [ 10004 ]
        Resolution Fixed [ 8 ]
        Christian Dupuis made changes -
        Workflow dm Server Workflow [ 18941 ] jira [ 28746 ]
        Status Done [ 10004 ] Resolved [ 5 ]
        Trevor Marshall made changes -
        Workflow jira [ 28746 ] jira with Pivotal Tracker [ 66069 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        To Do To Do In Progress In Progress
        31d 15h 51m 1 Andrew Eisenberg (c) 08/Nov/09 8:58 PM
        In Progress In Progress Done Done
        72d 1h 41m 1 Andrew Eisenberg (c) 19/Jan/10 10:39 PM
        Done Done Resolved Resolved
        315d 13h 20m 1 Christian Dupuis 01/Dec/10 12:00 PM

          People

          • Assignee:
            Andrew Eisenberg (c)
            Reporter:
            Graeme Rocher
          • Votes:
            37 Vote for this issue
            Watchers:
            25 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: