Ven, sigamos con la validación.
Bueno, lo primero, si queremos validar, por ejemplo, el formulario.
Recordemos que el formulario está mapeado excepto a el usuario a esta clase POJO.
Entonces acá tenemos que validar esta clase usuario.
Entonces con la anotación paly un espacio bueno, importamos de Java Bali de hecho.
Bueno, vamos a aliar usando anotaciones con el API de validación de Java Java pings valid hecho y mediante
estas anotaciones podemos aplicar reglas de validación que ya vienen predefinidas.
Vienen por debajo, construida en la plataforma Java y en Spring se integran.
Pero otra forma después, por ejemplo, vamos a ver cómo implementar una validación personalizada.
Pero bueno, eso es otro tema.
Después vamos a ver, por ahora vamos a utilizar esta validación es típica que nos sirven para el 99
por ciento de los casos.
Entonces lo primero es habilitar la validación acá.
Cuando se recibe los datos del usuario mapeado al formulario lo siguiente En la clase usuario tenemos
que indicar qué regla de validación.
Usando anotaciones vamos a validar en cada campo.
Por ejemplo, si el Yussef name, el password y el email son requeridos y además son del tipo String.
Entonces podemos validar con Not empty, entonces not empty valida.
Bueno, primero que el string sea distinto en URL y además que tenga un largo el string.
Es decir, que no esté vacío.
Entonces muy importante siempre con los string del tipo texto valíamos con not empty nuevo acío.
Entonces esto se aplica tanto a iUsted name.
También si quiero validar password.
Y también y?
Entonces estos tres campos son requeridos y guardan.
Bueno, también podríamos validar por el IMEI que sea un formato de correo electrónico.
Pero bueno, eso lo vemos después por ahora requerido.
Es decir, no puede ser vacío.
Nos vamos al controlador y de alguna forma por acá en este método, antes de procesar el formulario,
el objeto usuario, por ejemplo, antes de pasarlo lavista o antes de guardarlo en la hace rato, tenemos
que manejar si es válido o no. En el fondo si tuvo error el formulario.
Pero para eso necesitamos pasar o inyectar mediante el método procesar este método handler.
Podemos pasar por argumento el objeto del tipo binding result
y le llamamos result.
Vamos a importar por acá.
Control Barra es una interfaz, un tipo genérico.
Bien, este objeto es propio de Spring y representa el resultado de la validación.
Es decir, contiene los mensajes de error.
En caso de que ocurran errores de que hayan de que falle la validación, entonces tiene toda la información
del resultado de la validación y se inyecta de forma automática cuando está anotado el objeto con vale
el objeto en este caso usuario.
El objeto POJO o Entity, pero tiene una restricción que es muy importante que se respete siempre.
El binding result tiene que estar justo después del objeto que se valida, es decir, el objeto usuario
y el objeto usuario o cualquier objeto que queremos validar.
Cualquier POJO o Entity por lo general es el primer argumento del método tal como lo tenemos acá.
Entonces primero el objeto usuario o que vamos a validar y el segundo el Bingen result.
Siempre tiene que ir después de este objeto que vamos a validar.
Esa es la regla.
Por ejemplo, no ir después de Modell.
Si muevo esto después de Modell, no va a funcionar siempre.
El segundo argumento justo después, en este caso del usuario y listo.
Esa sería la regla.
Luego, usando un if podemos validar result.
Punto jass errors.
Si contiene error, entonces acá manejamos la respuesta.
Por ejemplo.
Bueno, lo típico.
Volvemos.
Retornamos la vista al formulario form.
Eso es lo primero, regresar.
Bueno, también podríamos pasar el título acá, pero mejor es cortarlo y lo dejamos justo acá.
Entonces el título se aplica tanto si ocurre un error o si todo sale bien.
Bien, qué faltaría?
Bueno, faltaría pasar un mensaje de error a la dicta cómo de diferente forma podemos usar, por ejemplo,
un Ashima, un map de Java con el nombre del campo, en este caso el Yussef, el password o el email
y el mensaje error message error lo tenemos desde acá.
Entonces justamente eso vamos a hacer el map del tipo String.
Perfecto.
Importamos.
Errores igual New Map importamos de ya útil.
Bien, entonces ahora usando el result para obtener los mensajes de error, vamos poblando este mapa
con los mensajes de error por cada campo.
Entonces resulto con el método Get fiel Errors por acá, guet fiel, errors en plural.
Una lista es una lista, por lo tanto la trama que iterar.
Punto foreach Por acá tenemos el método Zürich, que recibe una presión blanda, es decir, una función
Ginetta, función que también se le conoce con función de flecha.
Obtenemos el error, el objeto error.
Recuerden que Get Field Errors es una lista, es un array list que contiene los field erros y cada field
error tiene el campo que falló y el mensaje de error correspondiente.
Entonces función de flecha y las llaves.
Entonces por cada uno es un for.
Por lo tanto estamos alterando por cada mensaje error, errores, punto put.
Acá vamos a colocar una llave y un valor bueno, cuál sería la llave del tipo String?
Error.
El objeto que se está emitiendo acá.
El error field.
Punto get field.
Acá obtenemos el nombre del campo o del input que dio el error.
Por ejemplo, USENET o el password o el email y el Valium, el mensaje error que queremos manejar.
Y esto lo podemos personalizar.
Entonces por acá comillas el campo, un espacio y concatenados punto con catt bueno, del objeto string
no cierto concatenados con el nombre campo.
Get field.
Entonces, por ejemplo, el campo Giussani.
Acá volvemos a concatenar junto con Cat.
Un espacio y volvemos a concatena.
Punto.
Bueno, esto me pareció usar el más para concatenar un string, pero más orientado objeto y también
más optimizado, porque es más, lo que hace es crear una instancia de un string y acá estamos anexando
más contenido, más secuencia de carácter al mismo objeto, al mismo string.
Entonces, en el fondo estamos guardando menos objetos en la memoria, un solo string versus versus,
el más que crea diferentes instancias del string que vamos a concatenar.
Al final tampoco.
No es tan tremendo, pero es mejor concatenar con el mensaje.
Por acá tenemos get default message por acá get default, message el mensaje y listo.
Ahí estamos poblando nuestro mapa, que es un arreglo asociativo, una lista asociativa basada en nombre
y valor.
El nombre corresponde al nombre campo y el valor mensaje error.
Bueno, y que faltaría pasar a la vista errores entonces models a atributo por acá.
Errores o error?
Mejor le podemos llamar error.
Da lo mismo, y acá errores.
Bien, le dimos en singular herrores porque contiene, por ejemplo, error, punto Yussef, error,
punto, password, error, punto y así por cada uno.
Y herrores el objeto.
Bien, estamos listos.
Guardamos y qué faltaría implementar la vista.
Es decir, mostrar los mensajes de error en la vista formulario.
Pero bueno, eso lo vemos en la siguiente clase.
Ah, y un detalle.
Esta sería la forma manual de obtener un mensaje de error no cierto del objeto.
Bingen result.
Con los métodos get field errors el foreach.
Bueno, de esa forma manual obtenemos los mensajes, lo guardamos en un mapa y después lo pasamos a
la lista.
Pero después vamos a ver otra forma mucho más automática a través de atributos de timeline, pero después
lo vemos.
Continuamos en la siguiente clase.