debug=true and loading things in dojo.require

Quick question: are you running off a stream with Dojo 0.4 or off the new Dojo 0.9 codebase?

Quick question: are you running off a stream with Dojo 0.4 or off the new Dojo 0.9 codebase?

We are using 0.4.

Not having a lot of information, based on the symptoms you described, my *guess* is that somewhere during code loading, an exception is being thrown and swallowed. This could prevent some of your widgets from actually getting registered even though the require statements are correct.

My *first guess* is that there's a failure happening during widget definition, so I'd suggest doing the following: override dojo.widget.defineWidget and surround it with a try/catch block to catch the exception.

Somewhere high up in the code stack, like Workbench.js, do something like this:

dojo.widget.__oldDefineWidget = dojo.widget.defineWidget;
dojo.widget.defineWidget = function(widgetClass, renderer, superclasses, init, props){
try {
dojo.widget.__oldDefineWidget(widgetClass, renderer, superclasses, init, props);
} catch(e) {
alert(e.name + ": " + e.message + "\nFile: " +
e.fileName + " (Line: " + e.lineNumber +
")\n\n" + "Stack: " + "\n" + e.stack);
}
}

Note that only Firefox has nice exception properties; IE only has e.message and it's the same message you get in the IE trim.

If this doesn't work, then you'll have to do a brute force approach of inserting alert statements into the code that's failing and tracing back to where your alerts stop showing up.

Please let us know how this goes and what the problem is so that we can figure out how we can provide more feedback on these sorts of problems.

That did not help, but turns out there is an exception that gets lost. I cannot tell exactly where it happens, because it happens during an eval (and the FF debugger gets confused debugging eval statements), but the error is the following:
TypeError:setting a property that has only a getter

I wonder if this may be related to the Jazz web optimizer, because all our problems go away when we turn off webui.optimized. I believe debug=true stops optimization even if webui.optimized = true.

makbulut@us.ibm-dot-com.no-spam.invalid (makbulut) wrote in news:fc9fpc$pqa
$1@localhost.localdomain:

I wonder if this may be related to the Jazz web optimizer, because all
our problems go away when we turn off webui.optimized. I believe
debug=true stops optimization even if webui.optimized = true.

Hello, I do not have the answer but I just want to tell you we are really
interested in this issue.
So I will closely follow this thread and work with Bill.

The reason is that we do not have *yet :)* a great way to debug js issues
and we know thay may occur and will be really time consuming.

Don't despair, it may take us a while to figure ths one out, but I promise
you we really care and want to work with you so we can fix this problem,
and then learn the best practices so we can improve JS troubleshooting :)

Just my 2cents.. if you have recommendations, let us now :)

--
Christophe Elek
Serviceability Architect
IBM Software Group - Rational

Richard Backhouse <backhous@us.ibm.com> wrote in news:fcbf8g$l1f$1
@localhost.localdomain:

Christophe,

Just as an FYI. I have contacted Muhtar directly to work on getting his
issue resolved. I will post an update when we have figured out what is
going on.

Richard

Richard :) Great :)
Could you also let us know the proces you followed to troubleshoot, so we
can use the sam in support ? :) thx :)

--
Christophe Elek
Serviceability Architect
IBM Software Group - Rational

Christophe,

Just as an FYI. I have contacted Muhtar directly to work on getting his
issue resolved. I will post an update when we have figured out what is
going on.

Richard

Christophe Elek wrote:

makbulut@us.ibm-dot-com.no-spam.invalid (makbulut) wrote in news:fc9fpc$pqa
$1@localhost.localdomain:

I wonder if this may be related to the Jazz web optimizer, because all
our problems go away when we turn off webui.optimized. I believe
debug=true stops optimization even if webui.optimized = true.

Hello, I do not have the answer but I just want to tell you we are really
interested in this issue.
So I will closely follow this thread and work with Bill.

The reason is that we do not have *yet :)* a great way to debug js issues
and we know thay may occur and will be really time consuming.

Don't despair, it may take us a while to figure ths one out, but I promise
you we really care and want to work with you so we can fix this problem,
and then learn the best practices so we can improve JS troubleshooting :)

Just my 2cents.. if you have recommendations, let us now :)

Here is an update on what the issues were. It turns out that the code
was using two Dojo widgets that were badly written.

One module was written in such a way that it would not be able to be
built using the Dojo build system. The Jazz WebUI optimizer is using
part of the build system for dependency analysis.

The other module had invalid syntax. While it loaded ok when directly
referenced via script tags or loaded in with the main dojo.js module it
failed to load when interpreted via an eval statement. It seems that
eval has stricter syntax requirements.

As far as a process for troubleshooting. I think this one is a special
case as the issues were in fact with Dojo code itself. Certainly turning
on debug via the ?debug=true parameter is the first step.

Richard

Christophe Elek wrote:

Richard Backhouse <backhous@us.ibm.com> wrote in news:fcbf8g$l1f$1
@localhost.localdomain:

Christophe,

Just as an FYI. I have contacted Muhtar directly to work on getting his
issue resolved. I will post an update when we have figured out what is
going on.

Richard

Richard :) Great :)
Could you also let us know the proces you followed to troubleshoot, so we
can use the sam in support ? :) thx :)

Another trick I've adopted recently is that when I'm having bizarre problems, I run in debug mode and set Firebug to break on all errors (an option in the 'Script' view). This makes sure that even if code is swallowing an exception (a common cause of mysterious problems), you can still find it.

Just remember to turn off 'break on all exceptions' afterwards or you'll soon discover how many bugs are out on the web. :-)

If the code is in an eval() block, the code stops at a break point in that case, but you cannot see the matching source code. There is a note on this in Firebug, and it is a known issue. Because optimizer-related and "debug=false only" cases often end up in an eval block, debugging becomes challenging. Guessing the offset in actual source, and looking at the stack helps to guess what is running, but having the correct source and line would help. Do you know a way for that?