I does Javascript! » General

Dealing with CSS Vendor Prefixes

sstchur — Tue, 08 Nov 2011 06:03:56 +0000

The IE team recently posted what they're calling a best practice for dealing with vendor prefixes in modern browsers.

After reading it, I thought I would post the solution used in Gimme, which I implemented as soon as I had to start dealing with vendor prefixes.

I've yanked it out and posted it here as a stand-alone function called getStyleName(). You can use it when you want to set some element's style in Javascript. You always pass it the "standard" name (without any prefix) and it will do (or try to do) the right thing in the right browser.

For instance:

var someElem = document.getElementById('foo');

// MozTransform in Mozilla, webkitTransform in webkit, etc...
someElem.style[getStyleName('transform')] = 'rotate(90deg)';

Here is the getStyleName function in full:

var getStyleName = function()
{
var styleHash = {};
var vendorPrefixes = [ 'O', 'ms', 'Moz', 'Webkit' ];

return function(styleName, elem)
{
   elem = elem || document.createElement('div');
   var s = styleHash[styleName];
   if (!s)
   {
      // hope the browser supports the "official" (non-vendor-prefixed) style first
      var camStyle = camelize(styleName);

      // if not, then ask getVendorStyle for help -- it will try the various vendor prefixes seeking
      // one that works (if it doesn't find one, it will return an empty string, in which case we
      // revert back to originally passed in styleName)
      if (elem.style[camStyle] === undefined)
      {
         camStyle = getVendorStyle(camStyle, elem) || styleName;
      }

      // finally, store the camelized & vendor-specific (if applicable) value in the styleHash where key = styleName that was passed in
      s = styleHash[styleName] = camStyle;
   }
   return s;
}

function camelize(s)
{
   return s.replace(/-(\w)/g, function(m, c)
   {
      return c.toUpperCase();
   });
}
}();

True private variables in Javascript with prototype

sstchur — Tue, 27 Sep 2011 05:09:49 +0000

Most folks know how to mimic public, private, and "privileged" variables in Javascript, but I think at some point, when getting familiar with prototypal inheritance, most scripters wonder if there is a way to access the private members (the ones created in a closure) of an instance within a function defined using prototype.

There is really no good way to do this. Here's a simple prototype example:

function Cat(name, age)
{
this.name = name;
this.age = age;
}
Cat.prototype.introduce = function()
{
alert('I am a cat. My name is ' + this.name + ', and I am ' + this.age + ' year(s) old.';
};

var c = new Cat('Garfield', 7);
c.introduce();

The introduce function was defined with .prototype so the this keyword in that context refers to the Cat instance in question. Using it, we can get at the .name and .age properties. But this also means that the introduce function isn't the only thing that has access to those properties. In fact, the whole world has access. They are, essentially, public properties.

alert(c.name); // directly accessible
alert(c.age); // directly accessible

What if you don't want that? What if you want to take the name that is passed into the constructor, modify it in some way (let's say, convert it to uppercase) and then offer read only access to it?

function Cat(name, age)
{
this.name = name.toUpperCase();
}
Cat.prototype.getName = function()
{
return this.name;
};

var c = new Cat('Garfield', 7);
alert(c.getName()); // GARFIELD
c.name = 'STEPHEN'; // oops, should this be allowed?
alert(c.getName()); // STEPHEN, clearly not the kind of encapsulation we're going for

So how can we allow getName to have access to .name, but at the same time disallow access to .name outside of prototype defined functions? Well, as I said, you really can't. I mean, there's no good way. But there is a sort-of way.

DISCLAIMER: I am NOT recommending that you actually do what I'm about to demonstrate. At the same time, I am not telling you NOT to do it either. From a performance perspective, this is completely unvalidated (at least by me). So if you want to do something like this, best do your homework and figure out if it will offer you an acceptable level of performance -- I am not attempting to answer that for you.

Alright. With the disclaimer out of the way, here we go:

var Cat = function()
{
var guid = 0;
var privates = {};

return cat;
}();

var cat1 = new Cat('Garfield', 7);
var cat2 = new Cat('Fluffy', 13);

alert(cat1.getName === cat2.getName); // true
alert(cat1.name);         // oops, no dice (which is good)
alert(cat1.getName());       // Garfield
alert(cat2.age);       // oops, no dice
alert(cat2.getAge());          // 13

First, I alert cat1.getName === cat2.getName to illustrate that prototype really is being used here. The instances cat1 and cat2 share the implementation of the getName function (they don't each get their own -- something that would have been true had we used the closure model exclusively).

Second, you'll notice that I do not have direct access to .name or .age. So this seems to do what we want.

Now, more alert readers will no doubt have noticed that I cheated. I'm still using the this keyword from within my prototype defined functions, getName and getAge. This is so that I can access the instances GUID (._$guid). The GUID is, of course, nothing more than counter, but it serves as a way to track the created instances. Using it, we can get access to property bag in the privates hash that "belongs to" the particular Cat instance we're interested in.

But there is a flaw here, of course. The ._$guid, despite its marginally cryptic name, is completely unprotected. That is, the whole world has access to it. So one could really hork things badly if he decided to do something like:

var garfield = new Cat('Garfield', 7);
var fluffy = new Cat('Fluffy', 10);

fluffy._$guid = 0;
alert(fluffy.getName()); // Garfield, oops! this is NOT good

Now, in this example, I chose a valid GUID (that of Garfield), but I could have just as easily chosen an invalid GUID, which would have caused a script error. Of course, the script error is easily preventable by ensuring that the ._$guid actually exists as a key in the privates hash before attempting to access it, but this does nothing to ensure the integrity of the data, and that's a problem.

Turns out though, that we can add a bit more code. A bit of code that involves a check prior to accessing data from the privates hash to ensure that the instance's _$guid hasn't been tampered with. If it has, we throw an exception and refuse to go any further.

Here's the revision:

var Cat = function()
{
var guid = 0;
var privates = {};
var check = {};

return cat;
}();

var fluffy = new Cat('Fluffy', 7);
var snowball = new Cat('Snowball', 12);
var garfield = new Cat('Garfield', 9);

alert(fluffy.getName());    // Fluffy
alert(snowball.getName());   // Snowball
alert(garfield.getName());   // Garfield
fluffy._$guid = 2;
alert(fluffy.getName());    // Throws an exception, b/c fluffy's _$guid was modified

I even created a nice illustration to help you visualize this

As you can plainly see, the keys in the privates hash correspond to the ._$guid property of Cat instance. In other words, if you match up an instance's ._$guid with a key in the privates hash, you'll have access to that instance's collection of member variables.

You'll also notice that the keys in the check hash match the keys in the privates hash. However, they don't point to a property bag, they point to an actual Cat instance. In the getName function, we have access to the instance (through the use of the this keyword), and we can use that to perform a check. If an instance's public ._$guid has been tampered with, then looking in the check hash for that $_guid will result in accessing a Cat instance that isn't equal (identical) to this. In that case, we can throw an exception. Otherwise, we go ahead and access and entry from the privates hash, and this gives us access to the current Cat's members.

Before closing, I want to once again make clear that I am most definitely NOT recommending that you use this model, but neither am I discouraging the use of it (I'm a little bit annoying that way, I know). It's simply untested in terms of memory and speed performance. Whether or not this yields anything that would constitute acceptable performance, I do not know and have not attempted to determine. I imagine there could be some scenarios in which it is probably okay. And I imagine there are other scenarios in which it might be a nightmare, but I'm only guessing on both counts.

If you decide to experiment with this, definitely report back here with your findings for all to see.

Happy scripting!

Dependency Injection / Dependency Management (part 1)

sstchur — Sat, 06 Aug 2011 01:19:31 +0000

I'm not an expert when it comes to dependency injection, but I do know a little. My team uses Unity in one of its projects, so I have some exposure.

Recently, I started work on a project (hoping to eventually release it as OSS) on a Dependency Injection (like) / Dependency Management framework for the client (that is, written in Javascript).

Since it was (is) a fun project for me, I thought I might blog about some of the more interesting parts of what I've done.

Dependency Resolution:
One of the key parts of Dependency Injection is dependency resolution. That is, if I need an instance of something, say, a Foo, and if creating a Foo requires an instance of say, a Bar, then my DI framework ought to resolve the Bar for me on its way towards creating my Foo.

var registration =
{
Foo: { className: 'Stephen.Stchur.Foo', params: [ 'Bar' ] },
Bar: { className: 'Stephen.Stchur.Bar' }
}

// obviously, code for Container, not show here (yet)
var c = new Container(registration);
var f = c.instance('Foo'); // container "knows" Foo needs Bar; it takes care of it for us

So what I'm focusing on in this blog post is the comment above: "container 'knows' Foo need Bar; it takes care of it for us.

In a future post, I'll be talking more about the management part (involving not only resolving types on demand, but also downloading dependencies and groups of dependencies prior to resolution).

But for now, let's just assume that all dependencies needed to create anything/everything have already been preloaded.

So how does the container know that Foo needs a Bar? Well, it's not too hard to figure out if you look at the registration. It's just a dictionary of key/value pairs, where the value is a simple object literal containing a couple properties:

className - required, the fully qualified name of the thing that the container will eventually be creating instances of
params - optional, an array of string keys that map to other values in the registration dictionary

Container knows that Foo needs a Bar because that was explicitly spelled out in the registration when we defined:

Foo: { className: 'Stephen.Stchur.Foo', params: [ 'Bar' ] }

The params array tells the container everything it needs to know. So what does the code that actually implements this type resolution look like? Glad you asked. Code below, explanation to follow:

function Container(reg)
{
function instance(factoryName)
{
var params = reg[factoryName].params;
var i = params.length;
while (i--)
{
var f = reg[params[i]];
if (f)
{
params[i] = instance(params[i]);
}
}

return create(reg[factoryName].className, params)
}
this.instance = instance;

function create(type, params)
{
var constructor = new Function('return ' + type)();
var inst = new constructor();
inst.init && inst.init.apply(inst, params);
return inst;
}
}

var c = new Container(registration);
var f = c.instance('Foo');

Now this is not actually the code used in the project I'm working on. It's actually rather different, but this will suffice for now. One thing to note is that I'm really not performing any sort of safety checks here. If you ask the container for an instance of something that hasn't been registered, it will not fail gracefully (and it really should). But that's an easy change and not really the focus here.

There isn't a ton code that requires explanation here, except for a couple pieces. The first piece that I suspect will raise some eyebrows is:

var constructor = new Function('return ' + type)();

Now let me say right off the bat that I'm not claiming this is the best way to do it (certainly it's not the only way). Essentially, this is just a confusing way of doing:

var constructor = eval(type);

So why not just do that? Well, I'm not saying you can't, but a lot of people have a hard-line stance against using eval. Also, in some browsers, eval was much slower than using new Function(..). However, in other browsers, eval was faster (sometime nominally, sometimes significantly).

Finally, there is another option in this case: you can split the type string on the dot, and actually attempt to access the parts as properties. It would ultimately translate to something like:

var constructor = window['Stephen']['Stchur']['Foo];

Of course, you wouldn't hard code it like that, you'd split the string and loop, but I trust you get the idea. For simple cases, this actually turns out to be quite fast, so it's something to consider. But also worth considering is that fact that, for small numbers of repeated executions, it matters very little which method you choose. And if you cache the resolved constructor once you get it, it matters even less.

Anyway, I used new Function(..) in this post, because I think it's an interesting way to accomplish the task (not necessarily the best, but chances are you haven't seen it before, so you learned something, and that's what this blog is all about -- spreading knowledge and learning).

If you're unfamiliar with Function (capital F) in Javascript, allow me to explain.

Function in Javascript is a constructor that takes a string and returns you a function whose logic is whatever string-code you passed into it. For example:

var sayHello = new Function('alert("hello there");');
sayHello(); // alerts "hello there"

It's not too hard then to see how we've leveraged Function in our case. We created a function whose job it is to return a reference to function named, type. That is, if type = "Foo" then this code:

var constructor = new Function('return ' + type)

Will result in the variable constructor, pointing to the function, Foo (so it essentially is Foo). Another way of thinking about it is that the implementation of the function we've create is:

return Foo;

And when you execute that function, what you get back is a reference to the function Foo, which is the constructor you care about.

Great! Now what? Well, now we should invoke the constructor. Unfortunately, things fall a part a little bit here (but only a little). There isn't really a great way to invoke a constructor with the new keyword and at the same time pass in an array of params to be used as the individual arguments to that constructor. More clever Javascript Ninjas will give you creative solutions. You can create an empty object, and then call .apply on the constructor, passing in the object you created as the this object and the items in whatever array you pass in will becomes the individual arguments to the constructor. This however, won't result in an object that actually is an instance of your constructor.

function Cat(name, age)
{
this.description = 'furry';
this.name = name;
this.age = age;
}
var c = {};
Cat.apply(c, [ 'Garfield', 10 ]);
c instanceof Cat; // false

You can carry this further though. You can set the native prototype of your c object to be Cat's prototype:

var c = {};
c.__proto__ = Cat.prototype;
c instanceof Cat; // true

However, support for __proto__ is not so good in several older versions of a certain, still-fairly-popular-but-I-have-no-idea-why browser (I'm a Firefox guy myself).

It's worth pointing out here that your temptation to try c.prototype = Cat.prototype will not work, but I'm not going to get into why. This isn't a post about prototype in Javascript.

If you care to, you could iterate Cat's prototype and manually copy over all the properties. Then your object would satisfy as a Cat if you're okay with duck typing. But it still wouldn't actually be a Cat.

Well, if you're only targeting browsers that support __proto__, then that's an option. If you don't care about your object actually being a true instance of the thing you're creating, then you can use .apply and copy over the prototype. Or, if you have some magic pixie dust that I don't have, then I suppose that's an option too (please share).

Short of any of those things, your other option is to mandate some sort of a convention. Two conventions come to mind that are simply and work well.

Mandate that all constructors be able to successfully execute, parameterless. And then automatically call (if it exists) some special initialization function (I like .init) that take all the params that really matter.
Mandate that all constructors take only a single param - an array of values needed to construct the instance.

I chose option 1 for the sample code in this post. I like it better than option 2 because I have a Chocolate Lab named Guinness (that didn't make any sense).

Moving on...

With the instantiation out of the way, the only remaining bit of code might be the resolution of the params.

First we grab a reference to the array of params, as defined by this factory's definition in the registration:

var params = reg[factoryName].params;

We then loop through it (backwards, because that's how I roll), and pull out each value, assigning it to the variable, f. We assume that f points to a valid, registered, factory. If not, we leave the value alone (this isn't particular useful right now, but in a future blog post, you'll see the code reworked a bit so that the .instance function can accept arbitrary values to be used as other arguments in constructing your object).

Now if f does point to a valid, registered factory, then we go ahead and resolve it. Resursively. By calling .instanace again. This is important, in case of the params, are factories that take other params that are factories.

Once we've resolved a param though, we can actually just have the result "take over" what was in the original params array at the index originally.

params[i] = instance(params[i]);

In this way, the right value will be in the right place in the params array when it finally gets plumbed through to the call to inst.init.apply(inst, params)

Makes perfect sense right?

Honestly, I think it's harder to speak/write about than it is to just understand. It's not super complicated. It will get more complicated though. But that's for a future blog post. In the mean time, here's a full, copy/pastable bit of code that actually works.

var Stephen =
{
Stchur:
{
Foo: function()
{
this.desc = 'foo!';
},

Bar: function()
{
this.desc = 'bar!';
this.init = function(f) { this.myFoo = f; };
},

Baz: function()
{
this.desc = 'baz!';
this.init = function(f, b)
{
this.myFoo = f;
this.myBar = b;
};
}
}
};

var registration =
{
Foo: { className: 'Stephen.Stchur.Foo' },
Bar: { className: 'Stephen.Stchur.Bar', params: ['Foo'] },
Baz: { className: 'Stephen.Stchur.Baz', params: ['Foo','Bar'] }
};

function Container(reg)
{
function instance(factoryName)
{
var params = reg[factoryName].params || [];
var i = params.length;
while (i--)
{
var f = reg[params[i]];
if (f)
{
params[i] = instance(params[i]);
}
}

return create(reg[factoryName].className, params)
}
this.instance = instance;

function create(type, params)
{
var constructor = new Function('return ' + type)();
var inst = new constructor();
inst.init && inst.init.apply(inst, params);
return inst;
}
}

var c = new Container(registration);
var f = c.instance('Baz');

Look for part 2 coming soon.

Happy scripting!

Javascript Quiz

sstchur — Fri, 10 Jun 2011 18:45:25 +0000

Inspired by some Javascript questions I was asked recently by a few co-workers, I decided to put together what started out a little reference/cheat-sheet, but which ultimately took the form of a Javascript Quiz.

It's meant to be fun and informative. You keep track of your own answers (if you want to); no one ever has to know what you got right or wrong.

I should mentioned that I did NOT test this in all browsers. I'm a Firefox guy, so that's where I do most of my testing and development for little one-off personal projects like this. I did take a quick pass with IE8 and Chrome, but I did NOT test with IE6 or IE7 or Safari. If something doesn't work in one of those browsers, feel free to let me know, but bear in mind that there is a strong possibility that I will not care in the least

And of course, there's always multiple ways to solve a problem. I do not claim any sort of authority with any of the answers I've provided. If you dislike an answer of feel you have a better one, good for you

Anyway, here it is: http://blog.stchur.com/blogcode/jsquiz

Enjoy!

My New Blog

sstchur — Fri, 07 Nov 2008 20:12:47 +0000

This blog is mostly technical. I do, from time to time, post about non-technical things, but I try to keep this blog more or less about programming, the web, and javascript.

But I'm a loud-mouth and I have lots to say. So rather than clutter up this blog with "too much" incoherent babble, I decided to start another.

My new blog is called Stchur on Whatever (http://whatever.stchur.com) and on it, I'll write about whatever the heck I feel like.

So please check it out.

Microsoft Releases New Version of Live Maps

sstchur — Thu, 25 Sep 2008 02:40:34 +0000

Microsoft released a new version of Live Maps today. This version features multi-way point routing as well as a number of other nice little updates.

Another cool thing about this release is that it features Gimme quite prominently. After getting directions, you'll notice the ability to expand/collapse the directions specific to each point along the route. That nice, smooth animation you see is Gimme doing what Gimme does best!

Wither IE6?

sstchur — Tue, 22 Jul 2008 13:00:07 +0000

Welcome aboard guys. Glad you finally decided to start thinking about what I discussed long ago.

Firefox 3

sstchur — Thu, 19 Jun 2008 14:45:50 +0000

Well unless you've been living under a rock, you know that Firefox 3 was released on Tuesday. This is a big deal for me. When other browser makers release a new version, it's like eh... ok, that's cool (I guess). But when Mozilla releases a new Firefox, I've got a brand new shiny app to get me through my day to day web browsing.

Besides the new theme (on Windows) being a little bland, FF3 does not disappoint!

Palindromes

sstchur — Sat, 14 Jun 2008 19:06:11 +0000

The other evening while I was watching TV, I happened to have my laptop out, so I started dabbling around in Firebug just for the heck of it. I'll often just start writing functions for no particular reason, other than to refresh my skills or perhaps discover something about Javascript that I hadn't previously known.

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:

Writing the function in a clever way, so as to achieve the least amount of code possible
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:

def pal(s)
s == s.reverse
end

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):

function pal(s)
{
return s === s.split('').reverse().join('');
}

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:

function pal(s)
{
var i, j,
len = s.length,
mid = Math.floor(len / 2);

for (i = 0, j = len - 1; i < mid; i++, j--)
{
if (s.charAt(i) !== s.charAt(j)) return false;
}
return true;
}

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:

function pal(s)
{
var len = s.length,
x = len / 2,
y = x === Math.floor(x) ? x : (x = Math.floor(x)) + 1;

return s.substr(0, x).split('').reverse().join('') === s.substr(y,len);
}

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).

Another Puzzle

sstchur — Mon, 09 Jun 2008 17:25:38 +0000

Well after some significant thought, I have decided that I was either not given enough information to solve the puzzle in my last post, or I'm going to need a hint from the person who gave me the puzzle.

Either way though, I don't have an answer to post as I promised I would, but not to worry... I have something better: another puzzle!

This one I heard on NPR's Puzzle Master, so I know it is legit:

On a calculator display there are 5 digits. The first 4 digits are: 8 7 3 5. What is the fifth digit?

It's not a trick question, and there is a simple and elegant solution to the puzzle.

In case you're wondering, I heard this in the car listening to the radio, and I'd estimate that I drove about 5 miles or so before the answers came to me, so I'll guess that that was about 5 minutes. How long did it take you to solve?

Comments welcome.