JavaScript Constants (Cross-Browser)
www.gerardvignes.com
boot and shutdown scripts as hooks for the browser load and unload
events.
My JavaScripts interact with scripts running on the web server. I need
to declare shared values (as constants) to assist communication between
client and server. I declare these constants using global variables:
var CONSTANT_NAME = 'whatever';
I would prefer to avoid the global scope for a larger number of
constants. I am also aware that the "constant" value can be modified by
running code.
I toyed with the idea of creating resource objects that would dispense
shared values in response to invocation of a hardcoded method. This
should reasonably isolate the code from changes to the protocol between
client and server. It should avoid global namespace pollution and
changeable constants.
alert(resources.constantName); // prints "whatever" in a popup
I haven't attempted this approach yet on a realistic scale, so it may
have its own special complications.
Do you know of any practical, scalable alternatives to global variables
for shared constants that are cross-browser?
Thanks,
Gerard Vignes
http://www.GerardVignes.com
Seattle, WA
Duncan Booth
> I toyed with the idea of creating resource objects that would dispense
> shared values in response to invocation of a hardcoded method. This
> should reasonably isolate the code from changes to the protocol between
> client and server. It should avoid global namespace pollution and
> changeable constants.
>
> alert(resources.constantName); // prints "whatever" in a popup
>
> I haven't attempted this approach yet on a realistic scale, so it may
> have its own special complications.
>
> Do you know of any practical, scalable alternatives to global variables
> for shared constants that are cross-browser?
What you suggested above should work fine, except you just use an attribute
(as in your example) not a method (which you said in the text).
var resources = { CONSTANT_NAME: 'whatever' };
alert(resources.CONSTANT_NAME);
VK
www.gerardvignes.com wrote:
> I would prefer to avoid the global scope for a larger number of
> constants. I am also aware that the "constant" value can be modified by
> running code.
>
> I toyed with the idea of creating resource objects that would dispense
> shared values in response to invocation of a hardcoded method. This
> should reasonably isolate the code from changes to the protocol between
> client and server. It should avoid global namespace pollution and
> changeable constants.
IMO here is the case then closures and CCSM (with some modifications)
can be most useful. The rest depends on how robust you want to make
your protection from runtime modifications - bearing in mind that in
any case there are not absolutely secured programs and that any given
code can be reverse-engineered.
<html>
<head>
<title>Demo</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript" defer>
var glbConstantPool;
(function(){
if (typeof glbConstantPool == 'undefined') {
/* This is your constants you want to
* make read-only:
*/
var $CONST = {
'foo' : 1,
'bar' : 2
}
glbConstantPool = new Object;
glbConstantPool.item = function (key){
if (this instanceof arguments.callee) {
/* Someone is trying to use privileged method
* as constructor: new glbConstantPool.item();
* In the constructor context one cannot return
* primitive values, such return statement will
* be ignored - so no use to return undefined or null.
* Either return new reference to the method:
* return arguments.callee;
* or false wrapped into Boolean object:
* return new Boolean;
* As a historical note: this is the first
* ever practical use of Boolean constructor
* in JavaScript - and it was found by your
* humble servant :-)
*/
return new Boolean;
}
/* There can be boolean constants so the
* "durty casting" over if($CONST[key])
* is dangerous.
*/
if (typeof $CONST[key] != 'undefined') {
return $CONST[key];
}
else {
return 'undefined';
}
};
/* Protecting the privileged method from source dumping
* in string context. In the current sample nothing useful
* one can see anyway from the glbConstantPool.item code,
* but it is not always the case.
*/
var $bogus = 'return "function item() {'.concat(
'\\n [native code]\\n', '}', '";');
glbConstantPool.item.toString =
new Function(''+$bogus);
glbConstantPool.item.valueOf =
new Function('return "";');
/* On Gecko platforms (and wherever watch method is supported)
* additionally protect our privileged method from restoring
* the native toString and valueOf methods for it.
* Alas JScript doesn't support watch/unwatch for object
* properties.
*/
if (typeof glbConstantPool.item.watch == 'function') {
glbConstantPool.item.watch('toString',
new Function('return arguments[1]'));
glbConstantPool.item.watch('valueOf',
new Function('return arguments[1]'));
}
}
else {
throw new Error('glbConstantsPool identifier not free');
// or window.alert, or nothing or whatever by your choice
}
})();
window.alert(glbConstantPool.item);
window.alert(new glbConstantPool.item);
window.alert(glbConstantPool.item('foo'));
window.alert(glbConstantPool.item('bar'));
</script>
</head>
<body>
<h1>Demo</h1>
</body>
</html>
www.gerardvignes.com
A resource object would need to use hardcoded methods. If not, then it
is a more complex "solution" that fails to solve the original problem.
I am going to embed constants inside existing objects (chosen carefully
to maintain cohesion) and expose their values through hardcoded methods
on the containing objects.
This avoids the problems of (1) changeable constants and (2)
unnecessary global scope without introducing special, global resource
objects.