Discuss: User-Proofing Ajax
by Peter Quinsey
- Editorial Comments
2 code nits
Having a coding background, there are some nits with the code that wouldn’t have passed a code review. Considering the ‘leader-of-the-pack’ status of ALA, people will copy-paste examples given here, and why have them copy-paste less-then-perfect examples? :)
- The test in the ‘keep users informed’ example should be rewritten in reverse (if (request.status!=200){ error(...);}). Saves an indent and unobfuscates code.
- In the PHP-code example; after an exit() in an if()-statement there is no need for an else. Saves an indent.
The “second example” that pops up a box ‘please wait’ is a very nice touch indeed!
posted at 11:04 am on December 05, 2006 by Maarten van Baarsel
4 return NOT perform_ajax_action
logically, if perform_ajax_action is successful, it should return true…so
onsubmit=”return perform_ajax_action();”
should be
onsubmit=”return !perform_ajax_action();”
posted at 07:56 pm on December 05, 2006 by patrick lauke
5 Untitled
@patrick: I guess that
if ( !request = createAjaxRequest() ) {}
allready did that trick here.
posted at 10:15 pm on December 05, 2006 by Sander Aarts
6 should have expanded my previous comment
sorry, should have expanded the first part of my comment: if the function perform_ajax_action fails to create an ajax request, it should return false, not true…
more generally: if i call a function and the function fails to perform, it should return false, not true (from a good practice/clarity point of view). hence, imho, it should be:
function perform_ajax_action(){ if ( !request = createAjaxRequest() ){ return false; // abort Ajax attempt, submit form } // proceed with your regular Ajax functionality // ... return true; // do not submit the form }
and then deal with it via
onsubmit=”return !perform_ajax_action();”
posted at 12:18 am on December 06, 2006 by patrick lauke
7 true / false
I agree to Patrick, that it’s common sense for developers to return false if the execution of a method failed. Same is for JavaScript onSubmit event handlers, because they were meant for checking form values and then when the check failed you should return false and the form should not be submitted.
With Ajax it’s vice versa, the form should not be submitted if everything is ok.
A solution to this is the usage of an onClick event handler on the submit button that triggers the Ajax action and an onSubmit method that just checks for errors of the Ajax action. Then the true / false logic is right again.
posted at 07:59 am on December 06, 2006 by Frank Fischer
8 Sorting of comments broken?
My last comment appears as the first comment, but it was actually an answer to “should have expanded my previous comment” by Patrick. Confused,
Frank.
posted at 08:02 am on December 06, 2006 by Frank Fischer
9 @patrick
You’re probably right. It seems more logical.
cheers
posted at 04:08 pm on December 06, 2006 by Sander Aarts
10 handling non-scripted browser
How do you write a single server-side action that:
1) returns xml for valid ajax request 2) returns full html/xhtml,or forwards to full url, if standard form post?
posted at 05:09 pm on December 07, 2006 by brian smith
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.


1 Server Side Error Handling
Beside the client side error handling this (well written) article described, it is first of all essential, that the server side indicates errors in a proper way. Many scripting languages like PHP were made for producing HTML. Now that they have to produce an XML document for the Ajax-client you have to customize the error handling to be integrated into the XML document and/or generate the right HTTP response code.
posted at 11:01 am on December 05, 2006 by Eugen Schneider