Jump to content
Larry Ullman's Book Forums

Understanding Ajax


Recommended Posts

Hi,

 

First of all, my English is very bad, but I hope you will understand me.

 

I started reading the chapter 11 (Ajax) and, at some points, I think that understood well, but there is one example that confuses me. Let's look at an example from the beginning of the book:

 

... When the user clicks the submit button, the JavaScript could pause the submission of the form and send the form data to a server-side script. That script would perform all of the validation and return data that indicates a simple status or a list of errors. If errors were returned, the JavaScript would parse the errors and update the page, indicating any and all errors accordingly, and add highlighting to further emphasize the problems. If the returned status indicated that no errors occurred, the JavaScript would do whatever to move the user along in the process...

 

 

 

2n9jqjt.jpg

 

 

 

I didn't really understand the purpose of this. If AJAX was used when user fills some fields like username, that would make sense. For example, when user enters username and onblur event happens - than AJAX will be used to "do the job" and that would save some time for that user if he entered username that already exists. And that makes sense.

 

But, it this example, AJAX is used on submit. So, what the difference between using AJAX on submit and using some server script (<form ... action="script.php">) to validate data? In both cases, the user must press the button and see if he entered everything ok.

Link to comment
Share on other sites

The onsubmit event is often used to perform simple validation on the client-side to catch obvious errors. This is beneficial because you don't have to submit the form to the server-side and reload the page if there is an error that client-side validation catches.

This creates a much smoother experience for the user, and it lessens the load on the server, which is always a good thing.

 

The golden rule of client-side validation though is that you should never rely solely on it. I like to use client-side validation for very simple things, but regardless, I always perform full and thorough validation on the server-side (including repeating the checks I do on the client-side).

 

That answer your question?

 

As a note to Larry: I noticed that I see the pictures QuakeLive posts in Chrome on my Windows 7 PC, but I don't see them in Chrome on my MacBook Pro. Just an FYI.

  • Upvote 1
Link to comment
Share on other sites

The onsubmit event is often used to perform simple validation on the client-side to catch obvious errors. This is beneficial because you don't have to submit the form to the server-side and reload the page if there is an error that client-side validation catches.

This creates a much smoother experience for the user, and it lessens the load on the server, which is always a good thing.

 

The golden rule of client-side validation though is that you should never rely solely on it. I like to use client-side validation for very simple things, but regardless, I always perform full and thorough validation on the server-side (including repeating the checks I do on the client-side).

Would not it be better to use, for example, onblur event for every field, so if someone enters username that already exists, he will know that as soon as onblur event happens for that field?

 

As for the onsubmit event - in that case - do we really need Ajax because we can just prevent the default browser behaviour and not reload the page and show errors, right? :huh:

 

Sorry for bad English.

Link to comment
Share on other sites

It's up to you.

The problem with onblur is that it could potentially be fired many times during a single form submission, which can lead to a bigger load on the server.

Really, there are many ways you can approach this: Use a key event, a blur event, a submit event, etc.

 

Also, I agree that you don't need Ajax for the onsubmit event. I wasn't suggesting that you do use Ajax. I was suggesting that you prevent the default form submission so that you could do some basic checks on the client-side before submitting the form.

Doing so involves the use of JavaScript, but not Ajax.

  • Upvote 2
Link to comment
Share on other sites

It's up to you.

The problem with onblur is that it could potentially be fired many times during a single form submission, which can lead to a bigger load on the server.

Really, there are many ways you can approach this: Use a key event, a blur event, a submit event, etc.

 

Based on what I've read until now, I suppose that Ajax search works based on onkeypress event... but my knowledge isn't enough, I'm a beginner, so maybe I'm wrong...

 

 

Also, I agree that you don't need Ajax for the onsubmit event. I wasn't suggesting that you do use Ajax. I was suggesting that you prevent the default form submission so that you could do some basic checks on the client-side before submitting the form.

Doing so involves the use of JavaScript, but not Ajax.

 

Regarding the previous example, is it possible to check that "username" already exists without reloading page and without Ajax?

 

I'm still learning JavaScript and I don't know any of server-side languages such as PHP, but if I understood some things well - when we submit some form - we actually forward the entered data to a server-side script that is in <form ... action="somescript.php"> and then the page is reloaded. That is the default behaviour, right? And, if we are speaking about the default behaviour - does it mean that the same page is reloaded?

 

If we want to check that username already exists without reloading page and without Ajax - we need to prevent the default behaviour. But, in that case, is it possible to forward the entered data to a server-side script and to get the results of validation without the default behaviour - reloading the page again?

Link to comment
Share on other sites

Most user name/email address Ajax checkers work on key presses, yes. However, they don't usually fire every key press, as that would create a huge load on the server. They usually don't fire until at least three characters are entered and they don't continue to fire until a certain amount of time has expired.

 

As for checking whether a user name exists without Ajax and without reloading the page, the only way to do that is to get the entire DB of user names on page load, store that in a JS object, and then check from there. If you have < 500 users or so, that might be doable. In most practical cases though, you should never do that.

 

Also, yes, the default behavior of a form is to submit to the script entered for the action attribute. If the action value is the same as the current script, then the current script is reloaded. Otherwise, a different script is loaded. In all cases, the default behavior does cause a page reload.

 

This is why JavaScript and Ajax are so popular; you can do a lot without reloading the page, and when you do need to change something based on DB data, you can use Ajax to gather only the data you need, which greatly reduces the load on the server.

 

That all make sense?

Link to comment
Share on other sites

Thank you so much for the answers!
 

As for checking whether a user name exists without Ajax and without reloading the page, the only way to do that is to get the entire DB of user names on page load, store that in a JS object, and then check from there. If you have < 500 users or so, that might be doable. In most practical cases though, you should never do that.

 

1. So, it is possible that client JavaScript communicate with DB, or that would be done (somehow) with php or with some other server-side language which would store all the names from DB in JavaScript object?

 

I understood that I should never do that, I'm just asking because I want to make some things in my head as clear as possible. :)

 

2. I'm not sure if I'll formulate well this question - is Ajax the only way for JavaScript to "read" the content of other files such as text files? In this topic we had an example where JavaScript actually "read" the content of text file test.txt, and put it on html page "test.html". That was done by using open method and responseText property (by using the "Ajax technology"):

 

ajax.open('GET', 'resources/test.txt', true);

...

...

document.getElementById('output').innerHTML = ajax.responseText;

 

Also, can JavaScript write to some files?

 

 

If the action value is the same as the current script, then the current script is reloaded. Otherwise, a different script is loaded. In all cases, the default behavior does cause a page reload.

 

I'm not sure if understood this well. Let's say that we have some simple html file named example.html with some registration form:

 

...

<form ... action="something/somescript.php">

...

 

The default behavior of a form is to submit to that script ("something/somescript.php") and example.html (the same page) will be reloaded?

 

So, the action value is something/somescript.php, but what do you mean by the "current script"?

 

Thank you very much again!!!

Link to comment
Share on other sites

"Ajax" is purely a name used to refer to JavaScript communicating with a server-side language (e.g., PHP) without reloading the page.

As such, Ajax is the only way for JavaScript to communicate with the server-side, and yes, Ajax can be used to read text files and the like, but it cannot be used to write to text files directly. For that, an Ajax request would have to be made to a PHP script, which would then write to the text file.

 

As for the form question, the form will submit to something/somescript.php, and unless you redirect the user back to example.html after that, you will not see example.html again. That make sense.

  • Upvote 1
Link to comment
Share on other sites

HartleySan, thank you so much for helping me to understand Ajax, JavaScript... now, some things are much clearer. Thank you for your support and help!

 

 

As for the form question, the form will submit to something/somescript.php, and unless you redirect the user back to example.html after that, you will not see example.html again. That make sense.

 

So, speaking about the default behaviour - regardless of whether everything was OK - page somescript.php would be loaded.

Link to comment
Share on other sites

Is it important to Identify a Result Handler first, and then to Make a Request, or it does not matter? I am asking this because in the book Larry always first Identify a Result Handler and then Make a Request... for example:

 

 

window.onload = function() {
    'use strict';
    var ajax = getXMLHttpRequestObject();

    ajax.onreadystatechange = function() {
        if (ajax.readyState == 4) {
            if ((ajax.status >= 200 && ajax.status < 300) || (ajax.status == 304)) {
                document.getElementById('output').innerHTML = ajax.responseText;
            } else {
                document.getElementById('output').innerHTML = 'Error:' + ajax.statusText;
            }
        }
    };

    document.getElementById('btn').onclick = function() {
        ajax.open('GET', 'resources/test.txt', true);
        ajax.send(null);
    };

};

 

but for me it would be more logical (and nicer) to Make a Request first:

 

 

window.onload = function() {
    'use strict';
    var ajax = getXMLHttpRequestObject();

    document.getElementById('btn').onclick = function() {
        ajax.open('GET', 'resources/test.txt', true);
        ajax.send(null);
    };

    ajax.onreadystatechange = function() {
        if (ajax.readyState == 4) {
            if ((ajax.status >= 200 && ajax.status < 300) || (ajax.status == 304)) {
                document.getElementById('output').innerHTML = ajax.responseText;
            } else {
                document.getElementById('output').innerHTML = 'Error:' + ajax.statusText;
            }
        }
    };

};

 

Maybe there is some practical reason why... :huh:

Link to comment
Share on other sites

As a general rule, you should always have event handlers set up before any events can fire that would trigger those event handlers. Likewise, I would make sure that the onreadystatechange event handler is set up before you call the send method.

 

Also, while my memory is a bit fuzzy, I seem to recall IE6 having issues if you do onreadystatechange last.

  • Upvote 1
Link to comment
Share on other sites

As a general rule, you should always have event handlers set up before any events can fire that would trigger those events. Likewise, I would make sure that the onreadystatechange event handler is set up before you call the send method.

 

Also, while my memory is a bit fuzzy, I seem to recall IE6 having issues if you do onreadystatechange last.

Thank you!

Link to comment
Share on other sites

 Share

×
×
  • Create New...