2.3 Displaying Unobtrusive Validation Errors

In the previous sessio, we started looking at the constraint validation API. And we did so in relation to the email field in our form. And it's great that we have that, but unfortunately, the way that I originally coded it, it uses an alert box. And that is horrible design. So instead what we want to do then is fit the error message so that it actually fits within the page itself. So that means that we want to directly have the error message in our HTML. And I'm going to do this, I'm going to add a span element in between the label and the input element. And I'm going to give this an ID of error-email-message. So this can be a convention that I can follow. Anytime that I need an error message for a forum field, I can begin with the term error, followed by the name of the field, and then message. So this is the error message. Let's also use a class to give this a particular type of styles, so I'm just going to call that error. And let's also make this float to the right, so that it's not just jumbled up right next to the label. I will say this, I am not a designer, so somebody can make this look a whole lot better than I can. This is going to be fine for my needs. So let's add some text, so that we can at least make that this is going to look okay. Let's ass the CSS for the error message. We want the foreground color to be red. And let's also set the font-weight to bold, so that it kind of sticks out. And if we look at the browser then that's okay. I mean, I think would rather have it closer to the label, but then well, there's different ways that we could do it. This is going to be fun. Okay, so with that in place, let's get rid of the text because we don't want to display an error by default. We only want to display an error when there is a validation error. So let's go to our JavaScript code, and let's make this happen. Now I will admit that, whenever I wrote this preventDefault, I was thinking about the form submission event, not the input event. So that's kind of useless there, we'll get rid of that. And we don't want to alert, that's just horrible. And in fact, you know what, let's reverse this. If we have a valid email, then we're just going to return, because that's the easiest thing to do. All of our other code as far as showing the error message. And eventually, we're going to pick a particular error message based upon the type of error. That will be nested inside of the if statement. So I like that approach better. We do however need to retrieve that error message element. So let's call this emailError, and the id was error-email-message. So it's nice having a convention, because I can easily remember that. So inside of our if statement, if we have a valid email. Then we're going to set the inner HTML to an empty string, because we don't have an error. No need to display it. Otherwise, we're going to display an error that is simply going to say, please enter a valid email address. Now there's one thing to consider here. We have really two types of validation that's being performed on our email field. We have the check to see if it's an email, because it is a type of email. But then we also have the required attributes, so this is required. So there's two things, if the user doesn't type anything into the field then we could say that's please enter something into the email field. However, in this particular case, please enter a valid email address, I think works in both cases. If the user doesn't type anything in, then we can say please enter a valid email address that fits that just fine. So right now we're just going to display a single message, we will change that eventually. And yeah ,I think that's good, so if we go to the form we just start typing we can see that the error message automatically pops up. The moment that we have a valid email address it goes away, but whenever we once again have an invalid, we see the error message. And it will pop back and forth based upon whether or not the email address is valid, so we have that working. However, there is one thing if we submit the form, it's still going to submit, so we need to prevent that from happening. That means that we need to handle the form's submit even, so that it will not submit in the case of an invalid email address. So the first thing we need to do then is retrieve the form object, now we could do that using document forms, some people do that. I don't like to rely upon any type of array like forms, because there are some ISPs that will inject HTML. And it could inject a form, in which case it will throw off the amount of forms that are inside of the forms collection in the dorm. That could break your code. So to me, it makes much more sense that if there is a particular element that you want to retrieve give it an id. That way you always know that you are getting that element. So I'm just going to give it an id of theForm, and let's just copy and paste one of our current lines. And we'll change the variable name to the form and the id is the form. So there we go, we will listen for the submit event, and we will of course have our function for handling that event. Now, what we want to do then is essentially the same thing. If our email is valid, then there's really nothing to do, so we're just going to return. Now we're not going to do anything with the email error, because that should be handled by the input event listener. So as far as the submit event listener, all we should really check to see is if we have a valid field, if we do great. If not, then prevent the default. So that should be fine. If we go back, and let's type something in, and that's fine. If we click on the Send Message, okay? The form is not being submitted. But if we type in a valid email address, and submit the form that gets submitted, so there we go. We have our little email validation going. Now this is okay, but we have three other fields. And frankly, I don't wanna have to do this for every stinking field. So I would like to someway of generating our logic as far as validity is concerned, so that it will check to see if the form control is valid. And if it's not, then it will display the appropriate message. But that might be getting a little bit ahead of ourselves. Let's take this in baby steps. In the next lesson, we are still going to work solely with the email field. But we're going to start adding the logic for handling different types of errors. And once we have that in place, we can start thinking about generalizing our form validation code.