Is it possible to debug into the Javascript code?

[atomatom]

One of my biggest issues using SmartGWT is that I can't understand what is going on in SmartClient. I certainly appreciate the SC Console as a useful tool that helps.

But is it possible to debug/trace into the Javascript layers? How does Isomorphic debug SmartGWT bugs - do you do it in pure Javascript or is there a way to do it with GWT running as well?

I would really like to be able to do this so that I can understand the framework better - I very much appreciate that many bugs are simply me using the system in a way that it was not intended/tested. Sometimes this is a valid bug, sometimes it is abuse.

[Isomorphic]

When you see a JavaScript error, you can usually look at the stack trace *in IE* and see what's wrong or have a clue about what's wrong, such as a null parameter to a method where null clearly should not be passed.

Outside of that, we wouldn't recommend tracing through framework code whether it was Java or JavaScript. You're just going to be overwhelmed by details you don't need to know, or worse, come to rely on behaviors that aren't actually documented. This is just an ineffective approach relative to other methods, in all but the very rarest of cases.

But if you just want to play with it, most JavaScript debug tools (Firebug, IE's built-in Developer Tools) just work in the same way they work without GWT. You can "Stop on Error" and intentionally cause an error to try it out.

[atomatom]

Thanks for the pointers.

I am aware that the underlying SmartClient code is a bit like a compiler with the components defined in xml files (see below).

I guess my question could be posed this way: what do you recommend as best-practice for debugging - what do you guys use? Is SC Console pretty much the one-and-only tool? I guess the art is knowing how to use that tool is which loggers to turn on - this can be pretty difficult for anyone who does not have a good grasp on how the components interact.

I guess for the most part, user errors will be data problems. For all other issues, we should try and produce a test-case and ask for help?


ie, Label.ds.xml

<DataSource	ID="Label"	inheritsFrom="Button" Constructor="Label">
	<fields>
        <field name="contents" type="HTMLString" basic="true"/>	
		<field name="dynamicContents" type="boolean" defaultValue="false"/>
		<field name="align" type="alignEnum" basic="true"/>	
		<field name="valign" type="valignEnum" basic="true"/>
        <field name="autoFit" type="boolean" basic="true"/>
		<field name="padding" type="positiveInteger" />	
		<field name="wrap" type="boolean" basic="true"/>

        <field name="title" inapplicable="true"/>
        <field name="peers" inapplicable="true"/>
		<field name="children" inapplicable="true"/>	
    </fields>
    <groups>
        <group>basics</group>
        <group>contents</group>
        <group>sizing</group>
        <group>appearance</group>
    </groups>
    
    <methods>
        <method name="click" basic="true"/>
    </methods>
</DataSource>

[Isomorphic]

No, the underlying SmartClient code is nothing like a compiler and is not based on XML component definitions - if you want to learn about SmartClient, it has it's own QuickStart Guide, docs, etc.

There's no such thing as a "how to debug" guide - it's a skill, not a procedure. This is true for any product. You need to understand the layers of your application and be able to use tools such as the Developer Console or GWT breakpoints to look at state at various points.

The purpose of preparing a test case isn't solely or even primarily to ask for help. It's problem isolation, a standard debugging technique, and a very effective one when code-test cycles are fast as with GWT.

This is partly why we don't recommend stepping through framework code (again, Java or JavaScript). A lot of developers have a bad habit of immediately firing up the debugger and stepping through code they only half understand hoping to trip across some kind of clue. You can easily spend half a day on this and get nowhere, whereas simplifying your use case by commenting out some code and reloading will often lead straight to the solution.

[atomatom]

I very much agree with the test-case approach - I did not intend that to be a criticism against that approach. Reduction often leads to the obvious.

Most of the time, breakpoints work well to figure out what is going on - albeit you often need to extract the state from SmartGWT objects into Java objects to see what is going on.

I was not really asking for a how-to guide, rather I was curious what processes people use. Thanks for the feedback.

[Isomorphic]

You shouldn't have to "extract the state" into Java to see what's going on. On util.SC note all the "echo" methods - these are convenient for showing, eg, all the current properties of a component.

If you know just a little JavaScript, you can do runtime inspection from the Eval area in the Results Tab of the Developer Console (try eg just evaluating componentId as an expression).