The Uize.Util.Debug module provides a Uize.Util.Debug.summary static method that returns a summary for instances of Uize.Class subclasses, and for Uize.Class subclasses.

Using this method, you can conveniently display summary info for instances of Uize.Class subclasses as well as Uize.Class subclasses using the alert statement.

EXAMPLE 1

alert (Uize.Util.Debug.summary (page.children.slider));

In the above example, if the page widget has a slider child widget that is an instance of the class Uize.Widgets.Slider.Widget, then the output of the alert statement could look something like...

EXAMPLE OUTPUT

[object Uize.Widgets.Slider.Widget]

built : true
busy : inherit
busyInherited : false
children : [object Object]
container : undefined
decimalPlacesToDisplay : undefined
displayedStyleHeight : 400
displayedStyleWidth :
emptyColor : undefined
enabled : inherit
enabledInherited : true
extraClasses :
fullColor : #999
html : [package Uize.Widgets.Slider.Html]
idPrefix : page_slider
idPrefixConstruction : concatenated
inDrag : false
increments : 1
insertionMode : undefined
localized : undefined
maxValidValue : undefined
maxValue : 200
minValidValue : undefined
minValue : 0
name : slider
nodeMap : undefined
orientation : vertical
parent : [object UizeSite.Page.Example]
restTime : 250
scaleFunc : [object Function]
size : large
trackLength : 400
v2RootNodeCssClasses : Uize_Widgets_Slider_Css Uize_Widgets_Slider_Css-vertical Uize_Widgets_Slider_Css-large
value : 50
valueFunc : [object Function]
wired : true

EXAMPLE 2

alert (Uize.Util.Debug.summary (page.children.slider.Class));

In the above example, if the page widget has a slider child widget that is an instance of the class Uize.Widgets.Slider.Widget, then the output of the alert statement could look something like...

EXAMPLE OUTPUT

[object Uize.Widgets.Slider.Widget]

built : true
busy : inherit
busyInherited : false
children : [object Object]
container : undefined
decimalPlacesToDisplay : undefined
displayedStyleHeight : 400
displayedStyleWidth :
emptyColor : undefined
enabled : inherit
enabledInherited : true
extraClasses :
fullColor : #999
html : [package Uize.Widgets.Slider.Html]
idPrefix : page_slider
idPrefixConstruction : concatenated
inDrag : false
increments : 1
insertionMode : undefined
localized : undefined
maxValidValue : undefined
maxValue : 200
minValidValue : undefined
minValue : 0
name : slider
nodeMap : undefined
orientation : vertical
parent : [object UizeSite.Page.Example]
restTime : 250
scaleFunc : [object Function]
size : large
trackLength : 400
v2RootNodeCssClasses : Uize_Widgets_Slider_Css Uize_Widgets_Slider_Css-vertical Uize_Widgets_Slider_Css-large
value : 50
valueFunc : [object Function]
wired : true

The Uize.Class base class implements a valueOf Intrinsic Method that returns the value of the value state property for instances of Uize.Class subclasses.

Because this method is implemented in the Uize.Class base class, all Uize.Class subclasses get to inherit it. For any class that implements a value state property, the value of an instance can be displayed in an alert dialog using a convenient shorthand. This can be done by prepending a "+" (plus sign) to the instance reference for classes that implement a number type value, or by appending a + '' to the instance reference for classes that implement a string type value.

EXAMPLE 1

alert (+page.children.slider);

EXAMPLE 2

alert (page.children.imageWipe + '');

Firebug provides a powerful DOM inspector that not only lets you traverse the document's node hierarchy, but also lets you inspect user-defined properties and functions.

By using the DOM inspector, you can traverse the JavaScript widget tree for a page that uses the UIZE JavaScript Framework. On a typical page you will have a page widget at the root of the widget hierarchy. Finding this in the DOM inspector, you can expand it and inspect its properties. In order to dig deeper into the widget tree, you can locate the children property of the page widget and expand it too. For each child widget of the page widget you can do the same. You can keep sleuthing like this, digging as deep as you need to, to ultimately find the "widget of interest" that is a suspect in the code crime you are investigating.

At any stage in this process, you can inspect the values of state properties for a widget instance. Note that the state properties will be represented using their private names (i.e. prefixed with an underscore).

When using the DOM inspector in Firebug to peruse the widget tree, any property that is an instance of a Uize.Class subclass will have the module name for its class displayed to the right of the property.

EXAMPLE

page                  Uize.Widget.Page instanceId=uizeGuid1 _children=Object

This can be particularly useful when inspecting the children property of a widget to peruse its child widgets. In this case, the widget class for each child widget will be displayed to the right of the child widget name, as in...

EXAMPLE

imageWipe             Uize.Widget.ImageWipe ...
paramsInspector       UizeSite.ParamsInspector ...
performWipe           Uize.Widget.Button ...

Just as with alerting summary info for instances or classes, summary info for instances of Uize.Class subclasses as well as Uize.Class subclasses can be conveniently logged to the Firebug console using Firebug's console.log method.

EXAMPLE 1

console.log (Uize.Util.Debug.summary (page.children.slider));

EXAMPLE 2

console.log (Uize.Util.Debug.summary (page.children.slider.Class));

In both cases, the output that is logged to the Firebug console will look pretty much the same as what you would see in an alert dialog (see alerting summary info for instances or classes).

Just as with alerting values of instances or classes, values for instances of Uize.Class subclasses as well as Uize.Class subclasses can be conveniently logged to the Firebug console using Firebug's console.log method.

EXAMPLE 1

console.log (+page.children.slider);

EXAMPLE 2

console.log (page.children.imageWipe + '');

Missing semicolons at the end of statements can lead to JavaScript syntax errors when JavaScript code is scrunched and consecutive lines that used to be separated by linebreaks are compacted together.

JavaScript interpreters are quite forgiving regarding missing semicolons at the end of statements, and use linebreaks as hints to resolve situations where there might be ambiguity. This forgiving nature can lead to missing semicolons creeping in and not being detected while developing with source code. However, when the code is scrunched and linebreaks are stripped, two lines where a linebreak was serving as a statement terminator suddenly get tacked together to produce something that is syntactically incorrect.

SOURCE CODE - IT WORKS

var _blah = 5

function _myFunction () {}

SCRUNCHED CODE - IT FAILS!!!

var _a=5function _b(){}

A particularly common place to miss a semicolon is when assigning an anonymous function declaration to a prototype property, as in...

INCORRECT

MyObject.prototype.myMethod1 = function () {
  // ... ... ...
  // ... ... ...
  // ... ... ...
  // ... ... ...
  // ... ... ...
}

MyObject.prototype.myMethod2 = function () {
  // ... ... ...
  // ... ... ...
  // ... ... ...
  // ... ... ...
  // ... ... ...
};

The semicolon omitted after the first assignment will cause the two assignments to run together when the code is scrunched, causing a JavaScript error. This problem can be easy to miss for a few reasons...

Accessing a private identifier as though it were a public identifier will work in source code but will almost certainly not work when the code is scrunched.

When application code or some other module of code (such as a different class, or even a subclass) accesses a private identifier, such as a private property or method, then the code will most likely break when it is scrunched. This is because modules are scrunched independently, and so the same private identifier name is very unlikely to be mapped to the same scrunched name across multiple different modules of code. One can consider this a kind of serendipitous slap on the wrist delivered by the Scruncher, because code shouldn't be inappropriately looking at other code's privates - let alone touching them.

The kinds of inappropriate accessing that one may encounter when troubleshooting scrunch-related failures include...

5.2.1. Accessing a Superclass' State Properties

Accidentally assigning globals can have interesting interactions with the scrunching process.

Scrunch-related side-effects of accidentally assigned globals are discussed in more detail in the section accidental globals.

It can sometimes - yet rarely - happen that source code of a subclass may conflict with source code of a superclass, if the same private identifier name is used in each, but for different purposes.

To avoid collisions in private identifier names between a superclass and a subclass when code is scrunched, scrunched identifier prefixes are registered with both the superclass and the subclass that are unique to each. This has the interesting potential side effect that a superclass-subclass collision in a private identifier name could surface only in source code but be guaranteed to never occur with scrunched code, since the names will be the same in the source code but different from one another in the scrunched code.

Fortunately, a problem that occurs in source code is more likely to be detected earlier, because development will be done using source / unscrunched code. However, when writing an implementation for a subclass, you may nevertheless want to crack open the source code for the superclass that you are subclassing - just to be certain. This is pretty typical, anyway, since it is useful to understand the implementation of a superclass when implementing a subclass of it.

The Scruncher does not enter string literals. This means that any code contained inside string literals will not be scrunched.

A HYPOTHETICAL SCENARIO

For performance reasons, you might want to dynamically build a function that will get executed repeatedly, rather than repeatedly performing the same conditional steps. By building a function, you can capture how the code that you need to repeatedly execute is conditionalized based upon some state that remains the same throughout the entire iteration. Now, let's say you wanted your dynamically built function to call private functions or methods. If you use the private identifiers when constructing your function's body, your function will work with source code but will fail with scrunched code.

So, if you're putting code into string literals - either to be evaluated using JavaScript's built-in eval function, or to be built into a function using JavaScript's Function object - you will either need to make public the identifiers that need to be accessed from the code inside string literals, or you will need to use a trick to "pipe" the scrunched name into the dynamically constructed JavaScript code.

The following example is not a good, real world example, but it does illustrate the point quite clearly...

SOURCE CODE - IT WORKS

function _myFunction () {
  var _myVariable = 'Hello there';
  eval ('alert (_myVariable)');
}

SCRUNCHED CODE - IT FAILS!!!

function _a(){var _b='Hello there';eval('alert (_myVariable)');}

To fix the problem, you could do one of the following...

5.5.1. Avoid Privates

function _myFunction () {
  var myVariable = 'Hello there';
  eval ('alert (myVariable)');
}

function _a(){var myVariable='Hello there';eval('alert (myVariable)');}

5.5.2. Pipe the Privates Through

function _myFunction () {
  var _myVariable = 'Hello there';
  for (var _myVariablePrivateName in {_myVariable:1});
  eval ('alert (' + _myVariablePrivateName + ')');
}

function _a(){var _b='Hello there';for(var _c in{_b:1});eval('alert ('+_c+')');}

The kinds of problem situations that can arise as a result of accidental global include...

6.1.1. Collisions Between Different Instances of a Closure

6.1.2. Collisions Between Disparate Code

6.1.3. Collisions With Page Code

The most obvious way to assign an accidental global is to simply forget the var keyword in front of a plain old variable declaration / assignment.

However, more insidious traps are waiting to ensnare you.

6.2.1. Incorrect Semicolon in Compound var Statement

var
  myVariable1 = 1,
  myVariable2 = 2,
  myVariable3 = 3;
  myVariable4 = 4,
  myVariable5 = 5
;

6.2.2. Missing var statement in Loops

for (_elementNo = -1; ++_elementNo < _elements.length;) {
  // ...
  // ...
}

for (_key in _object) {
  // ...
  // ...
}

Accidental globals can be spotted by keeping an eye on the DOM in a debugging tool such as Firebug.

6.3.1. Thorough Interaction

6.3.2. Using Firebug

It can be hard to fix an accidental global, because there's no easy way to know where its assignment is originating from.

Unless it's obvious from the name of the variable, one may have to do a global search (how ironic!) through the JavaScript code. The process of tracing the origin of an accidental global assignment can be complicated for variables with generic names that are used in multiple places, such as _result, _object, _key, _property, _params, etc.

Having to hunt down the source of accidental globals can be avoided, of course, if you keep a watchful eye on the DOM as you develop code. That way, you'll notice the accidental globals sooner after they creep in and will have a better idea of what recent code changes may have introduced them.