Posts Tagged ‘JavaScript’
I finally put together a page to host my articles published in JSMag for those of you who might have missed them. The articles, titled “Roll Your Own” and dealing with the proposition of creating a custom JavaScript library from scratch, will run about a month or so behind the magazine’s releases so if you like the columns go pick up the current issue here.
The other day I forked the excellent javascript-tools Textmate bundle in order to add Douglas Crockford’s JSLint as an option to go along with JavaScriptLint and the Closure Compiler. You can find it here. I want to look at using Safari’s compiler in order to alleviate the Rhino dependancy, ad possibly include the newest jslint.js with a config file but, unfortunately, don’t have time at the moment. I will soon, but until then this early version at least fits in functionally and aesthetically with the rest of the bundle. Rhino is expected to be installed, as well as jslint,js to be located in ‘~/Library/JSLint’.
The enterprising can just open the bundle contents and hack away at the dclint.rb file to change any paths or dependencies. Hey look, screenshots!
Added entry into the lint options menu
Fits into the bundle aesthetics
Quick example of a header section of a web page that contains a few form elements done with RML:
I’m using it here in a larger object literal method which can be called with a refinement like so:
Get the code at github or here on the RML page. I’ll post more later this week…
I am going to blog more in depth this weekend about this little markup generating JavaScript that I’m working on. I know there are others, but what fun is that? Basically, RML will generate tag-based markup like HTML and XML from JavaScript. I have been using it for templating alone and within a larger Ext.js application with pleasing results. I just need to add more tag shortcuts to the object, but it is very usable now. Get it here or at my github repo.
Just a quick post about integrating JSLint with Vim on a Windows XP machine. I had posted awhile back about integrating JavascriptLint with Vim on XP, but while re-reading The Good Parts I got the urge to revisit JSLint just to revel in the Crockfordness of it all…
First off, get Jesse Hallett’s excellent jslint.vim plugin here. I installed this on my Fedora box without a hitch (well, the only hitch was figuring out the name of the Spidermonkey package for Fedora 12, ‘js-devel’ I believe it was) but my work XP machine would spit this out when attempting a :jslint command:
It’s obvious that some paths (literally, figuratively) were getting crossed somewhere (*Note you may also want to attempt to use cscript from the command line just to make sure it is, in fact, installed and working. I did, and mine was*.)
In my experience the first place to check for errors with Vim plugins is the PATH so I opened up Jesse’s plugin and focused on this section (lines 41-59 on his github repo version):
Here’s the version I ended up with after experimenting for awhile:
So, I ended up changing 3 things:
First, since we know this is for XP, the tests for Win32, Mac and ‘Nix are not needed. Second, there are more compact and portable ways to specify this path, but posting it this way makes it easy to adapt to your system path. Third, On my XP system my .vimrc is actually _vimrc and I keep it here in the vimfiles directory so it made sense to me to do the same with a jslintrc.
Speaking of the _jslintrc, it looks like the ‘fulljslint.js’ file is updated quite a bit on the jslint.com website, and allows for more options in the jslintrc file. I need to experiment with that next
I want to post a quick bit here about three methods I use in the X library which make use of element classnames. First a method to detect if an element has a given class:
Breaking that down, you have the function taking two arguments. One, the element to check for the presence of the class name and two, the class name itself. Next, a RegEx is defined which will attempt to match the class name you passed in. The RexEx itself is made so that a portion of a string can be matched because of the way that classnames are applied to elements on the DOM, i.e. “spam eggs vikings”. Last, the ternary (return pattern.test…) executes depending on what the test() method returns. Remember, test() is a function of the RegEx object which returns a bool depending on a positive(or lack of) match. Test() is going to return a ‘true’ of the class name is found, ‘false’ if not.If you are unfamiliar with ternary operators, let’s explain by looking at what an if/else doing the same thing would look like.
That works, but it’s not the lean and mean js machine we are going for here. Now, the one line of the ternary:
And it works like this:
an action -something to evaluate- ? do if true : do if false
So, in practice you could check if an element had a class name by calling:
hasClass is going to return a Bool though, so usually you will use it as part of an expression:
I rarely use hasClass outright, but the next function does.
To add a class to a single element or a collection of elements we have this:
In Summary, addClass takes 2 arguments, an element and a class name, checks to see if the element passed in is a single element or a collection of elements, then checks the element(s) to see if they have the passed in class name (via hasClass). If not, element is then checked for the presence of any other classes. Why? If there is another class name already assigned to the element(s) you need to insert a space in front of the new class being appended. Finally the class name you passed in is appended (as long as it’s not already there) and the element is returned. Let’s combine the get method with this in a couple of practical examples:
Say you have an HTML page with these four divs contained in a fifth div:
And maybe some styles to go with them:
So, on a goofy little test page you might have this:
Classless divs
Giving you this:
Now with some class (green to be exact)
Breaking that expression down, recall that the get method will allow you to pass in a ‘context’ to restrain searching. Because I only wanted the divs inside of the div with the id of “stripes” I passed it (‘#stripes’) in along with the search for the generic ‘div’ tagname:
You can break this up into 2 expressions if you want:
After getting the elements, I sent them to addClass. If you used the more verbose code above you would have:
In these examples the fact that addClass returns the element passed in is of no consequence. JavaScript functions always return a value, even if one is not specified (undefined in that case), so specifying element as the return value could just be ignored, but we are going to use it next to combine with removeClass.
Here is that removeClass function:
Before doing something pedestrian like just removing the ‘green’ classnames from the divs inside of ‘stripes’ let’s swing for the fence and remove the classnames, then add new ones all in one go. weeee!:
Now that test page would look like:
Class changed to 'slate'
This works because of the fact that addClass is returning the element list containing all of the divs we want removeClass to operate on. If you look close you’ll notice that all you needed to do was to take the previous expression we used for adding the green classes at once:
and wrapping it with the removeClass call:
There’s more to breakdown, but not too much. The removeClass function just uses the same methodology that addClass does for checking if element is an array-like object (has a length?) then looks for the passed in classname with a RegExp which will replace a match with an empty string using the ‘$1′ backreference (the second call to replace makes sure no whitespace is left over). Finally the element is returned, just like addClass. And, yes, you could invert the order to addClass(removeClass()), it doesn’t matter
All of these examples could have, obviously, been used on single elements. X.get, X.addClass and X.removeClass will take care of that for you. So if you wanted to change the second div back to green you would go:
Notice there is no need to specify a context when using an id (it should be unique).
I’ve spent a couple of days lately coding against the Microsoft Bing maps api at work. I just put together a little method this morning to mimic .Net’s ‘Request.Querystring’ functionality because I am needing to grab either a zip code or a latitude/longitude from the URL. The function, named requestQueryString(), expects a string to be passed in which should be a ‘key’ part in one of the key:value pairs located in the url of the page being viewed. In other words, if the URL is
the ‘keys’ are ‘zip’, ‘lat’ and ‘lon’, while the values are ’85226′, ’33.372154′ and ‘-111.754322′. To fetch the value associated with zip you would do:
This will return ’85226′ given the previous URL. For ‘lat’ or ‘lon’ it would be pretty much the same:
Here is the method itself. I’ll update the x.js page with the new code as well.
It’s an early implementation and a couple of things are worth noting. I had an issue with whitespace because I get the lat/lon numbers from a webservice maintained elsewhere in my company, and elsewhere is not properly constraining the input. You could remove this:
if you know that whitespace will not be an issue. Leaving it in place doesn’t add much of any overhead as the split command will just do nothing as it won’t see any ‘%’.
Now that we have a shiny new object created called ‘X’, Let’s use it. I like to organize all of my JavaScripts by incorporating object literals (see Rebecca Murphey’s talk on the closely related object lateral [that's a joke btw, it was a misprint at jconf], the excellent book Simply Javascript, and of course The Good Parts ). Here’s a ‘stub’ for the objects we could use:
I will typically use the ObjectName.cache{} to hold a snapshot of the page, or areas of the page that I don’t want to have to re-query the DOM for. If my page is not going to change via AJAX I can store fetched results there for further use/manipulation. The ObjectName.config{} has the same functionality as .cache{}, it’s just my way of seperating out more important info than the generic .cache{}. You could use one, both, or neither, really just a matter of taste.
For this to be of use we need a way to load it once the dom is ready. Let’s add a ‘ready’ type event to the X library then:
You’ll pass your object literal to the .go() method which will, after the page has loaded, call the init() method of the object you passed to it:
Where this goes depends on how you are constructing your site. For now, we’ll put this line just below each object literal created. Later we’ll look at a site-wide answer to automating the loading of scripts, see Paul Irish’s blogs for more on that…
With a way to bind event handlers, object literals to hold the handlers, and a method to load the scripts, now we can just write some really basic JavaScript to utilize this stuff. So maybe there’s a button that lives on a page:
We need to set an event handler on that button to fire when the user clicks it. In the init() function of objectName do something like:
I’ll get to the ‘doClick’ function in a moment. First, I want to write myself a convenience method to shorten the verbosity of adding event handlers. This is optional, of course.
Now, with the convenience method added to the X library we can revisit what we wrote earlier:
That’s getting better, but we can combine those 2 statements down to:
I am using a ‘$’ as a sigil in front of the name of the convenience methods throughout ‘X’. I do this to keep any conflicts with keywords like ‘submit’, ‘blur’ or ‘focus’ from happening. Plus all the cool kids are using $…
OK, so about the doClick handler. Remember that X.addEventHandler takes a target element, an event, and a function to call when that event happens on that element. The doClick function call is in object literal notation here, it is an attribute of the object you have made. I’ve been using ObjectName as the object so far (the observant among you may have noticed that the file is objectName.js. I do this in the development phase of a project as I will usually have many separate objects, all of them their own individual .js files. So objectName.js will have one object defined in it, ObjectName. At deploy time, I’ll combine them into one .js file and minify it). ObjectName will have this named function as an attribute:
The event handler calls ObjectName.doClick() because you bound it to that element. Here’s the whole object then:
Don’t forget to include the call to the go() method, outside of the variable which passes in ObjectName and tells the browser to call ObjectName’s init() method when the DOM fires the ‘load’ event. The cool thing about an object like this is re-usability. If your site was littered with buttons which needed to say “Hi” when pressed (it could happen) you would only need to attach this object to a master page and it would attach the event to any button with an id of “say-hi”. Now, it is an id so there should only be one per page. If there are going to be multiple instances per page, use a class instead, and iterate over the nodelist that get returns with a for loop to attach events. Assuming there are multiple buttons on the page with a class=”say-hi” attribute you would do:
with this you wouldn’t have to worry about the number of elements with a class of “say-hi”, as all of them would be fitted with a click event handler that will call ObjectName.doClick(). Note the use of the config object which is an attribute of ObjectName. You can manipulate this attribute if you wanted, changing it during the page lifecycle, like say adding a toggle-type command in the doClick() function:
Now the alert will alternate between “Hi!” and “Hi Again!”. Silly, but you get the idea.
Next, we’ll do a continuation of the object literal using more of the config and cache functionality, I need to get away from this keyboard now!
Before moving into the construction of object literals, which is my preferred method of organizing my scripts, I want to take a post to discuss the get() method in the X library. The functionality the get() method provides is as follows:
Pretty straightforward yes? To save on the typing, let’s construct the method so that a search for an element use the css selectors ‘#’ for id, and ‘.’(a period) for class like so:
will return an element with id=”spam”, and to fetch all elements with class=”eggs” you would use:
Finally a tag name search would just require the name of the tag:
This would return a node list of all div tags on the page. The use of a context argument:
You could just pass the function as well:
You get the idea…
Here’s the code for the method:
A selector is gotten by slicing off the first ‘letter’ of the passed in identifier. The switch statement looks at that selector to decide what query to pursue. The root of the query is assigned as document by default (resulting in document.getElement….) or reassigned as the passed in context if one was passed. The getElementById query (‘#…) checks first for the newer w3 querySelector() support which is present in the newest versions of most browsers (including IE8 to some degree), then falls back to the old standard if false. The search by class name is slightly more complex only because there was no standard DOM method to query by class until querySelectorAll() (which, again, is only in the newest of browser versions). When this segment of the case is entered a quick IE vs standards check is conducted (IE will use document.all) and if no querySelectorAll() support is present the 2 arrays created and the RegExp are used to:
gotArray is then returned. The last piece of the switch, fetch by tag name, is as simple as ID querying because of the presence of the native DOM method getElementsByTagName(). Again used as a fall back here in the case of no querySelectorAll().
I think thats a good enough explanation of this method moving into the next post…
Picking up where I left off in ‘Hacking together’, which we’ll now call Pt.1, Let’s look at the entirety of the addEvents section of the library in browsers which aren’t named IE…
Now to address the IE events model and the (hopefully) soon-to-be-a-thing-of-the-past memory leak issue. If we stroll back in time to 2005 there was a contest held over at Quirksmode for a JavaScript solution to the addEvent challenge. The winner was (to no great suprise) John Resig. That entire post saga is required reading imho. One of the judges of the contest, Dean Edwards wrote this solution, from which I am using a slightly modified version.
IE has a serious flaw if not corrected: When your attached function gets fired, the ‘this’ reference refers to the worthless ‘window’, when, in fact, it should refer to the parent object (I think I’m paraphrasing J.Resig there). This code addresses that by creating a hash table of event handlers with unique ids bound to your target element, assigning a ‘handleEvent’ method to be called when your event fires. This passes the object correctly and maintains scope (this). You should walk through this series of methods with IE’s developer tools JavaScript debugger, which is the best way to see how this works in real-time. Then there is a removeEventHandler to allow assigned handlers to be removed (more on that in a moment), as well as IE methods for preventing default behavior and stopping event propagation.
So, back to removeEvent and the IE memory leak possibility. This code does not use attachEvent() to handle events, which unless I am mistaken was the biggest problem with IE’s memory manager understanding which event handlers could be reclaimed by the garbage collector. See Douglas Crockford’s post here. Admittedly, this little portion of a discussion on the IE memory leak issue is a tiny drop in one seriously big-assed ocean. There is so much material out there on this subject alone you could get lost in it. I don’t really want to go down that path any further here. We’ll bind events without attachEvent, we’ll set a removeEvent handler on the events we bind and we’ll move on. A real solution would be don’t use IE, but I digress…
I have made a seperate page on the blog called ‘x.js’ for the code so far. Next I want to go into using object literals as a way to organize your code which will use the X library and some syntactic sugar to make for less verbose script, until then…
Follow me!
