Debugging changes

[Michael Turyn <MT...@nexaweb.com>]

Debugging has been changed to fit in with the new startup.  

 

Background: to be visible under Venkman, the Mozilla debugging
interface, JS objects have to be loaded using <script/> tags, rather
than the fetch/eval mechanism we've adopted from Dojo (for good
reasons); our debugging mechanism accomplishes this by going from a
class name to a file path, and writing the appropriate script tag.
(Dojo can do this too, supposedly, but making it work seemed impossible;
also, it can only do all-or-nothing debugging, and I think
class-by-class granularity will be useful.)

Most of the changes are refactoring:  Bob Buffone has removed the
debugging machinery from Xap and put it into a new xap.util.Debug class,
which I've adapted for ease-of-use.  In order to run debugging, you must
add  a "debug_config" object to the JS global scope _before_ loading
xapcore.js.  You may either specify a list of classes
    <script language="JavaScript"> 
        // Debug chosen classes 
        debug_config = {
            _debugList:[
                "xap.widgets.dojo.ListBox",
                "xap.bridges.xap.XapComboBoxBridge",

                "xap.bridges.xap.ListBoxBridge",
                "xap.bridges.dojo.DojoWidgetBridge"    
                          ]     } ;
    </script>
...or prep all classes for debugger-friendly loading:

    <script language="JavaScript"> 
        // Debug all classes loaded
        debug_config = {_debugAll: true} ;
    </script>

Then, after xapcopre.js is loaded but before the end of the <head/>
portion of html, you'll need to add the actual load command:

    <script language="JavaScript">
      <!-- must do this before we load the actual application: -->

      xap.util.Debug.loadDebuggables() ;
  </script> 

Early on in developing a new feature or debugging an old one, "debugAll"
probably makes sense.  When you've just got a few classes that will need
changing, specifying them makes more sense since that's closer to the
deployment version.

Added bonus:  because the individual files will be loaded after
xapcore.js, their code overwrite its code.  This has three useful
consequences:

        1.) The code the debugger will show for them loads much faster
than the whole xapcore.js, 

        2.) The code will not be compactified, so it will have much more
meaningful variable names (except, prehaps, for some of my code)

and

        3.) If you're developing a class that will be debug-loaded, you
can test the new code by rerunning your test page after just copying
over that class file---no need to go through the entire build process.
(Under Windows, xcopy /s/D under is useful for this.)

Caveat:  If you make a file available via the debugging mechanism, you
should test your code without debugging before you check it in.  Why?:
a subsequent developer might want to turn debugging off, at which point
you could get exceptions when it turns out that other files that should
load the file with Xap.require() are missing that declaration.

(You can also include a _sourceRootDir member in debug_config; if you
don't, it will default to "../../src", which works for our examples.
The mechanism for adding the <script/> tag is in the Debug class itself,
decoupling it from the equivalent mechanism in Utils, for which the
"src" was implied.)