Published in Programming and Scripts on Thursday, December 15th, 2005
Building Ajax enhanced applications presents new challenges in several areas of the development process. I have a couple of tricks that I have found to be useful, what do you do?
Debugging JavaScript can be a hairpulling experience, but with the likes of Firefox and it's Javascript Console and Dom Inspector, one has some decent tools for cleaning up errors. And there is always the alert(someVar)
when things get desperate.
The server side of things can get a bit tricky, especially if your application doesn't run without Javascript *. When you can't simply use a print_r, die or echo
a value to the screen, it can get frustrating.
* I would suppose that this is yet another good reason to build an app that runs both ways, but that is a topic for another post ;-)
One thing that I have found useful is to use a simple function to write data to a file. This allows me to check the value of variables or queries - or whatever you want - at certain stages of the script. Here's the code that I use:
At the top of the function it checks to see if the variable in question, $str
, is an array
. If if is, it uses PHPs output buffering to print out the array and store the printout in $str
.
The next step puts the data passed to the function together. The note bit is useful if you are debugging in several areas of your code (see usage below).
Lastly, it opens a file called debug, moving the file pointer to end of the document and it appends the data to the file, which is then closed.
To use this function, simply be sure that it is available to your script, and then call it when you need it. For example, if you are unsure of variable $foo
on line 300 of your code, stick this function on line 301 like this: debugAssistant('Foo, line 300: ', $foo);
.
That's probably my MVP for solving server-side issues when developing with Ajax, what are yours?
Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:
I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.
The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.
Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..
Comments and Feedback
Write it to a file, cool tip. If you're not getting responses, that's about the only thing to do ;)
>> I would suppose that this is yet another good reason to build an app that runs both ways
I don't see how somebody could call themselves a professional and write their apps any other way, but yes that is a whole other story I suppose.
Nice work :)
I also use a similar tool in production sites that gives me an 'Error RSS' for all the apps I maintain at work.
This bit:
if(is_array($str)) {
ob_start();
print_r($str);
$str = ob_get_contents();
ob_end_clean();
}
Would also work as:
if(is_array($str)) $str = print_r($str, true);
...so long as you're running PHP 4.3 or higher :)
mmm ya you are correct. but i think you can debug them using log. you can easily use PEAR::Log or log4php for advanced logging.
Though you cant see the error in server side, its pretty cool to use logger.
Hey Andrew, good point; the code that I use is a little more complex which is why I used the buffering, but for this, yours is much simpler!!
Hey Hasin thanks, I can't say that I've tried log, and to be honest I don't use Pear libs that much, however I may check that out.
Hey Justin, I can only think that some things don't get built to work both ways because of either budget or market...
Here's what I usually do to send an error message back to the browser after an Ajax call.
PHP:
header("HTTP/1.0 400 Bad Request");
die('error message');
JAVASCRIPT:
In your xmlhttprequest handler:
...
if(xmlhttp.status==400) {
alert(xmlhttp.responseText);
}
...
You can use '500 internal error' or whatever HTTP error code is appropriate.
> I can only think that some things don't get built to work both ways because of either budget or market...
Yeah that seems reasonable, but it's interesting that the scenario that would work in all browsers (non-ajax) would be marginalized in favor of the ajax-only solution. Maybe that's not that interesting and instead just typical small-business mentality.
Cedric, nice tip, thanks!
Justin, I hear you, but we've seen
all over the web before. Simply replace ajax for dhtml above...A side note: you can avoid the output buffering and get a printable dump string directly with:
if (is_array($str))
$str = print_r($str, true);
The boolean second argument to print_r was added in PHP 4.3.0.
Thanks Bill! Someone else had pointed that out above too. I had boiled this function down from something a little more complex and kinda missed that when posting this :-)