Monday, July 24th, 2006

XMLHttpRequest Quirks and PHP

Category: PHP, XmlHttpRequest

On his blog, Jacob Santos has written up two simple “gotchas” that he’s come across in his PHP/XMLHttpRequest adventures and wanted to share with other developers forging their way through the same experience.

I didn’t find the AJAX frameworks much use while I was working on my current project. I’m sure they are well thought out and designed, but after going through two or three, I was more lost than when I started. I decided then that I should learn how this whole AJAX thing works from the ground up. Turns out XMLHttpRequest isn’t all that difficult, once you get past a few JavaScript cross browser hiccups.

He talks briefly about his PHP backend and the methods that are available to return data in (XML/HTML/JSON) before talking about the issues he found:

  • Don’t Create an Instance of the Same Object For multiple Tasks
  • Always Call XMLHttpRequest Object First

For both, he gives a bit of code to explain the issue and to illustrate a workaround method, including the full code at the end of the post.

Posted by Chris Cornutt at 9:34 am

3.6 rating from 37 votes


Comments feed TrackBack URI

Alternate title: “AJAX 101” dated June of 2005.

Comment by Cynic — July 24, 2006

There are debates of the benefits of using XML, but JavaScript can be used to parse the XML.

He doesn’t mention XSL at all.

Comment by Hakan Bilgin — July 24, 2006

‘This is perhaps, the most used way. There are debates of the benefits of using XML, but JavaScript can be used to parse the XML. The speed in doing so, is up to how well you write the JavaScript code. I thought it was fun using this.”

Author just has never done anything serious. I fully agree with Cynic comment above — XSLT is a way to go.

I have experience, where switching from JavaScript processing of XML DOM to XSLT boost performance in 300-400 times.

This was (is) kind of a virtual table, where chunks of records were loaded on demand via Microsoft.XmlHttp (we didn’t know that someone calls this Ajax one day ;) . Size of chunk was not less then “view port” size but in reality it was 2-3 times larger: we pre-cached 2 regions right above and below currently visible region, so small scroll deltas did not cause content loading in most typical cases.

Original JavaScript solution yields terrible user experience: when table control was expanded to whole browser window (large view port size, approx 300 records -> 900 records to process) and user scrolls in list with mouse, she gets frozen screen for 2-3 seconds. XSLT approach reduces this time down to 50-70 ms.

Besides performance improvements, we get natural separation of content and presentation, so later when we apply “skins” process went smoothly — small changes was possible with CSS, complex one (it was developed for IE after all, so there were things impossible with CSS ;) was done with different XSLT template + CSS.


Comment by Valery Silaev — July 26, 2006


Comment by qw — February 22, 2007

Leave a comment

You must be logged in to post a comment.