Bien, en esta clase vamos a agregar la validación del formulario.
Vamos a usar anotaciones en la clase Entity a través del estándar de validación de Java, también conocido
como la especificación Beans Valid.
De hecho, nos vamos a la clase Entity.
Y por ejemplo, por cada campo, por el nombre, el apellido, el email, la fecha.
Podemos anotar con reglas de validación propias del estándar, por ejemplo, todo lo que sea del tipo
String.
Podemos anotar que sean requeridas usando la anotación Not empty.
Entonces empty es básicamente que sea requerido el campo.
Anotamos importante Yaks Valid Echols Constraint, que es el estándar y Vernet de precaver.
Tenemos que utilizar ya Bax Valid.
De hecho, por lo menos en Spring puntos importamos.
Vamos a copiar y también NMI porque son del tipo String.
Entonces por detrás va a validar que el string sea distinto de ácido, que el largo sea mayor que 0.
Por lo tanto, que al menos escribamos uno o más caracteres en el campo.
Bien, pero qué pasa con el tipo de con tipos que son de otras clases distinta del string?
Hoy podemos validar que sea distinto de nulo con not null.
Importamos también de yaks validacion.
Ven válida que la fecha no sea nula.
Básicamente sea distinta.
Nula.
Entonces la diferencia en Not Empty solamente se utiliza con string con cadenas para que sea requerido
y todos los demás tipos.
Por ejemplo, un tipo doit incluso también puede ser un tipo de otra clase Entity o un tipo numérico
como un decimal, un big decimal, un double, un float.
Podemos balear con not null.
Solamente los string con not empty.
Esa diferencia.
Porque por ejemplo, si anotamos con un null en un string, por ejemplo, el nombre nunca se va a aplicar
esa validación.
Por qué?
Porque un string.
Incluso si en el campo no escribimos nada, lo dejamos vacío.
Cuando se envía ese string es con carácter cero, pero no es nulo, es distinto, nulo.
Por lo tanto, no se va a validar.
Por eso tenemos que validar que el string tenga caracteres mayor que 0 sea requerido con Not empty bien
y email.
También queremos validar que el formato sea correcto.
Un formato de correo electrónico.
Anotamos con email.
Podemos importar también el estándar porque si usamos internet es de preset.
Por ejemplo, lo de marcar realmente para el ejemplo se marca como despégate en amarillo se fijan el
tipo email de precaver, ya que lo estamos importando del paquete de internet.
Voy a volver atrás y voy a importar de jabas valid, hecho que es el estándar perfecto.
Hoy lo porta correctamente.
Entonces, por lo menos en Spring puntos siempre tenemos que importar de yaks, Validacion Constraint,
el email y también el Not Empty y todo lo demás.
Bueno, y qué pasa si quiero validar que un string, por ejemplo el nombre, el apellido, esté dentro
de un rango, por ejemplo, entre 4 y 12 caracteres?
Bien, ahí podemos usar la notación 6.
No es necesario que lo hagan solamente para explicar.
Para el ejemplo 6 voy a importar.
Acá tenemos el atributo mínimo 1000 igual a cuatro coma máximo igualados.
Entonces el nombre va a estar entre 4 y 12 caracteres.
Y así tenemos muchas anotaciones más.
Pero para el ejemplo voy a dejar solamente not empty.
Y también el email y la fecha con nube y estamos listos.
Vamos a guardar.
Cliente Nos vamos al controlador.
Ven.
Es importante, fundamental en el método Guardar que recibe el objeto mapeado al formulario.
En este caso, el cliente.
Acá tenemos que habilitar la validación para que se valida el client.
Para eso usamos Valli.
Importamos de yaks.
Validación.
Bien, este paso es importante.
Tenemos que anotar con Paly en el argumento que se recibe el objeto de formulario.
Bien, pero claro, si falla el formulario, tenemos que validar que preguntar si contiene errores.
Si contiene errores es porque falló.
Ahí tenemos que cargar la vista formulario y volver a la plantilla del formulario con mensaje de error.
Mostrar estos mensajes al usuario para que los corrija.
Bien, para eso tenemos que agregar otro objeto.
Como argumento del método Binding resulto importamos de Spring Validación.
Y a través del resultado, mediante un if, por ejemplo, if result si contiene errores en plural,
haz errors, entonces acá manejamos cuando ocurre el error.
Por ejemplo, retornamos la vista del formulario con todos los mensajes de error y si todo sale bien,
bueno, guardamos al cliente con nuestro dado bien.
Un detalle aparte que es bien importante que lo tengan presente.
El binding result siempre va junto al objeto del formulario.
En este caso el cliente.
Estos dos tienen que ir siempre junto como argumento el método uno al lado del otro.
Primero el objeto que está mapeado, en este caso el cliente koma, el binding result y después lo demás
parámetros.
Por ejemplo, el model y todo lo demás que tengamos siempre estos dos van juntos.
Bien, continuemos.
Si falla, también tenemos que pasar el título, ya que el formulario lavista tiene el atributo título,
entonces con atributo y pasamos formulario de cliente como valor.
Bien, pero qué pasa con el cliente?
Acá pasamos el cliente también en el formulario y acá nos lo estamos pasando, pero en realidad lo pasa
de forma automática al formulario cuando falla.
Pero siempre y cuando acá hay una regla que importante, cuando el tipo de la clase, en este caso el
cliente, el nombre de esta clase se llame igual que el nombre con el cual lo estamos pasando a la vista
cliente.
Si se llama cliente y la clase cliente está todo bien, lo pasa de forma automática, sin tomar en cuenta
que las clases comienzan con mayúscula y que el atributo se escribe completamente minúscula sin tomar
en cuenta.
Eso sí, se llama igual está todo perfecto.
Ahora, qué pasa si se llamase distinto?
Bueno, hoy tenemos que indicar el nombre con el cual lo estamos pasando la vista a través de la anotación
modal atributo.
Entonces, al lado del cliente o del tipo con model atributo, importamos.
Esto no es necesario que lo hagan solamente para explicar.
Así que esto no lo haga, ya que la clase se llame igual no sería necesario.
Pero si se llama distinto, acá en los paréntesis indicamos el nombre con el cual lo pasamos a la vista.
Por ejemplo, si lo pasamos como cliente, otro acá hoy día el cliente otro, es decir, acá mismo,
nombre con el que le pasamos a la vista.
Bueno, en nuestro caso se llama igual client, así que se lo dejamos de forma explícita.
Igual va a funcionar, pero sería redundante.
Bien, vamos a dejar como estaba, ya que se llama igual.
Por lo tanto se pasa de forma automática.
No es necesario el modal atributo listo y estamos completamente listo con el controlador, con el método
guardar.
Estamos validando si todo sale bien, guardamos si falla.
En el caso erros pasamos el título.
El cliente se pasa de forma automática al modelo Attribute.
Cargamos la vista y vamos a mostrar el mensaje de error al usuario.
Guardamos y nos vamos a la vista a la plantilla en recursos template formulario.
Entonces acá por cada campo, por el nombre, apellido y mail y la fecha, tenemos que mostrar el mensaje
error.
Para eso utilizamos, utilizamos la etiqueta small o cualquiera puede ser small o label.
Básicamente usos moll para que se vea un poco más pequeño, no más un detalle bien, pero bueno, con
Taine LIF acá tenemos que validar, preguntar con TH if con este atributo esta directiva preguntar de
alguna forma si este campo nombre contiene errores antes de mostrarlos, pero para eso tan LIF tiene
objetos que son kelpers para trabajar en la validación en el formulario.
Por ejemplo, el objeto fields en plural termina en s es importante fields punto jass errors también
en plural si contiene errores as errors paréntesis indicamos el nombre del atributo.
En este caso nombre bien y si contiene errores, tenemos que mostrar este error.
Este texto th errors también en plural th errors igual asterisco la llave.
Por qué hacemos referencia al campo al atributo que este mapeado a la clase entity nombre igual que
acá, igual que en Field.
Lo mismo acá mostramos el error correspondiente al campo nombre, faltaría una clase de vostra para
que el texto esté de color rojo.
Usamos el estilo form text y text danger.
Bien, entonces ahora vamos a copiar esto mismo por cada input justo debajo para el apellido.
Para el email.
Y también para la fecha cred at.
Bien, problemas en el input por cada campo.
Podemos pintar también de color fondo rojo con un margen rojo.
Además del texto.
Para eso usamos el atributo details diff error class.
Todo junto.
Todo en minúsculas.
Igual comilla simple.
Dentro de la comilla doble indicamos el nombre del estilo de la clase de vostra.
En este caso fueron control para mantener el mismo estilo del input form control y además alert danger.
Vamos a copiar esto por cada uno.
En el apellido, en el e-mail y en la fecha.
Bien, estamos listos.
Vamos a guardar.
Íbamos a probar.
Bien, nos vamos a la página del formulario y vamos a enviar, se fijan?
Perfecto.
Acá pinta cada campo de color rojo.
Y el mensaje no puede estar vacío por cada campo.
Y el último, la fecha no puede ser nula.
No puede ser.
No ven estos mensajes.
Después lo podemos personalizar.
Después, en la próxima clase, vamos a ver cómo personalizar estos textos de error de forma automática.
Spring De acuerdo a nuestra localización.
De acuerdo al Time, Son va a mostrar los textos en el idioma correspondiente a nuestro país, a nuestra
zona.
Pero bien, cómo explicaba esto?
Se puede personalizar?
Estos son los mensajes mensaje queda por defecto bien colocamos Andrés
Crear cliente perfecto valida nombre y apellido correctamente.
Qué pasa con el email?
Está validando bien para que sea requerido, pero si escribimos un correo invalido, cualquier cosa
acá está validando con HTML5 y no con sprint.
Por qué?
Porque nos vamos a la dicta el tipo input del tipo email HTML5 al ser del tipo de email válida automáticamente
que sea un correo, un correo bien formateado.
Entonces, para poder probar con Spring la validación y mail que vimos en la clase cliente, tenemos
que cambiar al type text.
Vamos a guardar, tenemos que volver a cargar nuestro formulario.
No vamos a cliente crear cliente Andrés Guzmán Cualquier cosa crea cliente perfecto.
Ahora sí que está goleando por el lado de Spring.
No es una dirección de correo bien formada, claro, le falta la година y le falta el nombre del dominio,
por ejemplo.
Hola!
Punto com crear.
Perfecto.
Ahora, qué pasa si omitimos el punto com?
Bueno, si lo omitimos también es un email correcto, válido porque hay mucha corporaciones que contienen
correos corporativos sin extensión, sin el punto com, sin el punto, lo que sea.
Entonces si colocamos crea cliente se valida perfecto.
Es válido.
Lo importante que tenga el nombre, el arroba y el dominio.
Qué pasa con la fecha?
Otro tema también un poco más complicado, porque tienen un formato válida que no puede ser nula.
Pero si colocamos cualquier cosa, obviamente va a fallar.
El problema es que el mensaje es bien duro por decir es bien feo al cliente final.
La idea es que este tipo de mensajes se puedan personalizar y mostrar algo mucho más amistoso al usuario
final.
Pero esto lo vamos a ver la próxima clase con lo vamos en la fecha valia.
Bueno, si colocamos con Latch año, mes, día, pero con esa larch también va a fallar.
Por qué?
Revisemos nuestro código cliente.
Acá tenemos el data, informan.
Lo indicamos con año, mes, día, pero separado con guión.
Entonces, como Estaco se larch, obviamente el formato también es incorrecto.
Si enviamos falla, entonces nuevamente la idea de colocar un mensaje amistoso que diga al usuario que
la fecha de tener el siguiente formato y mostrar un ejemplo del formato.
Por ejemplo, con guión Yaí lo haría perfecto y guarda el nuevo cliente.
Bien.
Así que por ahora nada más.
Y la próxima clase continuamos con personalizar estos mensajes de errores del formulario.
Hasta la próxima.