JetGroovy 1.5 Obvservations

Hello Randall,

Hi,

Having recreated my module after JetGroovy 1.5
eradicated it in favor of an entirely new one, I'm
back to working. Already I've noticed some things
about which I'd like to give some feedback:

- Navigation Bar
-- This is nice, but it takes up more space than I'd
like it to. I'd like to see it shrunk (borders could
easily be reduced), possibly relocated outside the
text editing area (e.g., to the button bar) or made
optional or movable to the bottom of the text editing
area.

This is IDEA core feature that has been available since 6.0. If you don't like it, you can always hide it, though I personally find this functionality occasionally useful.

-- It would be nice to integate TagLibs into the
selector. While they aren't technically part of the
tuple <Domain, DomainController, DomainView,
DomainTest, DomainControllerTest>, when their name
fits the pattern, they could be included in the
tuple.

It;s not about the tuple, it's about one-to-one relation. I don't think taglib associate with these.

-- Likewise, it would be nice if Services were
accessible there.

Same concern.

- Inspections
-- Definite assignment check ("Variable 'something'
might not be assigned") is sometimes incorrectly
raised.

Is it in try/catch? Then this is because of due to the lack of checked exceptions we model control flow with two edges: one before the first try block instruction, and one after the last. Indeed since any statement in groovy may throw any exception, I don't see any other approximation that would be strict.

-- "Cannot apply default constructor for class
'DomainClass'": The Grails data-binding constructor
for domain classes should be known by this
inspection.

Yep, we have a request for integrating more domain classes PSI to jetgroovy. Though I personally don't like the approach to have a compiler inject additional methods/fields to domain classes...

- Iconography / Graphics
-- The asterisk in the editor tab overlaps the
padlock icon.

Thanks for pointing this out, we'll try to avoid this.

-- The extra border within the text area of Domain
classes that accommodates the tabs at the bottom (to
select Text or "domain class dependencies") causes
the JetGroovy Navigation Bar and its contents to
reposition slightly (but very noticeably). It's
border should adjust to the difference so its
contents do not appear to shift around when one moves
between Domain and non-Domain classes.


- General
-- As JetGroovy gets more complex, I think it is
going to be necessary to give users control over its
features. E.g.: Colors (comments are colored
differently, now); Navigation bar characteristics,
etc.

Colors are configurable in coors and fonts, groovy tab. Navigation bar is again not a part of jetgroovy. As well as code coverage that works with groovy files:)

- Irony
-- The access level check found a missing "public"
keyword in years-old Java code.

Sorry, we dont check for the age of your code in our inspections:)

Randall Schulz

Eugene.

Hi, Eugene,

Thanks for the details.

Regarding the Navigation Bar. Are we talking about the same thing? I'm talking about the bar that appears only when editing Groovy or GSP files that are part of a Grails application. I see it nowhere else and have never seen anything like it before.

I know the TagLibs are not one-to-one with any other file, but then again, neither are the Views. The point is that for the common cases (for me, anyway) when the TagLib is named for a particular Domain Class, it could be grouped with the rest of the files specific to that Domain Class.

The spurious "might not be assigned" diagnostic refers to local variables that are assigned at the outer-most level of the method (not closure) and are most definitely assigned. What's more, there are two such initializations immediately adjacent to each other, only one get the diagnostic. Reordering the initializations doesn't change which get the diagnostic and they're both used in very similar ways (they're arrays of String and the diagnostic occurs twice, both times is in a (for String str : strArray)):

 0) {
        fXRec.statusMesg = "Errors occurred while preparing to execute Tasks for Job \"${params.id}\""
        return fXRec
    }


    /* Execute the Jobs's Jobs */
    if (fNErrors == 0)
        for (String taskName : taskNames)
                               ^^^^^^^^^ Variable 'taskNames' might not be assigned
            fScript.executeTask(taskName)
]]>

There are a few try / finally pairs between the initialization and the use with the diagnostic. Here's the full listing:

 0 || fErrLog.nFatal() > 0) {
        fXRec.statusMesg = "CLIF resources for Job \"${params.id}\" contained errors"
        return fXRec
    }


    /* Compile the Jobs's Scripts */
    fScript = new TauScript(fCProc.collector(), this)

    try {
        fCompilingScripts = true
        for (String scriptName : scriptNames)
            fScript.compile(scriptName, fPathSep)
    }
    finally {
        fCompilingScripts = false
    }


    if (fNErrors > 0) {
        fXRec.statusMesg = "Errors occurred while compiling script(s) for Job \"${params.id}\""
        return fXRec
    }

    /* Preview the Jobs's Tasks */
    try {
        fPreviewing = true
        for (String taskName : taskNames)
                               ^^^^^^^^^ Variable 'taskNames' might not be assigned
            fScript.previewTask(taskName)
    }
    finally {
        fPreviewing = false;
    }


    if (fNErrors > 0) {
        fXRec.statusMesg = "Errors occurred while preparing to execute Tasks for Job \"${params.id}\""
        return fXRec
    }


    /* Execute the Jobs's Jobs */
    if (fNErrors == 0)
        for (String taskName : taskNames)
                               ^^^^^^^^^ Variable 'taskNames' might not be assigned
            fScript.executeTask(taskName)
]]>

The "Groovy" tab in the Colors & Fonts section of the IDE Settings had escaped my attention. Is it new in JetGroovy 1.5?

I shall refrain from entering a debate about Grails' philosophy and dynamic languages in general. But I (and JetBrains!) picked Groovy / Grails, and now I (we) have to work with it...


RRS

>> - Navigation Bar
>> -- This is nice, but it takes up more space than I'd like it to. I'd like to see it shrunk
>> (borders could easily be reduced), possibly relocated outside the text editing area
>> (e.g., to the button bar) or made optional or movable to the bottom of the text editing area.

This is IDEA core feature that has been available since 6.0. If you don't like it,
you can always hide it, though I personally find this functionality occasionally useful.

I used the wrong terminology. I did not mean the Navigation Bar that appears below the Toolbar, but rather the navigational controls that are specific to files that are part of Grails applications.

RRS

OK, I see. We had it in 1.0, but you probably did not see it if your domain classes et al. are not in the default package. In 1.5 I made it work in that case as well.

Actually, all my Groovy / Grails packages are and have always been in the default package (probably not a good idea, I agree).

The appearance of the Grails navigational controls (what do you call them?) coincided with the eradication of my old module in favor of a newly created Grails one. (I'm not going to let you forget that your code had this very onerous effect!)

So my observations about this Grails navigational panel (whatever it's called) remain, and I hope you'll address them.


Randall Schulz

Hi Randall,

Ufff, fixing those control flow bugs (the ones that resulted in "Might not be assigned") has been really tough, but these were indeed quite serious. Thank you!

Editor decorator (as we call it after Alex Tkachman) shrinked its vertical borders. Thank you!

Editor decorator (as we call it after Alex Tkachman) shrinked its vertical borders. Thank you!

Thank you!

RRS