Saltstorm :: ESC :: Caveats and known problems

ESC 1.14

ESC
	Introduction
	Requirements
	The inner workings
	Compression-levels
	Variable substitution
	Commandline options
	Examples of usage
	Caveats/Known problems
	Release history
	License
	Download

Caveats and known problems

First off I'd like to say, never put effort in trying to debug a script that has undergone treatment by ESC unless you are pretty damn sure there is a problem related to ESC itself and you feel determined to track it down. Instead, the first thing you should point your attention at is your original code. ESC rely on syntaxically perfect input to score. Sloppy written code will suffer hard.

However, there are a few situations mentioned here below that you should be aware of that current version of ESC will choke on. Running ESC in -v[erbose] mode helps you to further understand how to track down problems related/similar to the issues mentioned below.

Semi-colons, semi-colons. (Level 3)

A starter groundrule that will save you alot of headache when trying to crunch at level 3 or higher is;

!!! ALWAYS TERMINATE YOUR STATEMENTS WITH A SEMI-COLON ';' !!!

Think 'crunching-sessions'. (Level 4)

ESC's variable substitution scheme is 'session-unique', meaning a script's variables and methods may NOT be given identical substititution-names at different processings. So if you have two scripts that interacts is some way (i.e. shares variables) every BOTH should be crunched at the same session EVEN if you have only have made minor changes in one of them.

Dirty DOM shortcuts in MSIE. (Level 4)

In MSIE you easily get away with using dirty DOM shortcuts. ESC's substitution engine doesn't like that stuff and will produce a result that'll occationally break your application. This problem is MSIE specific, other browser won't allow such sloppy DOM referencing. Consider the following example, merge to the *Correct* way of element referencing if you intend to bring your piece into the dungeons of ESC (and standards). Need to say no more;

// Sloppy
elementId.style.visibility = 'hidden';
// Correct (MSIE only)
window.elementId.style.visibility = 'hidden';
// Correct (DOM style)
document.getElementById('elementId').
style.visibility = 'hidden';
... becomes after processing ...
// Sloppy
$xx.style.visibility = 'hidden';
// Correct (MSIE only)
window.elementId.style.visibility = 'hidden';
// Correct (DOM style)
document.getElementById('elementId').
style.visibility = 'hidden';

Beware of the 'with' statement. (Level 4)

There is currently problems related to ESC's substitution engine and the use of statement 'with' in your script that you should be aware of. The problem simplified is that ESC always treats a word that have atleast one whitespace character to its left as an object and tries to match it against the built-in maps. If no match was found, the word will be substituted. (Also apply to the use of object creation with { ... }, see below.) Consider the following snippet:

with(this.style){
visibility = 'hidden';
}
... becomes after processing ...
with(this.style){
$xx = 'hidden';
};

This substitution will break functionality in a way that can be very hard to track down in a large script. However, there are two ways around this:

Simply don't use statement 'with'. (it is inefficient executionwise anyway.)
Add property visibility to 'bless.map' to explicitly instruct ESC *NOT* to subject them for substitution. If the file 'bless.map' isn't present, create one in the same directory as ESC.wsf itself.

Creating and populating objects with { ... }

This is a troublesome thing to overcome, since the way ESC sees it, anything declared inside a set of braces are considerd top-level members unless prefaced with a 'var' keyword. Consider the following:

var oMyObject = {
euler : Math.E,
property : String("a property")
};
alert(oMyObject.euler);
.. renders ...
var $xx = {
$xy : Math.E,
$xz : String("a property")
};
alert($xx.euler);

As you might recognize, the alert will throwup 'undefined' since there is no property 'euler' declared, nor exposed by object $xx after ESC's been around. The 'euler' and 'property' declarations has been substituted since it *wrongly* appeared logical to do so. Furthermore you might think; why didn't 'Math' and 'String' end up the same way. Well, since ESC is ECMAScript-aware, these were recognized as *blessed*. For ESC this means something like; whatever I do, never, never mess with a word that appears to look like an intrinsic object, native object, keyword, statement or anything else that have been marked as *blessed*. (i.e. via 'bless.map') Workarounds to prevent this from happening when creating an object in this manner :

Bless them... Add property 'property' and 'euler' to bless.map to explicitly instruct ESC *NOT* to subject them for substitution. If the file 'bless.map' isn't present, create one in the same directory as ESC.wsf itself.
Separate the object-declaration and its population. ( var myObj = {}; myObj.euler = Math.E; ... )

SiteSearch
Search Site By