Category Archives: AJAX

How to use custom element attributes in JQuery

Have a look at the following snippet of very basic HTML.

<input type="button" class="my_button" value="Submit" product_id="1234">

You’ll recognise this as a FORM button, with a value of “Submit” and a DOM element class of “my_button”.

Nothing strange in that. But what’s this 3rd attribute in the element, “product_id”? That’s not a valid HTML attribute, is it?

No, its not. Its a custom attribute that I’ve added. It could be anything, and it will have no impact on the output of the button in the browser.

So why add it?

Custom HTML attributes, blended with a Javascript Framework like JQuery, are an excellent way to develop fluid UIs in web applications.

Let’s use the above example. Let’s say we have a list of products in a shopping cart application, and we want to give the user the option to add products to a cart, but we want to do this with AJAX, so we don’t have to refresh the page each time.

Our web application renders the list of products, each with a Submit button that has a custom HTML attribute “product_id” with a value of the product’s catalogue ID.

So, in our Javascript, we use JQuery to trigger our required Javascript when the document loads. Standard stuff.

$(document).ready(js_Init);

In our initialisation function, we then attach another function, js_addToCart(), to the Click event on any element with class, “my_button”.

function js_Init() {
	$(".my_button").live("click", function(event) {
                  js_addToCart($(this).attr("product_id"));
        });
}

Now, notice the argument that we pass to this function.

Its a JQuery object first and foremost, that is, the element on which the Click event occurred. The argument we want is the value of the attribute of that element called “product_id”.

Our js_addToCart() function now has the catalogue ID of the product the user wants to add to their cart, which we can process with JQuery without ever having to do a FORM submission.

You can add as many custom attributes to an element as you wish, and pass as many of this back to JQuery as you wish, which means you should never really have to use a HTML form again.

Facebook Apps and the Same Origin Policy

Over recent months, Facebook have become a lot stricter in relation to the use of secure URLs for applications presented in the App Canvas and on Page Tabs.

The bottom line in this is that you need to serve your Facebook application content from a secure (https) URL. You can have your app set up to serve on both http and https, but if  you don’t have this https set up correctly, any Facebook user who has Secure Browsing switched on will not be able to use your application.

My reaction to this was to convert all my applications to use https for all connectivity, so as to remove any uncertainty in this regard.

I figured that the users browser would just communicate with my web server over https, regardless of whether the Facebook use was using Secure Browsing or not.

However, there is a big problem with this if you use AJAX calls in your application.

I had set up all my AJAX calls to use https, but if the viewing Facebook user isn’t using Secure Browsing (ie they are connecting to your application over http), you are going to fall foul of Browser restrictions arising from the Same Origin Policy.

This policy is designed to prevent XSS attacks, in that it prevents Javascript from making calls to URLs domains that are not the same as the URL domain the user is viewing. Crucially, this includes the protocol which is used.

That means that if your Facebook user is connecting to http://facebook.nightbluefruit.com for general application content, and the application makes an AJAX call to https://facebook.nightbluefruit.com, the browser will send the request but will refuse to receive the response.

To overcome this, you should really set up your AJAX URLs based on the protocol used to connect to your application. You can use the $_SERVER['HTTPS'] special variable to do this.

AJAX Character Encoding in Internet Explorer

Is there no end to the woes of IE?

I’ve just spent 3 hours trying to find out why IE 7 won’t encode my form inputs in UTF-8 before sending them off in an XMLHttpRequest package to my server.

Here’s what is supposed to happen:

I send the page to the browser with UTF-8 character encoding, so the browser is supposed to use this encoding in whatever it does.

This is fine when sending form inputs back to the server with a straight-forward FORM Action routine, but when you use XMLHttpRequest in IE7, IE7 insists on sending the form input in ISO-8859-1.

So if someone enters Ø in one of my form inputs, IE7 sends this off to the server as ‘\xd8′ rather than as ‘%C3%98′ as it should.

The result is that garbage goes into my DB which then invalidates any XML that uses that garbage.

Thankfully, I found a solution.

When I take the form input value from my DOM, I pass it through the Javascript encodeURIComponent function before passing it to the XMLHttpRequest object.

var new_value = document.getElementById(“text_input”).value;
//CONVERT FORM INPUT TO UTF-8 FOR IE 7
new_value = encodeURIComponent(new_value);

XMLHttpRequest is supposed to use UTF-8 by default. There may be something wrong with my set up, but for the life of me I couldn’t get it to use UTF-8 (I’ve checked all my HTTP headers and everything is UTF-8; my server also uses UTF-8 by default, and everything works fine in FF) so this was the only solution that worked.

Another day lost to IE7.

Grrrrr.

Parsing the attributes of XML elements

PHP 5.0 contains some excellent functions for parsing XML into arrays and objects, but that isn’t much good to you if you have to used PHP 4.0.

That said, it is relatively straightforward to extract the data from between XML tags in PHP 4.0, but the particular problem I came across was having to extract attribute values from the tags themselves. This arose in relation to exchange rate data published by the ECB, which you can view here:

http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml

As you can see, the data we really want (the exchange rate and currency name) is an attribute value rather than raw data between the tags.

Anyway, to get at this data you need to look at the $attrs associative array that is passed to whatever ‘start element’ function you are using. This will work (CUBE is the tagname we want in the ECB feed):

function startElement($parser, $name, $attrs) {
global $insidecube, $tag;

if ($insidecube) {
$tag = $name;
} elseif ($name == “CUBE”) {
foreach ( $attrs as $name => $value ) {
echo $name . ” ” . $value . “\n”;
}
$insidecube = true;
}

}

This just prints the attribute keys and values on your screen, but you get the idea.