The Problem: Calling a function many times throughout a particular JavaScript file or block.
JavaScript is often used to manipulate a variety of HTML objects on a page, i.e. to “show” or “hide” them, or perform some type of toggled functionality on a variety of buttons, divs, etc. It is not uncommon to see code like this littered in a variety of places throughout a typical large Script block:
if(foo == bar){document.getElementById("blah").style.visibility="block";document.getElementById("blue).style.visibility="none";document.getElementById("red").style.visibility="block";document.getElementById("black").style.visibility="none";}Implementing the above in numerous places throughout said block of Script with a couple of hundred lines can eat up a lot of space, be harder than all get out to maintain, and if the guy that wrote it gets hit by a bus, you can often watch the next engineer in line cry for days in front of their screen just trying to figure out what the original coder was thinking when they wrote it.
This usually happens when your team begins to look at performance and realizes that 80% of what happens to the user is on the Client-side. A typical scenario involves JavaScript files that have been developed and built over time with very little attention paid to maintainability or even long life.
While standard libraries are solving many of these problems, they may be too bulky, or in most cases, invoking them would involve a total rewrite of the scripts and pages involved. As a Best Practice, it’s probably better to “evolve” your way to more standards-based solutions; creating your own methods is a good way to simplify what you currently have and allows your team to evaluate how far you really need to go with any changes.
Cleaning up what is currently there is the first step. Wouldn’t it be great that once you had a “handle to an element”, you could just write “changeVisiblilty(“block”) instead of having to iterate out “document.Element.style.display=’block’; ” time and time again?
Of course with the example code snip at the top, you could create arrays and iterate through them based upon their common modes — possibly create different versions of JavaScript objects and vary their values that way, but somewhere along the line the “document.Element.style.visiblity= ‘block’; ” gets written out, usually quite a bit.
Using the “prototype” keyword to extend functionality of JavaScript objects.
Prototype (not to be confused with the “Prototype Library”) was introduced to JavaScript beginning with the 1.1 release. It is a “prebuilt” object, and it is used to extend existing Objects with custom properties and methods, similar to extending Classes in Java. It is probably one of the most powerful objects that you can work with when refactoring existing legacy code into more manageable chunks.
The prototype keyword will allow the addition of custom properties and methods to all the existing objects of a particular JavaScript Object (String, Array, Element or your own Custom class). To implement this, just append “.prototype.” to the Object that you wish to extend, then name the method/function that you’ll be making available to all of these objects:
/* Extends Element functionality by switching the display to an inserted variable */Element.prototype.changeStyleDisplay = function(strVal) { this.style.display = strVal;}Now you have a new method “changeStyleDisplay(‘value’)” available to you on the Element object only. It can be used thus:
document.getElementById("foo").changeStyleDisiplay("none");Which changes the “display” attribute value to “none”. This Doc containing HTML file with JavaScript prototype implementation, contains a test that I created to toggle different visibility modes with two different method extensions of the Element Object. Feel free to copy, hack, change, use, and enjoy.
(note that is probably doesn’t work in IE — Will be testing to find out if newer versions will work. As Usual, MS just goes their own way….)
This would be a great idea!, but unfortunately it doesn’t work.
Well, it does, in all browsers except Internet Explorer.
View and track the (IE bug 186) details here.
http://webbugtrack.blogspot.com/2007/08/bug-186-cant-prototype-on-htmlelements.html
Well, that just blows. I’ll do some more testing with my group. Thanks for the note! Almost everyone is developing on Mac/Safari/Firefox… Gotta test this one…