James Gregory

This is a very old post. Please, stop reading and just download jQuery.

As I said I would be in my previous post, I’ve been working on improving getNextElement. I’ve improved the overall performance of the function and also created a few others with similar purpose; including the sister function getPrevious element. I outline all the functions and their uses below; you can find the download link at the top and bottom of this post.

Any bugs anyone finds don’t fret to email me or post a comment here, i’ll work on fixing them asap.

I’ve been playing with the prototype framework for a while now and am very impressed, the file size is a bit of a down point but that aside it’s excellent.

The one thing that has slightly irritated me (and others it seems) is that there isn’t a stop function built into the PeriodicalExecuter object. Seems something strangly simple to miss out, especially as the Ajax.PeriodicalUpdater has one built in. With that in mind I’ve made an extension my self to perform this function.

I’ve simply placed the following code in a prototype-extensions.js file and referenced it wherever needed.

PeriodicalExecuter.prototype.registerCallback = function() {
  this.intervalID = setInterval(this.onTimerEvent.bind(this), this.frequency * 1000);
}

PeriodicalExecuter.prototype.stop = function() {
  clearInterval(this.intervalID);
}

There’s really nothing much going on in this code, all it does is take the current registerCallback function (which creates the actual timer) and stores its returned interval ID which we then use in the new stop function with the native clearInterval method.

Here’s an example implementation where I fire the PeriodicalExecuter when a key is released in a text box and then stop it once the call completes, this was the main reason I created this extension, my aim was to have a waiting period of a few seconds before a ajax lookup is performed; mainly to cut down on server calls. Each time the textbox changes the PeriodicalExecuter gets reset and started again which means the function will only ever fire once the countdown is complete.

<input type="text" id="changer" />
<script type="text/javascript">
  var pe;

  $('changer').onkeyup = function() {
    if (pe) pe.stop();
    pe = new PeriodicalExecuter(textChange, 5);
  }

  function textChange() {
    alert('check textbox content against database here');
    pe.stop();
  }
</script>

One of my colleagues was having a problem with a datagrid nested in a repeater. We’ve done this kind of thing before with no problems, but this time the dataset wasn’t allowing key access to columns (i.e Container.DataItem("ID")). We toiled for quite some time trying to figure out why, with no avail. Eventually we just ended up using the direct index of the column; which worked fine as long as we didn’t change the column ordering.

You’ve seen the title; it’s true.

I’ve been running an “administration” query to modify a table with around 190,000 records in. This table, segments, contains a status column called Coded. This value is derived from another table, faults. If any faults belonging to a segment has a coded status of 0 then the segment coded value is also 0.

My query did an update on each row in the segments table, retrieving a count of how many faults there are with a coded status of 0 that belong to the current segment. If the count is greater than 0 then the segment coded is set to 0, otherwise to 1.

It ran for over 2 hours without any sign of finishing.

I changed the query to do a simple case statement with an exists on the faults table where Coded = 0 and it’s just finished in 4 minutes. Unbelievable.

The web has come a long way in the past few years, but it is still hindered greatly by the methodology of the “previous generation” of web-designers. People are still designing with the mentality of serving everyone with a page that is specifically tailored to suit their particular browser and operating system. While this did get the job done originally, it was most certainly a lot more work than it needed to be. That’s why I find the idea of generating one (and only one) document to serve all users very interesting. Most browsers are conforming to standards in some way shape or form, the majority support CSS2 and XHTML 1.1 and the ones that don’t (mostly) degrade gracefully. It’s no longer about serving a page that is pixel perfect on every system; it’s about making sure all users get a good experience from your site.

Another branch of this takes the form of Accessibility. Accessibility has recently been highlighted by governments as a priority for websites; the US and UK both have their own take on the situation with relating laws and amendments. It basically boils down to any website that is providing a service should have a bare minimum of accessibility; otherwise they are discriminating against their less able customers. This means businesses are required, by law, to provide for all their customers (whether or not they have disabilities). Just as you would expect a shop to provide wheelchair ramps for disabled shoppers, you should expect pages to be designed to aid disabled web-users.

Recently I equipped my self with a screen-reader (JAWS) and was appalled — but not particularly shocked — at the amount of sites that are simply unusable with anything other than a standard browser. Most pages are so full of invalid markup that the screen-readers simply mumble on continuously and any actual content is undecipherable. If websites complied to the standards then their experience would be tolerable at the very least. Unfortunately the majority of website designers simply do not know (or often care) about creating accessible pages.

Note: Screen-readers, for those that don’t know, take a web page and read it out using a synthesised voice. A perfectly accessible site would read the same as a printed document.

One of the largest problems with the way pages have been designed in the past has been using the supplied tags for their appearance rather than their actual purpose. The <b> tags have been used to create bold headings, the <font> tags used to change styles of fonts and worst of all the <table> tags for layout. This means when a screen reader parses these pages it emphasises the wrong words and spouts nonsense when encountering these convoluted tags. What a properly designed page would have is a distinct separation of content and layout, of HTML and CSS. The HTML document should use be structured like a standard plain text print document; with appropriate headings, sub-headings, lists and paragraphs. These tags can then be styled using CSS to any manner to which they like. So when a screen reader encounters this page it reads the unstyled version; a perfectly formed document.

That’s the end of my little rant, maybe together we learned something.