I’ve always liked the concept of the JavaScript prototype property. It wasn’t until my most recent project for AOL, and my journeys in Java and JSP, that I found a real use for it in my day-to-day coding. In the past, I wrote several prototype methods for the foto eBook application. Since then, however, prototypes have felt like more trouble than they’re worth.
The prototype property comes into its own when writing JavaScript in an object oriented manner. Object oriented code structuring is a great practice that Java forces you to adhere to. In PHP, it’s easy to write scripts that aren’t object oriented. Meaning, in PHP, you can get away with not writing classes for specific tasks. This is a bad practice, primarily because the code isn’t being modularized. So a task such as parsing XML isn’t encapsulated. This makes it difficult to reuse the XML parser inside of other projects.
The JavaScript prototype property came to mind when I began writing my second video consumption experience (VCE) for AOL. The first VCE for AOL Music turned out well. It’s a full blown AJAX video application with bells and whistles such as tagging, rating, commenting and related videos. But like any first project, it’s a prototype in and of itself. It need to be finessed and refactored. In the second experience, the TV Video experience, I found myself copy and pasting many of the functions that were written for the music VCE.
In wasn’t just a simple copy and paste though. Functions needed to be renamed, DIV ids that were hard coded needed to be changed. Class names had to be changed. In general is was annoying and tedious work. While copy, pasting and changing, I noticed I was passing 5 or 6 or the same parameters to every function. None of the functions were saving the current state, but the page wasn’t reloading either. The code worked fine, but it looked terrible and was very confusing and hard to read.
When code starts to look like the mess I was dealing with, it’s time to refactor. It was at this point the prototype method started to make sense. In my project, I was passing half a dozen parameters and only one or two was changing following a user event.
For example, the user changes the number of videos per page. Awesome, a user interaction, now what? The application should save the new videos per page to a variable, and request that many videos from the server. Simple. Before refactoring, I was passing in the new videos per page, as well as the show id, the hostname in order to call the server, the current page and a few more items I needed for the callback handler.
If my JavaScript object was saving state more effectively, I would only need to pass the videos per page and grab the rest of the information from an object. Enter the constructor function.
To handle this parameter passing confusion, I wrote a constructor function that took all these constants as parameters. Once I had a contructor, I wrote prototype methods to handle all the different requirements I had. There is a method to get more videos, a method to change the entries per page, a method to refresh the ads, plus much more.
Now I was getting somewhere, I went from passing around the same parameters to a cool constructor with tons of chances to use the sexy ‘this’ keyword. But what about those tricky AJAX calls? What about the call back functions never being called from the proper scope?
For my AJAX calls, I am using the Dojo project. This library has it’s benefits and drawbacks. One drawback I discovered, if used with prototypes the call back handler function is called in the context of the XML response object and not the prototype method that spawned the original AJAX request. I was able to overcome this annoyance by passing an additional property into the Dojo AJAX object called context name. Context name is set to the name of the instantiated object, you know what I mean, the variable you are setting your new contructor object to.
In dojo 0.9, the original request object is available in the returning ioArgs object. Read more about dojo 0.9 io transport here. In the contructor, I pass in the name of the variable in JavaScript for this instantiation of the object.
var hub = new contructor( arg1, argx, "hub");
Now that I know the name of the object, I assign it to the context name I pass with my AJAX call. Now, I am able eval the returning context name and call the appropriate method in the correct scope.
eval(ioArgs.args.contextName).updatePageMethod();
By doing this, the JavaScript becomes a blueprint for how the page should work. Basically, I am able to remove references to the object name. So anyone who needs a video hub should be able to grab my new JavaScript blueprint, instantiate a version on their page and bam, a working VCE.
In a shop that practices agile development, refactoring code in this manner is often difficult to justify, but as I found myself reusing code from one project to the next, it became obvious that my JavaScript code base wasn’t disposable. I wanted to make it easier to reuse the same file on the movies project, or whatever site wants to add a VCE.
I learned a tremendous amount about object oriented JavaScript in this Site Point article, also, this article from XML.com has some great thoughts on building OO Javascript. Once the television project launches in early 2008, I’ll post links to the JavaScript files.
Update:
The AOL Television Video Consumption Experience (VCE) launched a few months back. As promised, here are links to the JS files I authored. I have since left AOL and I’m not entirely sure if changes have been made to these files, but here they are anyway. It looks likes some code snippets have been dumped into this file, for that I apologize, but I no longer own the project.
