Developing Business Logic
Input Validation
This lesson is part of the Developing OutSystems Web Applications course.

Hello and welcome to the lesson on Input Validation in the OutSystems platform.
Now applications should try to limit the mistakes that the users make but as much
as you can try to do this automatically they will happen. For example, input
fields may have different data types that you want to enforce, you might
require different values depending on what the user inputs on a different
input or even have specific verifications in face of the context. To
help implement these, the platform provides you mechanics to do input
validation. Now, out-of-the-box, the platform provides you two standard
validation mechanics. One of them is the mandatory. On the top right hand corner
of your slide you have an input for the book title which is set as mandatory.
This means that upon submitting if the user does not provide the value you
will have a validation error. The second standard validation is the data type. So,
on the other screen shots you can see that PublicationDate is a date and the
input associated with it will make sure that the user types in a date as it
submits. It's important to note that these validations only happen when the
method of interaction is submit. On the navigation, there is no validation. Now
there are three different settings that the validation property of a button or a
link can take. If you select client and server, the built-in validations that we
mentioned are performed on the client-side. Assuming everything is okay
the values are submitted to the server, where you'll be able, on the screen
action, to perform any custom validations. If you select the server validation, then
inputs are submitted to the server, regardless of them being mandatory and
not filled in or of the wrong data type. It is up to you to make all of these
enforcements on the screen action.
Finally, there's the option of none, whereby the inputs are submitted and
there is no verification even on server side for the mandatories and
the data types. Now once execution reaches the screen action you will notice if you
look into the scope of the screen action that every single input has got two
properties: one which is Valid, which is a boolean property and another one which
is ValidationMessage which is a text property. If you selected server
validation mode, you will notice that for every mandatory that hasn't been filled
in or for every input where the user didn't type in the correct data type, these
two properties will be set accordingly. It is important to note that an invalid
input will bubble up the invalid state to the form where it's contained. So for
example, if Book_Edition is made invalid, then the BookForm will be invalid. The
two built-in validations are very, very handy but what if we want to write
custom validations that follow the business logic? For custom server
validations, it's just a matter of writing explicit condition checks and
assignments to the valid runtime properties in case of a validation
failure. So for the Valid property you set it to false and as for the
ValidationMessage property you set it to the text to be displayed to the user
informing him of the error and how he can fix it. So in the screenshot on the
right hand side, if you look at the second if statement,
we're checking if the addition number is greater than 0 and assuming that it's
not greater than 0 we go into the assign whereby we're setting the Valid
of the Book_Edition input to false and the ValidationMessage of the same Book_Edition
to "Edition must be a positive number." And just to clarify, these
validation properties exist for the Input and Input Password widgets, the
Checkbox, the Combobox and the Listbox. But how do these messages, how this
validation message, gets displayed
to the user? When, at any time, we're re-rendering the screen, the valid
property is checked. If the value is true, then the screen knows that input is
correct and it displays the regular widget. We have the first three inputs on
the screen shot with no validation problems. However if the valid is set to
False, then the screen displays the regular widget but applies a specific
styling and displays the validation message as soon as the focus is moved to
the input. On our screen shot we can see the fact that it has on the Edition_Number
input our validation message having been set to "Edition must be a
positive number." And basically that's all there is to input validation. To recap,
you have out-of-the-box two types of validations, the mandatory enforcement
and the data type verification. Plus you can write your own validations using
simple if checks and assign statements. At the end of your sequence of if and
assign statements, just check the form valid, because that will unify if
everything inside it is valid.
That's basically it. See you guys in the next lesson.