zelph.com

Today I release my first reuseable script into the wild. Hopefully it will be found useful and can help other projects move along as well.

Thanks to the new pages function of WordPress 1.5 this will live at it’s own location, so there can be a single point of reference for any changes and such. But I will post any updates made to it here in the blog so that anyone who cares to, will know about it.

I will put the full text from the page here for the initial entry (and for searchability since pages aren’t searchable yet through WordPress), but all future changes will be found on the page itself.

Comments, feedback and suggestions are greatly appreciated.

Information

Script Name: onDOMload
Current version: 1.1
Last Updated: 03.31.2005
Download: onDOMload

Purpose

To allow JavaScript to run on a page after the head, but before onload and before an “at the end of the page” (in-content) JS script fires.

What is it?

This script starts looping trying to run it’s code until the page is done loading. The code is continually checking for certain DOM elements to load from when the functions are called, until an onload call stops it. Using this method, the code you want to run will happen as soon as the loop runs again after a given DOM element with a certain tag/id/class is loaded, not onload or when another in-content JS call is made at the bottom of the page.

How does it work?

You provide two things.

1 - What you want the code to be run on - You can pass an ID (#theID), a class name (div.class), an element name (td) or several, but not all, combinations of the above (div#theID h4).

2 - What code you want to be run - You can pass it any code that you want, as it does an eval on it when it’s time to run it. I know that’s not super efficient, but if anyone can think of something better, please let me know. Since the code can be run multiple times, it provides a keyword of “theTarget” that references the current element being manipulated.

Every X milliseconds the script tries to run your code again, looking for the DOM elements you provided. When it finds one it runs the code on it, and then keeps track of how many it’s done. When the loop happens again it compares how many it did last time, with how many there are now. If there are more then last time, it starts with the next newest one and runs through the rest of them. If it doesn’t find anything new, it keeps looping and checking for new ones each time.

An onload is run that says the page is done loading. It then stops the loops so that they do not continue to run as you are just looking at the page, and does one last run just to make sure nothing showed up between the last loop and the onload.

Why use it?

As mentioned above, until now there have been 2 ways to fire code later on down the page. 1 - onload, which waits until every element (img,script,css,etc) has loaded on a page. If an advertisement, or stat tracking pixel, or whatever hangs for a while… your script can’t fire yet. 2 - “in-content” reference. This is a tad better in that you can call it at the bottom of the page, and it runs as soon as it is read by the browser. This again can potentially be slow if the page is very long, or if something server side hangs the page before it gets to it, but is definitely faster then the onload.

onDOMload allows code to run much sooner during the pageload. If the code you run makes changes to the looks of the page, then this will allow it to happen much faster then the other versions will. It also allows you to keep all your code in one location… at the top. Instead of needing part of your code at the bottom.

History

I had thought of this concept dozens of times, but finally started playing with it after the Man in blue posted about it and gave an example. The need for this became pressing for me when working with a version of IFR which had to wait till the end of the page to do the replacement. We would always see the headlines loading after the page was mostly rendered, and it didn’t look all that great.

I have improved on The Man in Blue’s version (I hope) by adding the ability to run code on elements with a specific class, ID or just on all instances of a given element. An earlier version of the script just had ID and tags available (the unreleased 1.0 version), but I leveraged the code from Alessandro Fulciniti’s Nifty Corners (which are pretty dang nifty, btw) to improve the ability to direct the code. You can also reference the current element by using “theTarg” in the passed code… kind of like a “this” call.

See it in action

Example 1 - Several different types of schedulers on the same page.
Example 2 - Example of how an in-content or onload call can delay your intended actions.

Compatibility

Works fine in FireFox 1.0.1, Win IE 6.0 SP2, Safari 1.0.3 (if anyone has a newer version they can confirm in, please let me know)

Partially works in Mac IE 5.22. I may get this working in the future, but for now it’s not a priority.

Changelog

03.31.2005 - 1.1 - First public release. Fairly decent overhaul from the unreleased 1.0 version. Added ability to go off of classes and IDs. Added final check after onload fires.

1.0 - Never actually released

Comments(4)

In continuing to play with the site (and in anticipation of a few actual articles actually being written) I have installed ShortStat, from the man himself Shaun Inman, so that I get all the spiffy info that comes with it.

My version is located here for all to poke fun at. As usual I couldn’t leave well enough alone and had to fiddle with it a little bit.

In setting it up I noticed I was the only one registering any hits. This is totally understandable as no one visits this site, but that aside, I hated seeing myself inflating the numbers. So I added a new paramater to the configuration.php file that is an array of IP’s that should be ignored. Then in the inc.stats.php file I added a check to see if the current IP was in that array. If not, then it would continue on it’s merry way. If it was, it would skip all the stat taking parts and it would be as if I was never there **queue tumbleweed**.

After testing this for a while I’ll let Shaun know about the concept so he can decide to add it to the actual program or not. Then again, last time I waited to write Shaun about something, he found out about it before I even had the chance to tell him. Sneaky little devil.

Update
After looking at my stats the next morning I was amazed to see 54 or so visitors. I thought that there is no way this could be, and so on further inspection all but like 3 of them were Search Bots, and RSS Aggregators. So I added two more options to the script. Variables to turn tracking of those two things on and off.

countBots - lets Short Stat do it’s normal checks on the User Agent. If it is returned as “Crawler/Search Engine” and this variable is “false”, then the insert doesn’t occur.
countFeeds - If the $res variable has “/feed/” in it (working through a WordPress install, so this won’t be globally true) and this variable is false, then the insert doesn’t occur.

Will continue to add any edits I make, and how things go after they run for awhile.

Comments(4)

Finally made the move to WordPress 1.5. Upgrade went pretty smooth except for a little hiccup with the .htaccess file which made the whole domain show up as a 500 error. Renamed the old one and put in an empty one and all is good.

Installed the del.icio.us integrator plugin which also went extremely smooth.

Will probably be stuck with the default template for a while as life is fairly busy at the moment. On that note, I hope to actually make a few posts in the near future. One or two to explain why I’m busy, and a few more of some projects I’ve been working on.

Until then… TTFN!

Comments(0)