Jeff's Blog

Quick note, I'm still plugging away at prepping my .sdf file for my domain series, but it's slow going. I should be back into that series by Monday 11/5, but in the mean time, more on this.

 

Here are there functions that are using the checkthis function we defined here as well as using this to reference some data. The results of the alert portion of these functions almost always gives me pause, and if it's been a few weeks since I last thought in JS, I probably would get them wrong. There are some parts that are not to odd, but 2 points usually catch me.

 

1. In xBthis this.myvar refers to the externally declared myvar. This is somewhat intuitive, it's just troubling, and potentially a gotcha, that you can have both myvars exist without conflicting, or overwriting values.
2. The non this –ed myvar in the x function, refers to the externally declared myvar as well. Again, it sort of makes sense, as I haven't explicitly scoped it, but it's just plain odd.

 

var myvar = '0023';

 

function xAthis(){
    var x = this.myvar;
    alert('x is: ' + x + ', myvar is: ' + myvar);
    checkthis(this);
}

 

function xBthis(){
    var myvar = '234';
    var x = this.myvar;
    alert('x is: ' + x + ', myvar is: ' + myvar);
    checkthis(this);
}

 

function xCthis()
{    
    var fn = function(){};
    fn.myvar = 'AADS';
    fn.foo = function(){ var x = this.myvar; alert('x is: ' + x + ', myvar is: ' + myvar); checkthis(this); };
    fn.foo();
}

 

The output from these calls are as follows (not including the checkthis output):

 

xAthis-- x is: 0023, myvar: 0023
xBthis-- x is: 0023, myvar: 234
xCthis-- x is: AADS, myvar: 0023

 

So what, right? Well, there are some times, when you can use the this your advantage. Consider this line from yesterday's script. This is a pretty common usage of this, the OnClick even of a button very often passes a this into a function to avoid storing variable references all over the place:

dv.ondblclick = new Function( "document.documentElement.removeChild(this);disposeObj(this);" );

In fact you can get creative, or really you can just start to treat JS much more like C#. Say you have a bunch of elements you need to "style" when a button is clicked, first you define a container to hold a the style definition

function styleObj(className, visible, top, left, zIndex){
this.ClassName == className;
this.Visible = visible;
this.Top = top;
this.Left = left;
this.Zindex = zIndex;
}

Create factory:

function styleFactory(obj){
if (obj.checkState){
return new styleObj("Foo", true, "10px", "50px", 1000);
}
else{
new styleObj("Foo", true, "80px", "50px", 1000);
}
}

Then you can write something like this:

<input type="checkbox" id="cbx" value="01"/>

<input type="button" id="cbxbtn" onclick="doStyle(styleFactory(this));" />

And run this script on load:

function init(){
for(var inp in document.getElementsByTagName("input")){
if (inp.type == "checkbox"){
document.getElementById(inp.id + "btn").checkState = inp;
}
}
}

Not particularly useful, but the idea is that you can use references, and objects just like you would in C#, it saves lookups, extra variables and other nonsense. Next time, I'm going to use this type of relationship chaining to show a way to manage some client side validation to support a WebMethod based UI…