I just noticed the other day that his latest post gives some props to my Emulating CSS word-wrap for Mozilla/Firefox blog post, but his version adds some much needed cross-browser support for browsers I neglected.

Nice One, HedgerWow!

So I was monkeying around, and I decided to write a function to determine if a string were a palindrome. This is not a very difficult problem, but it might make for a descent introductory interview question (one of those questions you'd ask to rule out the truly inept).

With problems like this, I'm mostly interested in two things:

1. Writing the function in a clever way, so as to achieve the least amount of code possible
2. Writing the function in the most efficient way possible

Now, if it were Ruby, writing the clever solution (which might also happen to be the most efficient solution in that language -- not sure) would be ridiculously easy:

That's so trivial, it's probably not even worth writing.

But Javascript doesn't have a .reverse() method on strings, so you have to take an extra step (still pretty easy though):

Split the string into an array, reverse the array, and then join it back together. Since this is all native Javascript stuff, it turns out to be reasonably fast, though one might expect you could do better.

For grins and giggles, I decided to see how a manual solution, where I compare characters starting at each end of the string and work towards the middle, would compare:

This function will probably fail quickly, so that's good, but it also turns out to be generally faster than the split/reverse/join version. It makes sense, since you're going through the string only one time and twice as fast as normal since you're traversing from both ends at the same time.

Can you do even better though? Maybe. At least in Firefox you can, and quick tests seemed to confirm across other browsers too (but I didn't test extensively).

What if we split the string in half, and only reverse half of it. Then we can compare the first half with the original half:

The idea here is just split the string in half, reverse one of the two pieces and compare them. For example:

TOOT: splits into "TO" and "OT." Reverse one of them, say the second part ("OT") and compare.

If you've got a odd number of characters, you can ignore the middle most character:

RACECAR: splits into "RAC" and "CAR" (ignore the "E" in the middle). Reverse the second part ("CAR") and compare.

As it turned out, this seemed to be faster than the other two methods. Not by orders of magnitude, but not insignificantly either. Here are the number from Firefox, running each function 10,000 time on the string "gohangasalamiimalasagnahog" (go hang a salami, i'm a lasagna hog).

• (Traverse from both ends): 797ms
• (Split/Reverse/Join): 969ms
• (Compare halves): 640ms

Of course, numbers varied slightly during each run, but overall the they were consistent relative to each other.

So there ya go. Nothing in particular I wanted to point out here; just found it interesting and thought you might too.

Think my code sucks? Got a better solution? Say so in the comments (you won't hurt my feelings).

Anyway, since the current beta release of Gimme is "Caspian" I figured I'd do a post today in honor of Gimme and the movie (ok, it helps that I also have something worth writing about too).

So anyway, on to what this post is really about: enhancing Gimme.

Not too long ago, Shaun Inman wrote about his proposal for CSS Qualified Selectors.

It's a good idea; I've actually had the same idea and thought briefly about making it part of Gimme's core CSS selector engine. Only, in my model, I have the left-hand-side and the right-hand-side of the < symbol switched. It feels more natural to me that way, because in most CSS selector rules, you can simply look to the far right of the selector rule and know what type of "thing" you're going to be selecting.

Thus, I feel that this:

feels more natural than this:

But this is just details; the idea is the same either way.

So anyway, after Shaun published his idea, John Resig chimed in and mentioned that jQuery supports this already via pseudo :has(..).

Well that's pretty cool, but since Gimme is my library, naturally, I feel compelled to make sure it stacks up against the competition, so I thought to myself: "self, can Gimme do this?" to which a mental reply came back "No, remember? You decided no to implement it."

And I would have just left it at that, because after all, I decided not to implement it for a reason (and I figured that's where I would leave it).

But then, today, my officemate surprised me by asking "Hey, I have a question about Gimme. I'm working with a page where I need to select a <table> element that has an <h1>. Can Gimme do this?"

Well crap! What are the odds that this would come up again so quickly?

Not being one to disappoint, I said "You know what? I decided not to implement it, but I did put significant effort into making Gimme's selector engine extensible. I bet we can write an extension really easily."

So a few minutes later, we came up with this little gem:

Which means you can now use Gimme to do something like:

Unlike what John did, I didn't bother to map this back to the < symbol. I thought about it, and you could do it easily enough, but the more I think about it, the more I like how :has(..) reads.

It's not likely that I'll make something like this part of the core Gimme library unless it start popping up everywhere. It comes up occasionally, but not enough to warrant making it part of the core (at least, not enough in my personal experiences so far anyway).

So there ya go! Think of this as edition 1 of "Gimme can do that too" with (hopefully) many more editions to come.

Comments welcome.

The major problem here is that there is only one mechanism available for accessing a CSSStyleSheetDeclaration object and its corresponding CSSRule collection.

And that (rather unfortunate) mechanism is by zero-based index, which means you need to know exactly where in the DOM a particular stylesheet lives and exactly where in said stylesheet the particular rule you're interested in lives.

Needless to say, accessing these sheets and rules by index is risky, since any update to your CSS may require an update to the code which accesses your CSSRule by index.

You might be thinking that one solution is to put the rule (or rules) that interest you in a predictable place (e.g. the very first rule of the very first stylesheet in your page), but even this is risky and error prone (I know; I did it, and it once came back to bite me).

In light of these issues, I wrote a function that, given a CSS selector rule, finds the the corresponding CSSRule (if it exists). Since this is not necessarily a cheap process, the results are cached so that future requests for the same rule are returned in constant time.

The full code is offered below, with explanations of anything interested embedded in comments.

The findCSSRule(..) function

Caveats:

This function isn't perfect by any means -- a few things need to be called out.

1. Specifying media type could be more flexible: I'm just doing a simple indexOf(..) check on the stylesheet's media attribute, which means that if you want to filter by more than one media type, you'll need to specify the comma separated list yourself, and you'll need to make sure you do it in the right order if you want the indexOf(..) check to pass. A more robust solution might be to parse a comma separated string of media types for the user, or to allow the user to specify multiple media types in an array.
2. Memory consumption could be an issue: I don't think it's likely, but if you're grabbing lots and lots of rules, the cache could become large and memory leaks could become an issue (since the cache is created in a closure). I'm not overly concerned about this though -- you can decide for yourself is this is a big deal.
3. No mechanism for handling dynamically created styles: If you happen to load a stylesheet later in page's lifetime (after the initial load) this function is still going to return the unsupported() function, since it does its check once, up front, to decide whether or not accessing stylesheets/rules is feasible. I'm okay with this, but again, you can decide for yourself.

Examples:

Now that the function is written, a few examples are in order. Assume the following stylesheets:

- stylesheet 0 - (media = "print")

div>span
{
   border: 10px solid red;
}

.christmas
{
   background: green;
   color: red;
}

.pascha
{
   background: purple;
   color: yellow;
}

- stylesheet 1 - (media = "screen")

div>span
{
   border: 5px dotted blue;
}

#main div~span
{
   background: pink;
}

Accessing any of the above styles is fairly trivial.

// returns the div>span rule from stylesheet 0
var r1 = findCSSRule('div>span', 'print');
   
// also returns the div>span rule from stylesheet 0 (since media default to empty string, the first stylesheet with this rule will match)
var r2 = findCSSRule('div>span');
   
// returns the div>span rule from stylesheet 1
var r3 = findCSSRule('div>span', 'scren');
   
// returns the .pascha rule from stylesheet 0
var r4 = findCSSRule('.pascha');
   
// returns null
var r5 = findCSSRule('.halloween');
   
// returns the #main div~span rule from stylesheet 1
var r6 = findCSSRule('#main div~span');
   
// returns null (b/c the rule doesn't exist in a stylesheet with media = "print"
var r7 = findCSSRule('#main div~span', 'print');

And there you have it!

Comments, questions, suggestions, complaints? Bring 'em on!

]]> http://blog.stchur.com/2008/04/09/programmatically-accessing-the-css-rules-in-your-pages-stylesheets/feed/ 2 http://blog.stchur.com/2008/01/24/accessing-the-native-domelements-prototype-in-safari-2/ http://blog.stchur.com/2008/01/24/accessing-the-native-domelements-prototype-in-safari-2/#comments Thu, 24 Jan 2008 20:17:00 +0000 sstchur http://blog.stchur.com/2008/01/24/accessing-the-native-domelements-prototype-in-safari-2/ UPDATE:

It turns out, Safari has an interesting quirk. Simply executing this Javascript:

document.getElementsByTagName('html')[0];

is enough to make the "[[DOMElement.prototype]]" property come into existence. This appears to be true regardless of how early in the page load cycle you execute the Javascript, so perhaps the whole polling script I suggest below is unnecessary after all.

For the longest time, I thought it was just completely impossible to access the prototype of the native DOMElement (or HTMLElement in most other browsers) in Safari 2.

As an alternative, I'd see people extend the Object object's prototype in order to add functionality to DOM elements (heck, I've done this myself -- shame on me). This is problematic for a couple of reasons:

1. Programmers expect var myObj = {} to be an empty object (i.e. it should have no properties). Extending Object's prototype breaks this.
2. Iterating an object's properties via for .. in now requires the use of .hasOwnProperty(..) to ensure you're not accessing properties you don't intend to access.

I searched high and low, and I experimented (numerous times) trying to find some way of accessing the native DOMElement in Safari 2, but always to no avail... until now.

It's worth noting that this is not an issue in Safari 3. Extending DOM elements in that browser is easy:
HTMLElement.prototype.foo = function()
{
   alert('foo');
};
// assume elem is a reference to some valid DOM element
elem.foo();       // alerts "foo"

At long last, a solution for Safari 2

Credit totally goes to my co-worker, Derrick Quan, as he is the one who discovered the initial solution.

It turns out there there is a property on the window object in Safari 2 which is identified by the string "[[DOMElement.prototype]]" (case sensitive and double brackets on both sides required).

Now you can't access this directly because [[DOMElement.prototype]] is not a valid variable name. It doesn't have to be though, since it lives as a property of some other object (the window object in this case).

This means that we can access "[[DOMElement.prototype]]" by treating it like what it is (a property on the window object).

var DOMElemProto = window['[[DOMElement.prototype]]'];
DOMElemProto.foo = function()
{
   alert('foo');
};
// assume elem is a reference to a valid DOM element
elem.foo();          // alerts "foo"

There is "gotcha" however (maybe not -- see the UPDATE note at the beginning of this post).

It seems that the [[DOMElement.prototype]] property is not available until the DOM is fully loaded, which means if you want to be confident in accessing the property, you'll need to do it, either in a window "load" listener, or by using a DOMContentLoaded-type script (see Hedger Wang's post: An alternative for DOMContentLoaded on Internet Explorer and/or Stuart Langridge's: DOMContentLoaded for IE, Safari, everything, without document.write).

Alternatively, you could poll for the existence of the [[DOMElement.prototype]] property, and take action once it finally "comes alive."

function getDOMElemProto(_retries)
{
   this.retries = this.retries || _retries;
   if ((this.count = (this.count || 0) + 1) > _retries)
   {
      // abort
      return;
   }

   var DOMElemProto = window['[[DOMElement.prototype]]'];
   if (typeof DOMElemProto === 'undefined')
   {
      setTimeout(getDOMElemProto, 100);
   }
   else
   {
      extendDOMElements(DOMElemProto);
   }
}

function extendDOMElements(_proto)
{
   // Extend the DOMElement.prototype as necessary here
   _proto.foo = function()
   {
      alert('foo');
   };

   _proto.bar = function()
   {
      alert('bar');
   }
}
getDOMProto(50);

After a few retries, Safari2 should be able to access [[DOMElement.prototype]], while other browsers will give up after 50 tries.

Now I haven't done extensive testing on this, but initial tests seem to indicate that this works quite well. And it doesn't resort to extending the Object object's prototype at all, so users of this script should not have to worry about object literals containing unexpected properties.

I think this is pretty cool.

Comments, questions, suggestions, complaints... all welcome.

]]> http://blog.stchur.com/2008/01/24/accessing-the-native-domelements-prototype-in-safari-2/feed/ 0 http://blog.stchur.com/2007/11/21/setcapture-with-gimme/ http://blog.stchur.com/2007/11/21/setcapture-with-gimme/#comments Thu, 22 Nov 2007 04:44:01 +0000 sstchur http://stchur.com/blog2/2007/11/21/setcapture-with-gimme/ In my last blog post I talked about how to re-route events in Javascript. It comes in handy from time to time, but some people prefer an alternate paradigm -- one that is probably more familiar to Win32 programmers.

It's called setCapture. It's proprietary, and it's native to only the IE browser (as far as I know).

What's .setCapture() good for?

Put simply, .setCapture() redirects all mouse events to a specified DOM element until a call to .releaseCapture() is made. Why would you want this? I can think of a couple scenarios.

1. Drag n' Drop: you wire up mousedown to some element to start the drag operation, but wiring up mousemove and mouseup on that same element could be problematic -- the user may mouse too fast and your code might not be able to "keep up." Using .setCapture() on said element however, will redirect all mouse events to the appropriate element so that the mousemove and mouseup handlers are guaranteed to execute.
2. Dropdown Menus: you want the next mousedown to dismiss a dropdown menu. A first crack at this might be to wire up mousedown to the <body> element, but if some other element on the page is listening for mousedown and is stopping event propagation, the mousedown may never make it to the <body> element -- .setCapture() will solve this problem.

These aren't the only applications of .setCapture() of course, but they're two of the most common and they're a good illustration of how .setCapture() can be useful.

Gimme's version of .setCapture(..)

Even though Mozilla/Firefox and other W3C browsers don't natively support .setCapture(), Gimme solves this problem by simulating the capability for browsers that don't natively support it. Using Gimme's version is a snap.

// just a shortcut for document.getElementById(..)
var dragElem = Gimme.id('dragElem');

// #dragElem will capture all mouse events until
// a call to Gimme.Events.releaseMouse() is made
Gimme.Events.captureMouse(dragElem);

A simple call to Gimme.Events.captureMouse(myElem) will do the trick (where myElem is the DOM element that should capture all mouse events).

This example, of course, doesn't accomplish anything very useful, but here's an example that's a bit more practical.

This snippet gives drag/drop capabilities to all elements marked with the class "draggable" (it looks long but that's just comments and a big font).

g('.draggable').iterate(makeDraggable);
function makeDraggable(idx)
{
   // variables to keep track of the drag element's start position
   // and the initial mousedown position
   var elemStartPos, mouseStartPos;

   // wire up mousedown to start the drag operation
   // and stop click events from propagating (just in case)
   this
   .addEvent('mousedown', mouseDown)
   .addEvent('click', stopEvent);

   function mouseDown(e)
   {
      // instruct all mouse events to be redirected to the current dragElem
      Gimme.Events.captureMouse(this);

      // prevent the mousedown event from propagating
      e.stopPropagation();

      // create a gimme object from the element being moused down on
      var gObj = g(this);

      // keep a ref to the dragElem's start position
      // and to the initial mousedown position
      elemStartPos = gObj.getPagePosition();
      mouseStartPos = Gimme.Screen.getMousePosition(e);

      // now, hook the mousemove and mouseup events
      gObj
      .addEvent('mousemove', mouseMove)
      .addEvent('mouseup', mouseUp);
   }

   function mouseMove(e)
   {
      // prevent the mousemove event from propagating
      e.stopPropagation();

      // get the current mouse position
      var mousePos = Gimme.Screen.getMousePosition(e);

      // position the dragElem (element's start position + mouse delta)
      g(this)
      .setStyle('top', elemStartPos.y + (mousePos.y - mouseStartPos.y) + 'px')
      .setStyle('left', elemStartPos.x + (mousePos.x - mouseStartPos.x) + 'px');
   }

   function mouseUp(e)
   {
      // instruct Gimme to stop capturing mouse events
      Gimme.Events.releaseMouse();

      // prevent the mouseup event from propagating
      e.stopPropagation();

      // remove the mousemove and mouseup handlers
      g(this)
      .removeEvent('mousemove', mouseMove)
      .removeEvent('mouseup', mouseUp);
   }

   function stopEvent(e)
   {
      e.stopPropagation();
      e.preventDefault();
   }
}

Before I get into an explanation of the code, the following note is significant:

The current version of Gimme (Belisar) doesn't offer Gimme.Events.captureMouse(..). This capability is new to Gimme (Caspian) which is currently in a pre-release state. You can access Caspian now by visiting the Source Code Section on the Gimme Codeplex site, or you can wait for the official release of Caspian, which should be sometime in late January.

Explanation

If you understand Gimme, the code here is really pretty straight-forward.

A mousedown event starts the drag operation by recording the mouse down position and the element's start position. Then, the mouseMove handler ensures that the element moves along with the mouse delta (delta from the mouse start position). Finally, the mouseUp handler ends the drag operation by removing event handlers that are no longer needed and releasing capture.

We prevent events from propagating (bubbling) in all cases, so that we don't get other elements interfering during a drag operation. And we use Gimme's Gimme.Events.captureMouse(..) capabilities to ensure the the mousemove and mouseup events are directed to the appropriate element. Otherwise we risk some other element "stealing" the mousemove or mouseup away from the intended element.

What does this refer to exactly?

Good question; it's the one thing in the Gimme drag/drop code that I can see tripping people up. The this keyword is somewhat polymorphic in Gimme, so what does it refer to exactly?

The answer is that is depends on context. Most of the time in Gimme, you'll be using this inside of an event handler function. In that case, this refers to the DOM element to which the event was wired up. For example:

g('#myElem').addEvent('click', function(e)
{
   // alerts "myElem"
   // since 'this' refers to #myElem in the current context
   alert(this.id);
});

In some cases though, you may want to use the Gimme .iterate(..) function. In that case, this refers to the current Gimme Object being iterated over, not a DOM element, but it's possible to combine both concepts. For instance:

g('#container > .funny').iterate(function(idx)
{
   // here, 'this' refers to the current Gimme Object,
   // which is why .addEvent(..) is okay here
   this.addEvent('click', function(e)
   {
      // here, 'this' refers to the DOM element receiving the click event,
      // so we can access native properties, like .parentNode
      this.parentNode.removeChild(this);
   });
});

In case you hadn't figured it out, the above snippet makes it so that all elements with the class "funny" that are direct children of #container will be removed from the DOM when clicked -- pretty trivial with Gimme.

But this is all secondary to the discussion at hand: capturing mouse events, which, thanks to Gimme, is also pretty trivial!

If you're new to Gimme, check out the Gimme Promo Page and the Gimme Codeplex Page.

You can also download a debug version of Caspian here if you just want to monkey around with it.

Note once again, that an official (and compressed) version of Caspian will be available sometime in late January.

Comments welcome.

]]> http://blog.stchur.com/2007/11/21/setcapture-with-gimme/feed/ 0 http://blog.stchur.com/2007/06/22/introducing-gimme/ http://blog.stchur.com/2007/06/22/introducing-gimme/#comments Fri, 22 Jun 2007 17:08:16 +0000 sstchur http://stchur.com/blog2/2007/06/22/introducing-gimme/ It's been quite a while since I've blogged anything significant regarding Javascript. This is largely due to the fact that I've been spending a good bit of my free time working on an open source project I started, called Gimme.

Gimme is a Javascript Library designed to make performing common tasks, not only easier, but down-right trivial.

What does Gimme look like?

Gimme is remarkably easy to use and was purposely designed to be very readable. Take the following snippet.

g('.moveable').addClass('hasBeenMoved').slideToPoint({x: 0, y: 0});
 

This code snippet grabs all elements on the page that have the class "moveable", adds to them, the class "hasBeenMoved," and then slides the elements (in a nice accelerated fashion) to the point (0, 0) on the page. Pretty easy right?

Believe it not, most tasks in Gimme are this easy (or easier).

Get started with Gimme

• See it in action on the Gimme Demo Page
• Learn what it can do at the Gimme API Reference Page.
• Download the source on the Gimme Releases Page.

Your Feedback

Gimme is still very young, but I'd love to get your feedback. Please don't hesitate to try it out and let me know what you think.

]]> http://blog.stchur.com/2007/06/22/introducing-gimme/feed/ 2 http://blog.stchur.com/2007/04/06/serializing-objects-in-javascript/ http://blog.stchur.com/2007/04/06/serializing-objects-in-javascript/#comments Fri, 06 Apr 2007 06:12:06 +0000 sstchur http://stchur.com/blog2/2007/04/06/serializing-objects-in-javascript/ Recently, in a personal project I'm working on, I came across a need to be able to represent any Javascript object as a string. This isn't a problem since just about every object in Javascript can be represented with JSON (Javascript Object Notation). Every modern browser can parse JSON for you easily enough through eval(..), and Gecko-based browsers even have the ability to reverse the process ("uneval" if you will) and give you back a string representation of an object through a call to .toSource().

If you need this ability in any other browser though, you're gonna have to write it yourself. I needed this ability, so I wrote it (and posted it here for your enjoyment!)

Gecko-based browsers, .toSource():

Gecko-based browsers provide a handy function: .toSource() that you can call on any object in your Javascript code to get back a JSON-like representation of that object.

function Cat(name, age)
{
   this.Name = name;
   this.Age = age;
   this.Speak = function() { alert('Meow!'); };
}

var garfield = new Cat('Garfield', 5);
alert(garfield.toSource());

/* garfield.toSource() yields:
({Name:"Garfield", Age:5, Speak:(function () {alert("Meow!");})})
*/
 

Pretty simple right? You have an object; you want a string. Just invoke the object's .toSource() function.

Serializing objects in other browsers:

Serializing an object manually (as is required by non Gecko-based browsers) requires a bit of recursion. Simple types like integers, booleans, and even functions are trivial to represent as strings. Objects though, are more complicated because they can contain simple types or custom objects (which would need to be serialized themselves). Those "inner" objects could in turn, contain more custom objects, which would also need to be serialized, and this pattern could (theoretically) go on forever.

In practice of course, this pattern will (had better) come to an end. And we can leverage that fact to write a recursive function that will return a string representation (in JSON format) of a given object.

The serialize(..) function:

First the code, then the explanation.

function serialize(_obj)
{
   // Let Gecko browsers do this the easy way
   if (typeof _obj.toSource !== 'undefined' && typeof _obj.callee === 'undefined')
   {
      return _obj.toSource();
   }

   // Other browsers must do it the hard way
   switch (typeof _obj)
   {
      // numbers, booleans, and functions are trivial:
      // just return the object itself since its default .toString()
      // gives us exactly what we want
      case 'number':
      case 'boolean':
      case 'function':
         return _obj;
         break;

      // for JSON format, strings need to be wrapped in quotes
      case 'string':
         return '\'' + _obj + '\'';
         break;

      case 'object':
         var str;
         if (_obj.constructor === Array || typeof _obj.callee !== 'undefined')
         {
            str = '[';
            var i, len = _obj.length;
            for (i = 0; i < len-1; i++) { str += serialize(_obj[i]) + ','; }
            str += serialize(_obj[i]) + ']';
         }
         else
         {
            str = '{';
            var key;
            for (key in _obj) { str += key + ':' + serialize(_obj[key]) + ','; }
            str = str.replace(/\,$/, '') + '}';
         }
         return str;
         break;

      default:
         return 'UNKNOWN';
         break;
   }
}

Explaining a recursive function can be difficult, but I'll give it shot:

The function accepts just one parameter: the object (_obj) to be serialized. If you'll remember, I mentioned previously that simple types (string, boolean, number, etc...) were trivial because they all have an obvious string representation already. Complex types though, are more difficult because they can be made up of additional complex types, which in turn could be made up of additional complex types (and so on).

Of course, this pattern will eventually end; ultimately, everything is made up of simple types that have a string representation. The trick is figuring out how to traverse through this maze of "types within types." Recursion (simply stated: a function that calls itself) is perhaps the easiest way to solve this "types within types" problem.

Recursive functions always have a termination case -- something which causes the function to stop calling itself. Otherwise, the function would go into an infinite loop. In our function, there are actually four different cases in which the serialize(..) doesn't need to call itself:

1. typeof _obj is a number
2. typeof _obj is a boolean
3. typeof _obj is a function
4. typeof _obj is a string

If any of the above four conditions are met, returning a string representation is trivial, so we simply do it.

You'll notice that strings are treated separately from the other 3 types. You'd think strings would be the most trivial case, but actually, there is one thing we must do before returning the "string representation" of _obj when it is of type string: wrap it in quotes. We need to do this, because JSON expects it, and if we ever want to be able to eval(..) the result of a serialize(..) call, we'll need these quotes.

The only other case to deal with is when _obj is of type object. Within this case though, there are two "sub-cases" we need to deal with. The first is when _obj is an Array, or when it has a .callee property (more on that later). The second is well... anything else.

Basic Object Types

Your every-day, run-of-the-mill, object in Javascript can be represented as JSON with:

{ key1: val1, key2: val2, ... }

Where the keys are strings and the vals can be any simple type, or some custom object you've dreamed up. The logic I've used is to simply loop through a given object's keys and build a string of comma delimited, serialized key/value pairs that are wrapped in { and }.

Notice I said serialized key/value pairs. Here, our function is calling itself as it builds the object representation. This ensures that any objects within the object being serialized will also be serialized. If we didn't do this, we'd end up with a lot of strings that looked (something) like this:

{ key1: [object Object], key2: [object Object], etc... }

And that's clearly not what we want. We want those inner objects to be serialized as well, and that's what the recursive nature of our function will take care of for us.

Arrays

When _obj happens to be, not just any object, but more specifically, an Array, we have a better way of representing that as a string:

[ val1, val2, val3, ... ]

The logic I used here is to simply iterate through the array building a comma delimited list of serialized values, wrapped in [ and ]. Arrays in Javascript already have a .toString() function, but we can't use it here; if the Array contains objects, then the result of the Array 's .toString() could end up something like:

[ [object Object], [object Object], etc... ]

Again, not what we want, so we need to make sure we recursively serialize all of the elements in the array.

Arguments (the .callee "gotcha")

There's one bit of code I haven't discussed yet and it deals with the (possible) .callee property of the passed in _obj. It turns out that .toSource() (native function used by Gecko-based browsers) doesn't do anything very useful when called on an arguments object.

The arguments object is an array-like (but not an Array) object that is automatically available within the scope of every function. Unfortunately, no matter what is contained within that arguments object, calling .toSource() on it will always return "({})"

In order to be able to serialize an arguments object then, we need some way to detect it and then treat it like an array. The .callee property is a good choice because arguments objects have it, but other objects (to the best of my knowledge) do not.

In the case of the serialize(..) function, I decided to use the native .toSource() function whenever it was available, unless the object were an arguments object, in which case, I send Gecko-based browsers down the same path as all other browsers for serialization.

Finally, just for good measure, I've added a default case which returns the string UNKNOWN to handle a situation where no other cases applied. Of course, we probably don't want UNKNOWN showing up in the our serialized strings, but it probably won't do much (immediate) harm if it ever does show up, and its presence would be a helpful indicator that there is some case not being met (that probably needs to be).

Conclusion:

What would you ever use a function like this for? Well, In my case, I wanted to use a Javascript object as the key for a hash, but if I tried to do that, Javascript would just represent all of my (different) objects as the same string: [object Object], which wouldn't do me any good. By serializing the object, I can then use that serialized representation as a key in the hash.

It's worked well for my need so far, but I haven't tested it a great deal. If you find any bugs or short-comings, please let me know.

As always, comments are welcome.

]]> http://blog.stchur.com/2007/04/06/serializing-objects-in-javascript/feed/ 23