Javascript

Javascript Shell Server

Russ — Mon, 01 Aug 2005 21:26:00 GMT

So it finally happened... We have had our own version of the javascript shell brewing over here for quite a while. Our version has been growing more and more divergent from the Extension Developer version. Nathan mentioned that he had incorporated Emacs into the mix a while back. Today we I spent a few hours rewriting the autocomplete, so that it is much more readable, and hopefully, much easier to modify in the future. Our goal being to bring the results back to Emacs, thus giving us intelligent emacs autocomplete for javascript.

This is our shell packaged up as a standalone extension (that can be run along side of the extension developer if you wish). The xpi contains js-mode.el (thanks a bunch Helmut Eller) which needs to be installed in emacs. Check Nathan's post for more instructions.

Now that we have taken the initiative to separate our version of the shell, I foresee more improvements in the future. I plan on posting an actual page about the extension and how to get it properly installed in emacs and what not tomorrow.

IE bug in dynamically added select options

Russ — Wed, 27 Jul 2005 17:16:00 GMT

If you add options to a select dynamically via javascript, IE will not render this correctly until you have opened and closed the select menu a few time. To get around this you just need to remove the select from the DOM then add it back. Setting the innerHTML will not help things :( Unfortunatly, setting the innerHTML causes bugs in both major browsers.

Oh Spider Monkey why doest thou keep secrets from me

Russ — Thu, 21 Jul 2005 17:46:00 GMT

There are so many hidden things inside of the javascript implementations that it is a constant frustration. I happen to like javascript an awful lot, but damn this language/environment for being so fickle.

The magic functions/properties I found are listed below. They solve one of my biggest problems with the javascript getter/setter system that Nathan wrote about here, which is that by doing what Nathan was doing, we couldn't find a way to get a reference to the actual function doing the getting/setting. I really hate that these are totally hidden.

__proto__ : a reference to the current instances prototype (deprecated in Rhino)
__defineGetter__('propName', func) : creates a getter function with the name provided as the first argument
__defineSetter__('propName', func) : creates a Setter function with the name provided as the first argument
__lookupGetter__('propName') : gets a reference to the getter function of a given property (whose name is passed as an argument)
__lookupSetter__('propName') : gets a reference to the setter function of a given property (whose name is passed as an argument)

__parent__ seems to return the scope that something is defined in, but we cant really get this to do anything reliably and its also deprecated. Nathan seems to think that this is what a closure uses to keep track of its scope.

Writing HTML in Javascript

Russ — Fri, 08 Jul 2005 17:35:00 GMT

Lately Ive been writing alot of HTML as javascript using a function Ive named createNode in my Controls Library

example:

// The strings with curly braces are binding points with names matching the columns of my datasource
var cn = Controls.createNode;
var template = cn('tr', {}, 
               cn('td', {'class':"topCell", style:'width:75;'}, 
                  '{StoreNumber}'),
               cn('td', {'class':"topCell", style:'width:100;'}, 
                  '{Name}'),
               cn('td', {'class':"topCell", style:'width:100;' }, 
                  '{Metro}'),
               cn('td', {'class':"topCell", style:'width:250;'}, 
                  "{Address}",
                  cn('br'),
                  "{City}, {State} {Zip}"),
               cn('td', {'class':"topCell", style:'width:150;'}, 
                  cn('textarea', {'class':"displayBox", style:"width:100%;", readonly:"true"},
                     '{PublicPhoneNumbers}')),
               cn('td', {'class':"topCell", style:'width:100;'}, 
                  '{ConnectionType} - {Speed}'),
               cn('td', {'class':"topCell", style:'width:100;'}, 
                  '{UserName}'),
               cn('td', {'class':"topCell", style:'width:150;'}, 
                  '{DateEnteredHistory}'))

I was curious how this would square up against redering plain HTML. I had a feeling that it might be faster since parsing XML is incredibly slow and direct interaction with the DOM is something that JS should theoretically be good at. In my test I average the rendering time of a 10 column 100 row table over a few page refreshes.
The following were the result data:

firefox - Static	firefox - JS	IE - static	IE - dynamic
ave: 54.5ms	ave: 39.125ms	ave: 17.25ms	ave: 52.875ms

Of note, in this test, is the IE static HTML rendering times, which is much faster than any of the other results.

Object Keyed Hashtable in Javascript

Russ — Wed, 06 Jul 2005 19:50:00 GMT

In the last couple days I have had the need to put keys (that are objects) into a hashtable. Since the default js hashtable only allows string keys (see my last post on this topic), I decided to check the internet. Synovic is most highly rated by google, and pretty much every other refernce to javascript hashtable points to either his implementation or notes that {key:value} creates an object/array/hashtable in javascript. Because Synovic's hashtable is just a java like wrapper around the default hashtable, his suffers from the same built in flaw that the normal hashtable suffers. I seem to be the only one with the need to hash based off objects. One of the requirements I had was that I didnt want to modify the key (which would greatly simplify the problem). If I could just add a hashcode to every object passed in as a key this whole problem again becomes trivial. The only problem is that, since objects == hashtable in javascript, I could be accidently adding things to a collection that I dont want to be modified. Also it just seems like a horrible practice to have random functions adding properties to your objects. My solution was basically to create a hash code that I could use to identify objects. Then, using that hashcode, I look into an internal string-keyed hashtable. In that value slot, I store an array of {key: objectKey, value: valPassedIn} objects. Then it is linear look up to go through the array. If I can improve the Hashcode function I can improve the overall performance of my Hashtable object, but right now I havn't a clue how to do this. and now, the moment youve all been waiting for:

Hashtable Source

Javascript Hashtable

Russ — Tue, 05 Jul 2005 16:23:00 GMT

First, I recognize that an Array is an Object is an Hashtable in javascript. The problem is that only strings can act as a key in an Object. Meaning:

 var x = new Object()  
 var y = new Object()  
>> [object Object] 
 z = new Object()  
>> [object Object] 
 x[y] = 'test' ;
>> test
 x[z]  
>> test

Since alot of the objects in javascript return [Object] as their toString(), this means that I cannot key a hashtable off objects. I guess I'll get to work writing an actual Hashtable instead of just relying on the built in stuff. I will post this when I am done. For now, off to class.

UPDATE: The Exciting Conclusion

Changing the scope of "this" when using eval in javascript

Russ — Mon, 16 May 2005 17:55:00 GMT

I want every Item on the page to have an onload that gets called when the window.onload is fired. What I ended up doing is calling documnet.getElementsByAttribute('onload'). This is a function I wrote, but I will assume everyone can do a simple preorder tree traversal, so I will not go into it here. After getting a list of nodes with onload (in the correct order I want to execute them, I call the following code on each node:

function(){ eval( theStringIWishToEval ); }.call( objectIWantToBeThis ); // the node

This gives the correct scoping to the evaluated code (which is the current node whose "load event" I am reacting to).

XUL Repeater

Russ — Wed, 04 May 2005 16:24:00 GMT

I had talked about this repeater control a while back but then got distracted onto other things.
Go Here to see the Repeater Source
It probably can easily be ported to work with just javascript and HTML but I havnt had the time or need to do so yet. Who knows maybe soon. UPDATE: Fixed Link

The XBL Template / Repeater control

Russ — Sun, 10 Apr 2005 17:04:00 GMT

So I finally found a palatable solution to the Templates Problem I talked about earlier. The technique I used was to create a XBL control called 'repeater'. Ryan had some issues with the word template as I was using it so we switched over to repeater to be less ambiguous. The goal of this is not to provide a general control system (which XBL and XBLinJS try to do), but only to provide the functionality to easily repeat nodes inside of a valid tag. The best example I can give for this is for binding a dropdownlist / select box / menupopup, where I just need to repeat the <menuitem /> over a flat set of data.

var testTable = [['id', 'name'],
[ 1, 'Programmers' ],
[ 2, 'WebAdmin' ],
[ 3, 'Broadband']];

<hbox>
<repeater>
<label value="{name}" />
</repeater>
</hbox>

What the 'repeater' control does is remove the repeater node from its parent storing a reference to this 'template' on that control (so we have what was there but none of it is rendered). Then it loops through the data set adding all of the nodes that were inside of the repeater tags, with their values filled in. So what gets rendered to the page would be this:

<hbox>
<label value="Programmers" />
<label value="WebAdmin" />
<label value="Broadband" />
</hbox>

The really nice part about this system is that by inserting a repeater node inside of the template, with the outer template filling in the datasource attribute for the inner repeater as it goes, allows you to chain these repeaters to make hierarchical data repeaters. After I finish polishing everything and test it once more, I am going to port this to use <div repeater="true" > [enter repeated data here]</div> so that I can achieve the same repeater functionality in standard HTML.

Overall this has been my best experience with XBL, most notable because it required only one function block and one line of xbl content binding ( the <children /> node). It did however force me to copy code in and out of the xbl document to a standard JS doc to get parse errors to show up (Mozilla was just silently failing when their was a parse error in the XBL Javascript).

Ryan will probably give us a little preview of his js control scheme based of his interpretations of XBLinJS. What it seems we've got almost worked out is a simple way to repeat nodes and a simple way to create complex, repeatable, XUL/HTML controls. Most of this work was inspired by excessive frustration (mostly caused by nonexistant error handling) at the way mozilla handles these two things and by reading Jeremy Bowers site which convinced us to do what we already wanted to do.

UPDATE:
Go Here to see the Repeater Source
Usage Example

JS Shell Update

Russ — Fri, 08 Apr 2005 14:24:00 GMT

I finally got around to sorting the outputs of both the tab complete and the props function. That was a long time coming for .sort().

The XPI