SuperDevMode with SmartGWT

[atomatom]

I appreciate that SuperDevMode is pretty raw/new, but from my perspective, this represents a huge leap in making SmartGWT easier to use/debug/understand as we can now trace into the SmartClient code from Java/GWT code inside the browser.

( Read more about SuperDevMode here: https://developers.google.com/web-to...s/superdevmode and how to set it up here: http://stackoverflow.com/questions/1...78009#13278009 )

So here is how I got it to work with SmartGWT

Since SuperDevMode does not allow script includes in the modules, I added the SmartClient javascript files in the HTML file and used the SmartGWTNoScript module. That made GWT compile happily.

However, when I go to run SuperDevMode the compile button fails (it will show Compiling MODULE... for ever) because of this javascript exception (in MODULE.nocache.js file)

 
    function computePropValue(propName){
      var value = [b]providers[propName]()[/b], allowedValuesMap = values[propName];

where the propName value is "Class" - which I believe is one of the core SmartClient globals. since there is no providers function, this blows up.

The good news is if I wrap computePropValue with a try/catch (in javascript) it appears to work. So far, I have done this just by manually modifying code in the Chrome Script window (then CTRL+S), ie I change

    result[key] = computePropValue(key);

to

    try { result[key] = computePropValue(key); } catch (e) {  };

Would be interested to hear of a less manual/hacky patch for this. The other option is to modify the GWT linker files (I think XSTemplate.js ).

[atomatom]

Link to the issue in GWT http://code.google.com/p/google-web-...ummary%20Stars

[sjivan]

I got it to work with some hackery too. The issue you discovered is already reported as a GWT bug, along with a simpler workaround.

http://code.google.com/p/google-web-...detail?id=7513

Please vote for it. As a workaround I added an ant target as part of my IntelliJ post-build step that fixes the bug with the GWT generated nocache.js file.

    <target name="fix-gwt-nocache">
        <replaceregexp file="${basedir}/out/artifacts/myapp.war/myapp/myapp.nocache.js"
                       match=".*result\[key\] = computePropValue\(key\);.*"
                       replace ="if \(values.hasOwnProperty\(key\)\) \{result\[key\] = computePropValue\(key\);\}"
                       byline="true"/>
    </target>

The other issue that you might have noticed is that because of the SmartGWT default z-Index, the super mode compile dialog is obscured as it uses a lower zIndex of 1000.

I worked around that by temporarily lowering the default SmartGWT zIndex values and then add bookmarklets for the SuperMode enable / compile operations.

    //in entry point class lower the default zIndex values to make the SuperDevMode panel visible
     setZIndex(100, 50, 200);

    public static native void setZIndex(int nextZIndex, int smallZIndex, int bigZIndex) /*-{
        $wnd.isc.Canvas.addClassProperties({
            // default zIndex for the next item to be drawn
            _nextZIndex:nextZIndex,

            // zIndex of the next item to be sent to the back
            _SMALL_Z_INDEX:smallZIndex,

            // zIndex of the next item to be brought to the front
            _BIG_Z_INDEX:bigZIndex
        });
    }-*/;

[Isomorphic]

Thanks for putting together these instructions.

Note that SmartGWT does not require the use of the "Class" global. You can put the system into portal mode by just setting a JS variable before the SmartClient runtime loads.

[sjivan]

This is just one of several other properties that it trips over. Array prototype errors follow which I recollect is not circumvented by portal mode.

[atomatom]

I was going to say the same thing as Sanjiv about it hitting other globals. It is pretty bad code in GWT.

Thanks for the zindex fix and ant script. I have been trying to see how you could inject that patch at runtime but I don't think it is possible because it uses values in a closure. Patching the GWT source code looks like the only elegant fix so far.

[atomatom]

I patched the GWT SDK and recompiled it. It fixes both issues. (I changed the zIndex to 1,000,000)

Be aware that this code is not just these changes, but all changes to date in the GWT code repo (so, you may get new bugs and fixes as well)

http://goo.gl/zyKfR

[sjivan]

It would be useful to create a GWT issue about the zIndex setting in the SuperDev panel and submit your patch.

[atomatom]

Done. Give it a vote. I'd hope these are easily merged as they are trivial changes.

http://code.google.com/p/google-web-...detail?id=7864

http://code.google.com/p/google-web-...detail?id=7863

[atomatom]

Just an update: I submitted both of these fixes earlier this year and they are now rolled into GWT 2.5.1 (released yesterday: http://googlewebtoolkit.blogspot.ca/...l-is-here.html )

You will likely find that developing with superdev mode is *way* faster with SmartGWT in particular, given the large amount of pure javascript code.

[sjivan]

Thanks for submitting the patches. I verified that both thses issues are resolved with 2.5.1 and SuperDev Mode works smoothly with SmartGWT and is great for debugging purposes.

I still haven't fully transitioned to SuperDevMode only - I am running the server with the properties below that are required for SuperDevMode, but and I'm running both, DevMode and SuperDevMode. Dev mode refresh is running at an acceptable performance since my current application isn't extremely large, but having SuperDevMode running alongside is super helpful trying to debug or troubleshoot calls from JS into my GWT Java code where I want to examine the call stack. I'm hoping to try to switch entirely to SuperDevMode if the experience working with it is good.

    <add-linker name="xsiframe"/>
    <set-configuration-property name="devModeRedirectEnabled" value="true"/>
    <set-property name="compiler.useSourceMaps" value="true"/>