If you’ve ever explored sorting tables, you might’ve come across a nice little library called sorttable. It’s functional, lightweight, and easy to add to just about any table.

If you’ve got a table with alternating colors for the rows, this little library will mess that up for you. From the looks of the results in the bug tracker, it appears that creating a remedy to this issue is a high priority, but can be difficult depending on how the background was applied. Well, if you’ve used proper CSS, then hopefully you’re using class names to apply your alternating background colors. If that’s the case, an easy fix is to add a couple of additional lines of code to the original source.

Look for this section:

tb = this.sorttable_tbody;
for (var j=0; j<row_array.length; j++) {

This is where we’re going through our loop of sorted elements and putting them on the table. Here’s our chance to apply alternating class names so we can keep our table rows looking nice. Just add the following in the for loop:

if (j % 2 == 0) {
   row_array[j][1].className = 'class_with_bg';
} else {
   row_array[j][1].className = 'class_with_other_bg';
}

…and voila!

I hope you enjoyed this post. If you did, consider subscribing to my feed.

While doing some programming I came across an interesting predicament. While I understand it’s evil to make it hard for a user to leave a page, I’m not here to argue the merits (or lack thereof) of onbeforeunload.

On a particular form, we are forcing the browser to not cache the information to avoid potential AJAX/JavaScript problems if they should leave the form and come back as browsers don’t all act the same (eg IE leaves checkboxes checked but doesn’t remember changes that have occurred to the page due to JavaScript). As such, we warn our users when they’re about to leave the order form to let them know they’ll need to fill it in again.

The function was simple enough:

window.onbeforeunload = function () {
    return "You are about to leave this order form. You will lose any information...";
}

Unfortunately, this would also be triggered if the user submitted the form which, is obviously not what we want. After searching around on the Internet I came across a simple solution that I thought I would share:

// Create a variable that can be set upon form submission
var submitFormOkay = false;
window.onbeforeunload = function () {
    if (!submitFormOkay) {
        return "You are about to leave this order form. You will lose any information...";
    }
}

Since onclick appears to register before onsubmit when clicking a submit button, we can add a little variable declaration to our submit button so that submitFormOkay will be set to true before the form submission happens:

<input type="submit" id="submit_button" onclick="submitFormOkay = true;">

Problem solved! I hope this post can help others solve the same issue in the future.

If you liked this post, then please consider subscribing to my feed.

If you’re having issues with getting some AJAX to work in Chrome or the newer Safari versions, then I hope this post will hope you.

This issue arose when one of our designers was testing some of the new AJAX I had written in Chrome. It worked fine in Firefox and IE, but Chrome was choking on the XML that was coming back. Treating it as though it were equal to null and alerting the appropriate response that is written in to our AJAX JavaScript. A bit more testing revealed that Safari was also having the issue. Once we figured that out, it became evident that searching for issues with WebKit would help.

Both browsers use the WebKit application framework. Because of this, they both enforce (choke) on XHTML that is given to them which does not follow the standards of XHTML. One of these standards, is that virtually all HTML entities are not valid. Here are the three that are:

 
<
&rt;

All other html entities need to be converted to their XML-safe (ASCII) form. So:

˜ = ñ

This can mess up AJAX that works in Internet Explorer and Firefox because they don’t mind dealing with XHTML coming back from an AJAX response with HTML entities. If you’re passing complicated strings with any entities in it through your AJAX requests, don’t expect them to work with any of the browsers using the current WebKit framework.

It took me a while to figure out what was causing the issue that our testers were experiencing, but once we did some searching, we found that others have talked about having this, or a similar problem, too.

We had experienced an issue with foreign characters creating improper RSS feeds for the same reason: html entities showing up when they shouldn’t be. I researched and wrote a function then that would convert all the HTML entities to their numeric format that would be safe. I applied this function to the AJAX responses coming back and presto, it worked.

So, I thought I would share this function with everyone in case someone else was having a similar problem:

function clean_string_for_valid_xml($string) {
    $entities_array = array();
    foreach (get_html_translation_table(HTML_ENTITIES, ENT_QUOTES) as $character => $entity) {
        $entities_array[$entity] = '&#' . ord($character) . ';';
    }
    return str_replace(array_keys($entities_array), $entities_array, $string);
}

Basically, we’re using the get_html_translation_table function to grab all of the entities. Then, we’re using the ord function to get the ASCII value for those entities. Then, we’re returning our string with the entities properly replaced.

Hopefully this works for you, or at least leads you to an answer that works for you.

If you liked this post, then please consider subscribing to my feed.