After learning the syntax of the data validation methods, discover how to add validations to the simple_cms project. Start by considering what good data should look like and any database or application restrictions.
- Now that we have an overview of validations, let's try writing some and we'll start by considering what we ought to validate. Deciding what to validate is really about asking yourself what your data concerns are and that may be different for each project. And it depends a lot on your personal style. A helpful starting place is to consider what good and bad data looks like. For example, you can start by asking what restrictions your database imposes. Then you can ask what would stop your application from working? What are the assumptions that you're making about data that either is present or has a certain format, or has a certain value. Typically you don't need to validate low level data like IDs, foreign keys, timestamps, or booleans. Those are usually simple enough that they don't require validation. It may take you a little while to get a feel for it. And you may want to start simple. We're going to start simple, by looking at two of the most common validations. validates_presence_of, and validates_length_of. Let's try adding these validations to our subject class. So I'll just come right here and below the scopes, I'll put in our first validation validates_presence_of name. Now we've written a rule and the rule says that you cannot create or update a record, unless you have a name that's present. That means the name can't be considered blank. Now let's add a second one. validates_length_of name and let's set it to a minimum of one for now. The reason I picked one as a starting place is that one of the questions that comes up with beginners a lot of times is what is the difference between validates_presence_of and validates_length_of. And this will help us to see that difference. Notice that I have two different rules on the same attribute. That's not a problem. We can have as many as we want. Let's try saving this and let's run it and see what happens. We'll go to rails console, and we'll start by just making a new subject, subject.new. And before we do anything else, let's just try saving it. Subject.save, and it returns false. It did not save the subject. We want to see why we can type subject.errors, and it will tell us information about what's wrong inside the messages here you can see it. The name can't be blank and the name is too short, minimum one character. So we now see one of the differences between validating a presence and validating the length. It gives us back different messages. Notice also that it ran both of our validations. When validations run, it runs all the validations inside the model and comes back and tells you all of the errors that it encountered. That's because you wouldn't want to have one problem with an object, and go back to the user to have them correct it, and then submit it only to find out that there's another problem. Instead, we find out all the problems, return them all back to the user. So the user can fix them all at once. Now let's try setting the subject name to something. Subject.name equals, we'll just make this test for now. Now, if I were to type subject.save it would save, but I'm not going to do that. Instead. I'm going to use subject.valid. And when I do it will run the validations but we'll not try to save it to the database. It's like a test run. Most of the time, you won't need to call valid. It happens automatically when you go to save the object. So by adding a four-letter name, it passed both of our validations and it could be saved. Let's try changing the name to just four spaces and see if that works. I'll hit the up arrow so we can do subject.valid. It's false. Why is it false? Subject.errors, and this time, instead of just doing subject.errors, I'm also going to add full messages after it. And now you'll see, it gives me back a nice array of messages that are suitable for displaying to the user. It's very easy to read. And the problem is that the name can't be blank. So that means that it failed my presence validation, because it's considered blank. But it did not fail the length validation. So we now see that there's another difference between presence and length. We won't save a subject to the database. Let's go back to our subject class. And before we leave things, let's just change this from being a minimum of one, to being a maximum of... And we'll make it 50. Now we must have some name and it can be any length up to a maximum of 50.