This made it somewhat tedious to decode them, as the only way to get the original list of points was to create a GPolyline and then pull out the points from that object. This is not ideal since the work must always be done on the client side with JavaScript and using Google Maps.

To solve this, I quickly ported the algorithm over to PHP from the JavaScript source. Please feel free to download/modify/use this script.

Since the encoded polyline format offers numerous benefits (and because I had data already stored in this format) I did not want to move away from it. At the same time, I needed access to the points for working with things like Google Static Maps, which curiously does not accept the encoded polyline format for displaying paths. (Probably to reduce resource usage on their end, since decoding takes CPU time)

Thankfully the polyline decoding algorithm was already available at Mark McClure’s site. I spent a few minutes understanding the process and porting it over to PHP. The source is attached above and is released under an MIT license. Basically, the only change I had to make was to use some PHP functions to convert characters to their ASCII code, since PHP doesn’t have a charCodeAt() function.

Please let me know if you find it to be useful.

I had been using input validation, but my validation procedure was not stringent enough to detect the improper parameter. This was tied to the fact that before the implementation change, things worked perfectly fine even with the improper inputs. However, the implementation change “broke” this work flow. All of this has led me to believe in the great importance of:

1. Draconian validation: For inputs, only accept what you say you will accept. Nothing else should pass.
2. Proper unit testing: Test your method with a variety of inputs, both expected and unexpected or non-conforming. You never know what callers will pass into your methods.

Let me go into some more detail.

Unintended consequences

I had written a method that would accept a FQDN (Fully-Qualified Domain Name) as its argument. The purpose of this method was to retrieve some information over HTTPs from the web server running on the server with the specified domain. Since domain names are protocol-neutral (i.e. they aren’t preceded by something like “http://”), I ended up forming a URL object based on the FQDN, since eventually I’d be retrieving information over HTTPs anyways:

final URL url = new URL("https://" + fqdn + "/path_to_service");

I figured that this was enough protection in terms of input validation, since the constructor for URL throws a MalformedURLException if something goes wrong. (There was other code to check if the web server at the specified URL could actually be contacted and this was contained in the actual retrieval)

However, it turned out that callers had started using this method by passing in not just an FQDN, but an FQDN followed by a port number in the following format: host.name:portNumber. This was being used so that servers operating on non-default HTTPs ports could be contacted.

Initially, this worked, as then the statement above was executed with something like this:

// With fqdn == "some.host.name:portNumber", nothing fails.
final URL url = new URL("https://" + fqdn + "/path_to_service");

This was because the URL formed was still valid. However, this was an invalid use of my method because we had never specified that this sort of input was allowed. It just happened to work. The issue of non-default HTTPs ports and the usage here was never discussed and because it seemingly worked, nothing was done about it.

Changing times

Some time went on until I decided to make an implementation change. Instead of retrieving the information from the web server itself, I would instead retrieve it directly from the TLS handshake process using a API provided to me. (The information was related to the certificates)

This API accepted two parameters: The server host name or FQDN, and a separate port number. Not realizing that callers were passing in non-default port numbers in the first place, I ignorantly just passed the FQDN supplied to me into this API along with the default HTTPs port. (443)

As expected, this broke the functionality that callers had come to expect of my API, namely, custom HTTPs ports specified alongside the FQDN in the argument. It was only after these complaints were filed that I realized my API was expected to take not just the FQDN, but something like “server.host.name:8080″.

The causes

The problem was quickly fixed as the solution was fairly trivial, but the causes have taught me several lessons.

1. Be Draconian in your input validation

   Or, don’t trust your callers to read your documentation. Initially, I thought my method was to accept only an FQDN. Even though I was wrong in this respect, the problem could’ve been identified earlier if I had coded my method to fail (i.e. throw an exception) if anything that was not an FQDN was passed in. (Simply forming a URL object around it was not stringent enough) This way, things wouldn’t have initially worked by coincidence and I would’ve had an earlier opportunity to correct my mistake.

2. Unit test for exceptional cases

   My unit testing of my method was not extensive enough. Though I coded both pass and fail tests using JUnit, I did not test for cases where someone would (very likely) try to pass in a port number along with the FQDN. This step goes hand-in-hand with the above: Code your methods to accept only what you’ve said they’d accept, and fail on everything else. Then, unit test to make sure this contract is fulfilled.

While the problem was frustrating, I’m glad to have learned these lessons.

I’ve been playing around with the Google Maps API for a bit and it’s turned out to be a great way to get started with “mashups” and the like. One of the best uses of the API is the ability to create paths or routes on the map.

This is done by creating GPolyline object and then adding it as an overlay to the map. Basically, a polyline is just an ordered list of geographical points/coordinates on the map, each of which is a GLatLng object. For serialization/storage of polylines, there is an algorithm you can use to Base64-encode a series of points; the resultant string can later be passed directly into a factory method to regenerate the GPolyline. By using encoded polylines, you also get access to a few more interesting and useful options related to rendering and performance issues.

Encoded Polylines

Despite the algorithm for encoding polylines being readily available on the Google Maps API documentation site, there is no built-in functionality within the API for generating the encoded polyline string from an existing GPolyline object. This might be a bit strange, but it’s probably because the encoding process requires some extra values that aren’t available in the typical polyline.

As specified on the algorithm page, you also need to specify a list of encoded “levels” in addition to the points themselves. These levels tell the the Google Maps renderer when certain points can be omitted from the polyline depending on the zoom level. For example, with a polyline with n points, you’ll always want to show the first and last point, no matter what the zoom level. However, intermediate points can potentially be omitted at low zoom levels and only shown when the map has been sufficiently zoomed in to warrant the detail. This sort of optimization cannot be done with the typical GPolyline constructor that just takes an array of points. (GLatLng objects)

Making things easy

If you’ve looked at the polyline encoding algorithm, you’ll probably notice that it’s a bit tricky unless you’ve taken course in CS or done a lot of this stuff before. (At least it was tricky for me) Google has an interactive utility for generating the encoded polyline format for you. The results can then be stored and later fed into a call to the factory method GPolyline.fromEncoded() to regenerate the polyline.

However if you want to generate the encoded polyline format on-the-fly as part of your application, the interactive utility is not really an option. Instead of coding the algorithm from the ground-up, there’s a much better way of doing things, thanks to the PolylineEncoder class and other utilities provided by Mark McClure.

The PolylineEncoder class is written in JavaScript and is very straightforward in its usage. (It has been ported to several other languages as listed on his site, in case you need to use it in different contexts)

Using this class allows you to quickly and easily convert a GPolyline into a compact encoded format useful for serialization or storage. You can also use the class to convert arrays of points into encoded polylines, thus gaining the benefit of optimized rendering at different zoom levels. McClure goes into an in-depth, but easy to understand explanation of the encoding algorithm used complete with animations that show exactly how the polyline approximations work.

I highly recommend the usage of his polyline encoder as it saves you the headache of implementing it yourself. It’s well-written, thoroughly documented and is free for usage. (It isn’t licensed under open-source terms but has instead been placed in the public domain - which is perhaps even more “free”) McClure also has a few other interesing Google Maps projects that you may want to check out.

Some documentation warnings

The Google Maps API documentation is fairly thorough, but it’s out of date in some places, as some people have found. Indeed, in this case, it appears that the GPolyline.fromEncoded() is documented somewhat wrongly in the API reference, though curiously, is used properly in their examples page.

Specifically, you should not use:

GPolyline.fromEncoded(color?,  weight?,  opacity?,  latlngs,  zoomFactor,  levels,  numLevels)

if you want to generate a polyline from the encoded format. Instead, you should use something like:

GPolyline.fromEncoded({
    color: "#FF0000",
    weight: 10,
    points: "yzocFzynhVq}@n}@o}@nzD",
    levels: "BBB",
    zoomFactor: 32,
    numLevels: 4
});

This is because the API has been updated to accept an object of options instead of separate parameters. This, in my opinion, is better for readability and takes advantage of JavaScript’s ability to define inline anonymous object literals.

As a side note, the example actually calls something like new GPolyline.fromEncoded, but I’ve found that you don’t need the new keyword, and in fact, it’s a bit confusing that the example has it and that it would work - after all, you are calling a factory method that returns a type of GPolyline, and not directly instantiating an object. (At least as far as JavaScript uses the new keyword)

* Sensationalist headline inspired by previous posts

Eclipse is my IDE of choice, as you’l probably have noticed from some of my previous articles. I had been wanting to write an article about why I use it (and why I switched to it), but kept putting it off. Recently, Matt Mullenweg wrote about his problems with Dreamweaver, and this perhaps prompted me to organize my notes on why I’ve chosen to use Eclipse. Don’t get me wrong - I’m not advocating that you immediately switch and throw out your current editing tool (the headline above, as noted, is purely for sensationalism) - but rather I’m just urging you to consider Eclipse for your next project.

Changing Gears

Like many, before switching to Eclipse I had been using a pure text editor, Ultraedit, for most of my web-development activities. Ultraedit seemed fine for most things, offering basic features like code highlight and autocompletion. However, it lacked a certain finesse when it came to dealing with larger projects. For example, if you’d defined a class, its members wouldn’t be available for autocompletion. Something else was needed. I finally decided to take the plunge, and switch over to Eclipse for all my development towards the end of the summer last year.

Some might wonder why I was even using a text-editor in the first place for development. For those coming from a traditional programming/development background, the idea of not using an IDE (Integrated Development Environment) is silly. This is because a lot of programming languages are compiled, and in this case, it just makes sense to use an IDE since it’s easier to write code, compile and debug using one tool instead of multiple ones.

However, for scripting languages, especially those meant to run on a web server, one can “get away” with not using an IDE quite easily. This is because the scripts are not run standalone but are almost always executed in the context of a web server; thus you’re usually editing code that you then run on a development web server, without the need for a special tool like a compiler. Additionally, it’s easy to view the output using any web browser. These reasons are what allowed me to persist in using a text-editor for so long.

No turning back

However, once I started using Eclipse, I was hooked. I downloaded Eclipse PDT (PHP Development Tools), which is basically a version of Eclipse bundled with the tools/plugins necessary for setting up a PHP development environment. Besides offering everything Ultraedit did, it also offered nice features like easy ‘Todo’ lists, (just type ‘todo’ anywhere in a comment and it’s automatically indexed by Eclipse into a list), code completion for built-in PHP functions and your own as well as a multitude of other advanced features that IDEs have. Oh, and it’s also FOSS. (Free and Open Source Software)

However, perhaps the best part about Eclipse is its robust and well-supported plugin system. This allows Eclipse to pretty much assume any feature that someone is willing to write a plugin for. This is what really sold me on Eclipse, because this almost makes its abilities endless. Some of the plugins I use are Subclipse for SVN integration, Mylyn for Trac integration and JSEclipse for JavaScript editing. This is part of the reason why Eclipse is the basis for many other IDEs out there.

Some other nice features are the ability to link the IDE in with the Zend Debugger, thus allowing for proper debugging sessions with PHP.

Spoiled

However, I’ve been pampered somewhat and have found a few things to complain about, at least when it comes to Eclipse PDT. I use Eclipse JDT (Java) a work and its advanced refactoring abilities are a feature I find myself wanting in the PDT version. Have you ever found yourself wanting to rename a variable to something more descriptive but putting it off because you’re afraid you’ll mess something up by forgetting to change the name somewhere?

With some IDEs, you’re left having to just do a search-and-replace in order to accomplish what should be a trivial name refactor. Even if your editor supports regex searches, things can still be tricky - what if you’ve used the same name, but in a different context, and thus shouldn’t change the variable there? The point is, the process still has to be human-supervised and is tedious. With Eclipse JDT’s advanced refactoring, you can rename the variable once - and the IDE is smart enough to know where else to change it to keep the code consistent - very neat, and I was amazed when I first used it. Other refactoring abilities include extracting methods out of blocks of code in order to clean up lengthy methods. All of this makes your life 10 times easier and allows you focus on real programming rather than annoying tasks.

However, Eclipse PDT doesn’t support this for PHP code, yet. I hear that it may be supported in a later release, so I have my fingers crossed. Perhaps accomplishing these refactoring tasks is easier in Java because of its compiled nature or because the JDT project has received more attention. It’s definitely possible in PHP, as some IDEs, such as the Zend Studio (which is based on Eclipse) support this ability. Zend Studio, however, is a commercial solution and I haven’t tried it out yet.

Nothing’s perfect

Eclipse does have its downsides as compared to a traditional text editor. First of all, it’s a memory hog - though most IDEs are. I have regularly seen Eclipse eat up 300-400 MB of RAM if I’ve been using it for a long time. However, it should be noted that I have not had it crash once, so it’s been rock-solid as far as stability goes. Nonetheless, I recommend you to have at least 2 GB of memory if you really want to use it properly, since you’re likely to have other programs open. This is especially important if you’re running Windows Vista. RAM is quiet cheap nowadays, and you can easily pick up 2 GB for $50 or less and upgrading is a painless process, so there’s no reason not to.

Finishing up

Eclipse has changed my life. Okay, so perhaps I’m exaggerating a bit. But, I can say that development, at least for me, would be much harder without Eclipse. If you’re still using a text editor for development, I urge you to give Eclipse a try - just for 30 days, and see how you like it. I don’t guarantee results as good as mine, but you may be pleasantly surprised.

This is why inheritance in JavaScript is probably one of the least understood concepts. While languages like Java have well-defined constructs for inheritance, the topic is of less importance with JavaScript. In many situations, you’ll never have to deal with these aspects when programming in JavaScript, simply because it isn’t required for a lot of client side scripts. However, for larger-scale web applications, applying object-oriented principles to your code may make it easier to design, improve and maintain.

There have been many articles written about inheritance in JavaScript and how it can and should be done. You really don’t need to read mine to gain an understanding. Rather, I’m just going to write about what I’ve learned, the process I went through and the experience I’ve gained along the way.

It’s all new(s) to me

If you come from a Java background, you’ll be no stranger to the new keyword. Using it allows you to instantiate a new instance of an object from its class by calling its constructor. The keyword also makes a lot of sense, since you’re creating a ‘new’ object.

JavaScript also has a new keyword, but it doesn’t do quite the same thing as its Java counterpart, though at first the effects might seem similar. This is one of the main reasons why JavaScript inheritance tends to be poorly understood.

Consider the following example.

function Foo(name)
{
  this.name = name;
}

var fooObject = new Foo('I am foo');

If you’re familiar with Java or JavaScript, this example is fairly straightforward. In the prototype-based JavaScript, functions can serve as object constructors in somewhat the same manner as a constructor in Java. However, Foo in the above example is not a class, since classes do not exist in JavaScript. So, if Foo is not a class, what exactly happens when the statement var fooObject = new Foo('I am foo') is executed?

Taking a step back

Before we dive into the details, I’ll explain the concepts of a prototype-based language as it applies to JavaScript. I mentioned above that JavaScript does not use classes like Java does. This basically means that new objects are not created from instantiation of classes, but rather inherit from existing objects. Thus, there is no “class hierarchy” but rather just an object hierarchy.

In JavaScript, all objects are descended from the built-in Object type. This is similar to how all Java classes implicitly have the Object class as a superclass. In JavaScript, instead of extending classes, you can inherit by manipulating the prototype property on a type; that is, the prototype property on the function you are using to create an object. Let’s see some code to straighten things out.

function Foo(name)
{
  this.name = name;
}
Foo.prototype.getName = function()
{
  alert(this.name);
}

var fooObject = new Foo('I am foo');
fooObject.getName(); // Will alert with 'I am foo'

This example is identical to the first one, except for the lines that are emphasized. Here, I’ve set the getName property on the prototype property of Foo equal to a reference to a Function object. This is effectively the same as defining a method for a class, since any object created from that type can call the method getName() on itself to return the proper value. But what exactly is happening, and what’s the deal with the prototype property?

More new(s)

In JavaScript, the new keyword actually accomplishes a few things. When you execute an expression such as var fooObject = new Foo('I am foo'), here’s exactly what happens.

1. First, a new generic object is created. This object is the same as if you created the object using the statement new Object(), using JavaScript’s built in Object type.
2. The constructor function, that is, the function Foo(), is then called with the this keyword set to reference the newly-created object. The parameters supplied are also passed to the constructor function, in this case, the string “I am foo”. If you’re familiar with context, this is equivalent to:

   var fooObject = new Object();
   Foo.call(fooObject, 'I am foo');

   Thus, the code in Foo() sets a property called name equal to the supplied string. Up to this point, things are the same as if you had created a new object and then manually set the name property yourself. The next step is where things change.

3. The last step is where inheritance takes effect. The constructor function, in addition to executing the specified code above, also sets an internal property called __proto__ equal to the value of Foo.prototype. This is how the new object inherits from the old one.

   When you call a property on fooObject now, JavaScript will first check to see if the object has a local value for it. In this case, the only local property is name. (Besides the internal and implicitly set __proto__ property. However, if it does not exist locally, it will check to see if the property exists under the object referenced by the __proto__ property. In this case, the getName() method exists under here.

Where things get confusing is because of how the new keyword is used. Perhaps the designers of JavaScript wanted to use a keyword familiar to Java programmers so as to ease the transition to a new language that sounded so similar. While it accomplishes a similar goal and for the most part you can consider the action to be almost the same, the use of the new keyword conceals the true meaning of prototype-based inheritance in JavaScript. This ends up causing more confusion when you start digging into code.

We’re all the same

Suppose you created multiple objects from the Foo() constructor, called fooObject1, fooObject2 and fooObject3, In one fell swoop, you could add a new method to all of these objects without having to recreate them. This is because of the prototype property. Because each object contains a reference to Foo.prototype, adding a new method here will allow all objects access to it. For example:

Foo.prototype.yellName = function()
{
  alert(this.name.toUpperCase());
}
var fooObject3 = new Foo('I am Foo 3!');
fooObject3.yellName(); // alerts 'I AM FOO 3!'

This adds another method to all Foo-constructed objects allowing them to “yell” their names.

Extending Types

I mentioned inheritance above but with just one type definition, the principles weren’t too clear. Suppose we decided to extend our Foo “class” - how exactly would this work? First, you need to define the child type and then set its prototype value to a new object of the parent type. An example:

function FooChild(childName)
{
  Foo.call(this, 'I am a child of Foo and my name is ' + childName);
}
FooChild.prototype = new Foo('');

var fooChildObject = new FooChild('Barbar');
fooChildObject.getName(); // Will alert with 'I am a child of Foo and my name is Barbar'

Let’s break down what’s going on here.

1. First, we define a new constructor called FooChild. In it, we call the parent constructor function with the context set to the current object. This allows the name property to be set on the object during creation since that’s what the parent does.
2. Then, we set the prototype property equal to a new object that’s an instance of Foo. This is what allows all of the child objects to have access to the parent’s properties, such as the getName() method.

A few more details

JavaScript provides two special operators for dealing with types and objects. One is called instanceof and the other is typeof. The latter, typeof, is less useful since it only deals with built-in JavaScript types.

The typeof operator returns the current variable’s type, but is limited to predefined types. For example, typeof fooChildObject or typeof fooObject both return a string with the contents of “object”. Thus, differentiating between the two is impossible. More information can be found at the Mozilla Developer Center.

The instanceof operator is more interesting. It takes two arguments and tests whether the first is an instance of the second. (I guess I didn’t need to explain that) For example:

function Foo(name)
{
  this.name = name;
}
Foo.prototype.getName = function()
{
  alert(this.name);
}

function FooChild(childName)
{
  Foo.call(this, 'I am a child of Foo and my name is ' + childName);
}
FooChild.prototype = new Foo('');

var fooObject = new Foo('I am foo');
var fooChildObject = new FooChild('Barbar');

alert(fooChildObject instanceof Foo); // true
alert(fooObject instanceof Foo); // true
alert(fooChildObject instanceof FooChild); // true
alert(fooObject instanceof FooChild); // false;

In the above code, it is clear that fooChildObject is an instance of FooChild, and fooObjectis an instance of Foo. However, fooChildObject is also an instance of Foo, since its type was inherited from it through the prototype property. However, fooObject is not an instance of FooChild since that type is a child of Foo.

I hope I haven’t said “foo” one too many times for you.

More information about instanceof is again available from the excellent Mozilla Developer Center.

Concluding remarks

I hope this has helped you to understand the nature of JavaScript’s built-in inheritance features. I know I found it very convoluted at first, coming from a class-inheritance background. I read everything I could find on the subject, and I believe it’s made me a better JavaScript programmer by understanding some of the “inner workings” of the language. I encourage you to check out some of the references I’ve provided below.

References

1. Prototypal Inheritance in JavaScript - Douglas Crockford
2. The Philosophy of JavaScript - Jesse of 20bits
3. Prototype Inheritance Revisited - Mozilla Developer Center
4. The Employee Example - Mozilla Developer Center

I won’t go into too much detail about the features since I wanted to talk about integrating the Eclipse plugin Mylyn with a Trac setup on Assembla. There can be some issues getting things to work so I’ve outlined what I did to get everything running nicely.

Background: Mylyn

Mylyn is an excellent task-management plugin for the ultimate IDE, Eclipse. I have been trying it out for a variety of things, since I was trying to find something better than just text files for managing various tasks lists. However, Mylyn does much more than just task management as it helps to streamline your work environment with “context”. I haven’t started using these advanced features though, but what really caught my eye was the integration Mylyn offers with various issue-tracking services such as Bugzilla and the aforementioned Trac. This is accomplished by various “connectors”, with each connector being specific to one of the issue-tracking systems.

The Problem: XML-RPC Integration

Integration of Mylyn with Trac allows you to view, create and edit tickets in a Trac repository from within Eclipse. To accomplish this, there are two levels of integration, the first being simple web-based access. This is the more primitive of the two and has been around for longer. Basically, items are still edited from a web browser; the only difference is the web browser is spawned within Eclipse. This isn’t really ideal and doesn’t offer a real integration.

The second uses an XML-RPC interface to send/receive data and thus offers proper integration with the Eclipse environment. However, when trying to connect to my Trac setup on Assembla with this choice, I ran into a lot of intermittent 404 (not found) errors. Basically, synchronization was very flaky and by no means usable.

The Fix

I did some searching and found this page on the Assembla site where other users had experienced the same problem. Scrolling through the comments brought me to this nice fellow’s explanation of the problem, where a screencast was provided showing how it had been fixed.

Basically, these are the steps I did to get Mylyn XML-RPC integration with Trac working.

1. Enable the XML-RPC plugin

   Go to your Trac site, then click on Admin. On the left sidebar go to General > Plugins. There should be a section called TracXMLRPC; click to expand it. You might as well enable RPC access for all of the options provided, though I’m not sure if this is necessary. Here’s a screenshot.

   

2. Enable XML-RPC permissions

   After that, you need to enable permissions for XML-RPC access. Go to General > Permissions on the sidebar. In the “Grant Permissions” area, add a permission for “XML_RPC” for “@editors“. Using “@managers” for the subject might also work/be needed if you’ve setup access for those users. This is the basically what it should be:

   

3. Ensure there is at least one ticket in the system

   For some reason, I had weird errors when trying to synchronize/connect to a Trac repository with no tickets. This was corroborated by the fellow who originally found the solution to this problem. It’s a minor issue though, just click “New Ticket” and create a placeholder.

4. Add Trac to Mylyn

   This step’s simply enough; though some suggestions recommended using http://<domain_name_to_assembla_trac>/<space_url_name>/login/xmlrpc as the URL, I simply used http://<domain_name_to_assembla_trac>/<space_url_name> and it worked fine. Remember to use XML-RPC as your access type or you won’t get proper integration.

   

After that, you should be able to properly connect to your Trac repository using the XML-RPC option of Mylyn. Then, you can finally enjoy proper Trac integration in Eclipse!

You may have run into this particular aspect of JavaScript when working with event handlers. For example:

function alertId()
{
  alert (this.id);
}

document.getElementById('someId').onclick = alertId;

This will return the “id” attribute of the element that the function has been attached to. You could attach the same function to multiple objects and each time you called it on a different object, it would return a different value, since the context is different. (Minor note: using element.attachEvent(), as part of the Microsoft event handler model, does not change the context of the function so “this” will still refer to the window object)

However, there may be times when you want to change the meaning of this without actually having to attach that a function to an object. Using the call() and apply() methods of the Function object can allow you to do this.

Context is everything

Let’s backtrack for a moment. In JavaScript, many (but not all) variables are objects. This includes the references to all functions as well - they are also objects. In the example above, using “alertId” (without the parentheses) would refer to the Function object that represents alertId. As the Function object is a predefined object in JavaScript, it has methods and properties associated with it.

Two of these methods are call() and apply(). Using these methods on a Function object allows you to set the context of that function - that is, what the “this” keyword refers to. The two only in how arguments are passed to the function whose context is being redefined. For example apply() takes an array of arguments like this:

function someFunction(arg1, arg2)
{
  this.id = arg1 + arg2;
}

var arrayOfArguments = ['valueOfArg1', 'valueOfArg2'];

someFunction.apply(objectToBeUsedAsThis, arrayOfArguments);

The values in the second-argument array are then used as the arguments to the someFunction() function.

The call() method is almost the same except it does not take an array of arguments, but rather just an indeterminate number of arguments that are all passed to the function. For example, the above could also be accomplished with this code:

function someFunction(arg1, arg2)
{
  this.id = arg1 + arg2;
}

someFunction.call(objectToBeUsedAsThis, 'valueOfArg1', 'valueOfArg2');

I prefer to use apply() sometimes since you can directly use the arguments variable that is local within all functions. (The variable arguments stores all the arguments that were passed to the function when it was called, and so this can be used in a situation with where it is desired to have a function with a variable number of arguments.)

A useful example

So far, the examples posed have been fairly trivial. Let’s look at a real-world use of call() to illustrate its usefulness. Remember the arguments variable? Basically, you have access to this object variable whenever you’re inside a function since it stores all the arguments passed to this function. However, it’s not exactly an array (although it works like one sometimes) and thus it does not have access to Array methods such as join().

We could easily convert it into an array by accessing each property by its index using a loop, but there’s an easier to way to do this. Consider the following code:

function someFunction()
{
  var argsArray = Array.prototype.slice.call(arguments, 0);
}

Using this one line, we have successfully converted the arguments into a true Array object and stored the result in the argsArray variable. How? First, we access the slice() method on the Array object through the prototype property and then call() the method telling it to use the arguments object as this.

The slice() method allows us to extract a section of an existing array. However, by using call() we are able to apply its effects on the arguments object that is similar to, but not exactly an Array object. The second argument of ‘0′ merely indicates that we want to extract not just a part of arguments but all of it. Since slice() always returns an Array object, we thus get back a true array containing the same data as the arguments object. And that’s it!

Note that the above example could be compacted even further. However, it looks very cryptic and can be confusing. (As if the previous example wasn’t confusing enough!)

function someFunction()
{
  var argsArray = [].slice.call(arguments);
}

This example works the same as the previous one. Instead of using Array.prototype, we create a ‘dummy’ empty array to get access to the slice() method. The second argument of ‘0′ isn’t needed, as if it is left out when using slice() the entire contents will be returned.

Contextual Conclusion

In short, using these methods to change the scope of a function can allow you to do some neat things with JavaScript that aren’t possible in some other languages. However, one should always be mindful to keep code readable and maintainable and to lessen the learning curve for those new to a language.

Some of this may have transferred over to JavaScript, a language that is already poorly understood and often implemented even worse. It is often hard to find well-written, maintainable JavaScript code, as it is often left as an afterthought in a project or otherwise not given much consideration, having been delegated to the realm of popup scripts and mouse-overs. While exception handling may be overkill for a lot of JavaScript applications, many do not even know of JavaScript’s exception-handling capabilities. In this article, I’ll give a brief overview of exception handling and some recommendations on how to use it in JavaScript to improve the readability of code.

Exceptional conditions

I won’t go too in-depth about the merits of using exception handling but will instead just give a brief overview. (While there are some drawbacks, these apply more to the Java language rather than JavaScript)

The main reason for using exceptions is to have a separate channel for communicating errors. Without this, you must communicate error conditions using the function itself. Consider a function that performs mathematical division:

function divide(dividend, divisor)
{
  var quotient = dividend/divisor;
  return quotient;
}

Division is a fairly simple arithmetic operation, but of the four basic operations it is the only one that has limits on its arguments: the divisor (the term you divide by) cannot be zero, since division by zero is undefined. So, how should you handle cases where the supplied arguments result in division by zero? (The situation is very likely in an application accepting user input)

Without using exceptions, you have a few options, each of which has its own weaknesses. Firstly, you could choose not to return anything and just alert() the user of the error. This isn’t good since when you call the divide() function, you expect a result, not a warning message.

Secondly, you could choose to return a special “error code” indicating that there was a division by zero. But this creates another problem - what exactly do you return when something goes wrong? In this case, the only error case is division by zero - since JavaScript is a weakly-typed language, you could just return false on this error, but then in the calling code you’d have to check if divide() equaled false before using it, probably using the strict equality operator. As you can see, things get messy fast.

Alternatively, you could just check the inputs/arguments every time before you called the function. However this is clumsy, and adds another layer of complexity where something could go wrong.

Another way of doing things

As mentioned before, exception handling adds a side channel of sorts strictly for communicating errors. By doing this, it allows for the interruption of program flow for the purpose of dealing with the exception or error situation. Using exceptions, you would re-write the function above like this:

function divide(dividend, divisor)
{
  if (0 == divisor) {
    throw new Error("Bzlorg! Cannot divide by zero.");
  }

  var quotient = dividend/divisor;
  return quotient;
}

Here we are checking if the divisor equals zero - signifying an invalid input value - and then throwing an exception if this is the case. How is this different than returning an error code?

The main difference is in the control flow of the program; using exceptions causes a change in the program flow. In the above example, if the divisor equals zero, the execution of the function stops there and returns to the calling code with the throw exception. The subsequent statements calculating the quotient and returning will not be executed. Here’s an example of how you’d call the divide function.

try {
  var dividend = 3;
  var divisor = 0;

  var quotient = divide(dividend, divisor);

  alert("The answer is " + quotient);
}
catch (e) {
  alert(e.message);
}

With exceptions, you enclose code that could throw an exception with a try block. This signifies to the interpreter (in the case of JavaScript) that you will be executing code (in this case, calling a function) that could throw an exception as a result of some error condition. Thus you are trying to do something - but as in real life, things may go wrong.

In this example, everything works until the line calling divide. Since divide throws an exception with the input values supplied, flow will be directed to the catch block. All try blocks must be followed with a catch block, with the variable in the parentheses specifying the variable to hold the thrown exception object. In the code above, we merely alert the user to the problem - the message “Bzlorg! Cannot divide by zero” is displayed - in a real program you most likely would want to do handle the error differently depending on the context - but that’s a whole different topic.

If, however, you executed the code with valid values and no exceptions were thrown, once the program had got to the end of the try block it would jump over the following catch block and the user would be alerted with the correct answer. Code within a catch block is only executed in the event that an exception is thrown.

Differences with Java

Since Java is an extremely popular language and one that also uses a similar exception handling model, it would be prudent to discuss some of the differences and similarities with it and JavaScript.

1. No multiple catch blocks with JavaScript

   This is perhaps the biggest difference. If you’re familiar with Java you’ll know that different exception objects can be thrown during execution (all subclasses of the root/parent Exception class defined by Java), each signifying different error conditions. You catch each of them separately by using separate catch blocks, each specifying a particular class or parent class. However, with JavaScript, as you might have noticed from the code above, there can only be one catch block and thus there’s no need to specify the exception class.

   If, however, you want the granularity of working with different exception classes, you’ll have to use the instanceof operator within a catch block, like this:

   try {
     ...
   }
   catch (e) {
     if (e instanceof RangeError) {
       ...
     }
     else if (e instanceof TypeError) {
       ...
      }
   }

   It’s not as elegant as having multiple catch blocks, but it’s one way to deal with multiple exception types.

   Correction:

   It appears I was mistaken. In JavaScript, you can indeed have multiple catch blocks, as seen in the Core JavaScript 1.5 Guide from the Mozilla Developer Center. My initial example above is still valid syntactically, but this way may be more appealing. An example is as follows:

   try {
     ...
   }
   catch (e if e instanceof RangeError) {
     ...
   }
   catch (e if e instanceof TypeError) {
     ...
   }
   catch (e) {
     // General catch-all block.
     ...
   }

   It just goes to show that when you think you know something, you probably don’t! This is part of why I like JavaScript (and by extension, programming); there’s always more to learn and experience to be gained.

2. Exception types

   The discussion of exception types brings us to another point - the different exception types in JavaScript. JavaScript defines some built-in exception types, all based off the parent Error object. These should suffice for most situations where you’re checking user input (the most common use), but if you’re developing a complex application you may want to define your own.

   In that situation, things get a little tricky, especially if you’re coming from Java. Despite the outward similarity, JavaScript does not uses classes like Java, but instead uses a prototype-based approach where inheritance comes from existing objects. In this respect, things can get complicated as there are debates on what the best way to inherit from objects is and to that degree, a few JavaScript libraries have been written to facilitate the extending of objects in JavaScript. These points are beyond the scope of this article, but I thought I’d just point you in the right direction.

   Interestingly, you can also throw many different types of expressions, and are not limited to the built-in exception types. For example, throw false; and throw "Hello World"; are valid statements, but in my opinion, it doesn’t make much sense to throw any type of expression just because you can. Using the built-in exception types (or defining your own) is a better practice, though throwing just String expressions might be alright in some situations.

3. Runtime errors

   During execution, you code may trigger runtime errors within JavaScript - for example, when trying to reference a property on a non-existent object. These will also result in a new Error object being thrown, even though you did not define this throw in your code. If this happens within a try block, the exception will subsequently be caught in the following catch block, and if you’re not expecting this error you may miss it. (If, for example, you’re only looking for specific exception object types)

   This can create problems with some of the JavaScript debuggers out there like Firebug. Since the runtime exception is being caught, Firebug will not be able to catch it (it is prevented from “filtering” up), so you may not be able to locate the source of your error if you’re relying on the debugger.

   My recommendation is thus to ensure your code runs properly under normal conditions. Only then should you start using exceptions and try-catch statements. This will ensure that no unexpected runtime exceptions get caught. (The runtime errors are analogous to the unchecked runtime exceptions of Java in that they are not normally caught)

Summing it up

The whole point of using exceptions is not to make your code “work” better - anything that can be accomplished with exceptions can most likely be done without it, with just the same end result. The point is to make your code more readable, manageable and flexible. By using exceptions you get rid of having to use cumbersome “error codes”, the values of which you may forget later. You also get more flexibility with how you handle errors. You need not handle the error right in the function where it occurs - you can throw an exception to the calling code and handle the error there - or, alternatively, you could let the exception bubble up to a higher-level and handle all errors there. It really depends on your needs, but using exceptions allows for this to be implemented more readily.

Though exceptions may seem like overkill for JavaScript and despite the limitations of its exception handling model as compared to that of Java’s, there are still some benefits to using exceptions, especially for complex JavaScript applications that you may implement to improve the interactivity of your site.

Changes/Fixes

• 2007-12-06: Changed throw new Exception(...) to correct statement of throw new Error(...).
• 2008-01-08: Fixed incorrect assertion of “No Multiple Catch Blocks” in JavaScript; added remarks about being able to throw any type of expression.

It’s been a while since Facebook introduced the concept of “applications” to their API, providing developers a very flexible set of tools to create and add features to Facebook itself. Applications on Facebook are best described as “widgets”, since they offer functionality that’s often provided by widgets on other sites, so why Facebook chose a different name is somewhat peculiar.

I’m not going to debate the merits of these applications, or whether they’re leading Facebook down the road to a MySpace-hell dominated by personalized profiles that are an eyesore (there’s already enough discourse on that subject, both on Facebook and outside of it), but rather I’ll take a look at this from a developer’s point of view. What is the potential for developing an application for Facebook, and at the same time, what are the pitfalls?

Pro: Relatively easy to develop

Facebook’s API is easy to work with, especially if you have experience with PHP. One of the official client libraries is written in PHP, and since it’s intended to be used for web applications, this makes perfect sense. Using it to develop an application should therefore be a relatively pain-free process.

While the documentation isn’t always complete, there’s a nice Wiki that covers additional details, and together, these two should allow you to overcome most problems you may run into during development.

Overall, the abilities offered by the API coupled with its ease of use make development relatively straightforward.

Pro: Access to a large user base

Facebook’s current user base of 30 million is rapidly growing. It’s already doubled since the start of this year, and continues to grow at close to 3% per week. If that rate continues, they’ll double again by the end of this year. But perhaps the most amazing fact here is the dedication of Facebook’s user base. It’s one thing to have millions and millions of users, with only a small percentage that are actually active. This isn’t the case with Facebook, which sees over half of its users log in daily. That’s an astonishing statistic by any measure, and even more so when you consider Facebook large and fast-growing user base.

Thus, developing an application for Facebook gives it access to a large, and more importantly, active user base. This gives it a huge potential to grow virally, that is, from person-to-person. When someone adds your application to their profile or account, it will show up as a News Feed item. This means that anyone who has this user as a friend will see a message in their News Feed about this user adding your application. The idea is that they might get interested, click on your application, and then add it to their profile as well, continuing the viral spread cycle.

They can, of course, also find your application by doing a search - if you’re lucky enough to get your application listed in Facebook’s official application directory - more on that later.

Con: Cost and scalability

I think Marc Andreessen (of Netscape fame) put it best when referring to the popularity of an application on Facebook, namely that success kills. (The rest of his article, while lengthy, is an excellent read and I suggest you take the time to read it) Marc gives the example of the iLike application, one of the first, which experienced an insane growth in the early stages. During that time, they grew by 300,000 per day, eating up all of their capacity to the point where they had to buy new servers on a daily basis.

While a company such as iLike, with sources of revenue, may be able to shoulder this kind of burden, it’s quite unlikely that a lone developer would. This creates a sort of Catch-22 - you want your application to become popular, so that you could hopefully monetize it. However, in order for that to happen, you need plenty of resources - which require money.

If all you’re looking to create is a neat little application for you and your friends, or if your application doesn’t really create a huge load on your end, you’ll probably be alright. But be aware that the same dedication and large user base of Facebook that can be so excellent for spreading an application, can be the same environment that quickly overruns your capacity to support your creation.

Con: Monetization

While we’re talking about monetization, it’s worthwhile to point out that if this is your main concern, it’s probably best not to pursue Facebook application development. Since support costs can be high for Facebook applications, attempting to derive a successful business model on this will most likely be met with limited success, if any. Some have called for Facebook to start a revenue sharing program, but this is unlikely, considering Facebook’s uncertain financial future - even if the IPO rumours turn out to be true. (Which they likely will be)

A revenue sharing program, however, would be fair, since by creating a successful application you are adding value to Facebook’s site, and directly increasing their revenues by nature of increasing the time a user spends on the site. I would not, however, hold out on this to develop.

This doesn’t mean that application development is limited to those who just want to create something “for fun” or to add something to their portfolio. On the contrary, I believe the best opportunities the Facebook platform affords is to other businesses based on web services. By utilizing Facebook, they can create applications that promote their site, or tie into their own API, thus using Facebook’s large user base as a source for new customers, users, and thus revenue. Indeed, the first applications developed were made by companies with this very intent. Other sites could follow this model.

Other Cons

Some believe that the viral nature of Facebook apps has been overstated, and that they now don’t spread as easily.

Another, more serious aspect, relates to something I alluded to when I commented on Facebook’s introduction of their Marketplace, a classified-listing type service. It seems that in the TOS of the Facebook Platform, they reserve the right to make a similar application to yours, without obligation to you. I don’t know if this is standard legalese in a TOS for API usage, but certainly it can be construed to be something more sinister, and would deny you any right you had to something you’d created. Of course, if Facebook did do something like this, I’m sure there would be an uproar from the community, with Digg fanning the flames, of course.

Privacy, as always

Privacy is also a concern, as it now not only falls on the user to determine what settings to implement, but also whether developers will respect the TOS of the Facebook Platform. The documentation clearly outlines what user (and user’s friend) info can be stored, but there is nothing to stop a developer from storing more of that information, either for the purposes of adding another feature to their application, or for malicious intent. There have already been concerns about this with popular applications.

The issue of privacy here is that when you sign into a Facebook application, it basically has access to all of the friend info that you would - after all, it probably needs this to perform whatever function it does. Though you may have consented to allow this information to be used, your friends may not have explicitly done this, and may not want their information to be used by 3rd party developers.

Though users can opt-out of participation in the Facebook Platform altogether (and thus prevent 3rd party developers having access), I’m guessing that not everyone or even a majority know about this feature. The privacy settings of Facebook have grown almost as much as the site itself, with settings divided amongst sections and sub-sections, creating somewhat of a convoluted mess. The best precaution to all of this, of course, is not posting anything on the Internet that you wouldn’t want to be known in public. This applies not only to Facebook but other sites as well; I only emphasize this for Facebook because of the notoriety its obtained from such incidents.

I was working on some PHP development recently with my editor of choice, UltraEdit. In my view, UltraEdit is the text editor to use. (Assuming you’re in a Windows environment) It basically has everything I need, and is especially well-suited for web development. Where it may fall short is for developing desktop applications, as then a specific IDE may offer more features, though UltraEdit can be configured to work with compilers and so forth. (UEStudio is probably a better choice in this case)

While I don’t want to argue about the merits of UltraEdit, as people’s passion for their text-editors seem to border on the religious, I wanted to point out a potential solution to a code highlighting problem some of you may have encountered when developing with PHP 5.

Missing functions in the function list

UltraEdit supports code highlighting through its wordfile.txt file, which stores the configuration information for highlighting different languages based on their file extension(s). This file can be found in the directory you installed UltraEdit to, or it can be accessed via the configuration menu. This file determines what language highlighting options show up in the “View As” list. It also allows the function list to display a list of functions/methods in the current file by defining what strings are function declarations.

PHP 5 supports classes and objects better than previous versions. In particular, setting the visibility of members is now supported. So, you can define, for example, methods to be public, protected or private. (The default is public)
However, when using one of these keywords to define a method, the method seemed to disappear from the function list. This was with using UltraEdit 12.10.

Modifying the UltraEdit wordfile file

You need to get the PHP 5 word file and then add it to your word file. Open up wordfile.txt (in UltraEdit, of course!), and delete the entire definition block previously used for PHP. It’ll start at a line of text that begins with:

Lx"PHP"

Where ‘x’ is a number. The end will be just before the next language definition, which will be something like:

L(x+1)"LanguageName"

You need to delete everything starting from the the first line to just before that last line. Then, you can copy and paste in the contents of the PHP 5 word file, changing the first line’s L20 to Lx, where ‘x’ was the number as before. Public, protected and private-declared methods should now show up in the function list.

UltraEdit and Regular Expressions

The UltraEdit word file is actually a bunch of regular expressions that tell UltraEdit which lines are function declarations (among other things) so that it can populate the function list with them. In the past, it would appear that the wordfile doesn’t use Unix-style RegExps but instead uses some sort of UltraEdit format. I don’t know if this behaviour has been changed since then, but looking at the word file, it appears that this is still the case.

You see, UltraEdit has its own style of regular expressions. While you have the option of searching within text files using either UltraEdit’s style, Unix, or Perl-compatible regular expressions, it seems as though the word file language definitions must use UltraEdit-style regular expressions.