on non-retarded browsers (ie. IE is retarded in its vanilla state), you have the script console, that should give you at least some valuable information about the bugs encountered, also, they offer console.log() as an option to let you write debug messages to the javascript console. firebug and chrome's developer tools also provide breakpoint options, and what's more, watch expressions. i use the latter a lot to inspect that states of JS objects i created, and i suggest you do the same.
the most confusing errors are the ones that seem to originate from jquery or prototype; in this case, you should examine the bug's call stack to see where your script called either framework that caused the glitch. most of the time it's about nonexistant elements you're referring to, or events which you have an invalid handler for.
another subspecies of errors is AJAX calls. things can get difficult there. first up, you have to write your AJAX call handling in a way that it intercepts network errors or server error responses, so if there's a legitimate reason why your AJAX request failed, you can handle it gracefully.
that done, if your AJAX output is HTML code interspersed with JS, you're in the clear as you can put in HTML tags containing debug information from the PHP source, or even console.log() calls in JS.
however, if you output JSON or XML as your result, you should write your AJAX processing in a way that it can interpret certain properties in JSON or certain nodes in XML that should go to a debug output in your AJAX application; the debug output can be alert() calls (which can be a nuisance and are not fit for displaying large amounts of debug information), element write-ins or console.log() calls. also, using watch expressions, you can see the actual contents of your JSON/XML information.
as for the PHP end of things, i'll describe them in the PHP section.
No comments:
Post a Comment