CODEWITHSUNDEEP
javascriptphpjqueryajax
Shairyar
Shairyar

Reputation: 3356

Better understanding of AJAX

I have been working with AJAX for a while now, I can get the form to submit via ajax, I can get the Div to reload via ajax, add, edit, delete via ajax. What i am aiming on now is better understanding on how to display error messages.

What I think is an error message Suppose a form asks for a name to be submitted, when the user does not enter his name and hits the submit button then the error message should be shown asking user the enter the information required.

At present I am managing this inside the success part of AJAX, is this the right way to do it? If yes then what is AJAX error: function for? Shouldn't the error message where user did not enter the required information be shown through error: function?

This is what my AJAX calls look like and I want to improve it.

$.ajax({
    url: 'demo.php', //your server side script
    data: $("#form").serialize(),
    type: 'POST',
    beforeSend: function () {
        $('#dvloader').show();
    },
    success: function (data) {
    $('#dvloader').hide();
    $("#message").html(data);
    }
});

I also wanted to know should hiding a loading gif be iside the success as well, although it works but I want to know if this is the right way to do it.

I will really appreciate anyone's feedback on it.

Upvotes: -1

Views: 91

Answers (4)

theLibertine
theLibertine

Reputation: 175

As an usual approach, many developers separate frontend errors and backend errors :

as frontend errors there are missing input text, or double click on submit button. This kind of errors are usually managed in the beforeSend: function, 'cause it would be a waste of time to send AJAX requests with missing data. You can stop the request with a simple return false statement as discussed here. A lot of people also use the JQuery validation plugin that works really well.

as backend errors there are values that are not validated by your server-side language (PHP or others), or more technical issues like internal server error or timeout. In this case, you can use the error: function as well explained by @Forien, separating errorStatus values to give users a more readable feedback.

Hope this helps

Upvotes: 0

Forien
Forien

Reputation: 2763

beforeSend: - before ajax request is sent
success: - when request is succeeded and returned something
error: - when ajax request failed (technically)

For timed out error you use error: callback:

$.ajax({
    ...
    timeout: 1000,
    error: function(jqXHR, status, error) {
        if(status==="timeout") {
           //do something on timeout
        } 
    }
});​

For user defined errors (i.e. from PHP) you use success: callback:

$.ajax({
    ...
    success: function (data, status, jqXHR) {
        if (data == something)
           // error
    }
});

Upvotes: 1

pistou
pistou

Reputation: 2867

error is the function to call in case you ajax call failed (like url called not found). It has nothing to do with the custom error verification you want.

In you case, you want to do your verficications (i.e. is there a name submitted?) in your PHP code. and return true (or false) - or actually whatever you want, the point is to define if it is ok or not.

Then, in the success callback function, you display (or not) an error message, depending on the returned value.

However, if your control is as simple as is there a value in this field? you may not want to use an ajax call for that, but a javascript / jquery verification before submit.

Upvotes: 1

Quentin
Quentin

Reputation: 943157

At present I am managing this inside the success part of AJAX, is this the right way to do it?

That's somewhat subjective.

If yes then what is AJAX error: function for?

That is primarily for HTTP errors (e.g. when the server side code does't work the way you expect it to) although it will also fire if (for example) a JSON response is malformed and can't be parsed.

A case could be made that, given inappropriate data being submitted through the form, your server side code should throw an HTTP error code (in which case the error handler would fire), but none of the standard status codes seems appropriate for that and it isn't the usual way to deal with the problem.

Upvotes: 1

Related Questions