Bien, continuamos implementando nuestra propia clase de validación personalizada.
La idea de crear una clase que implementa el valida Héctor de Spring y en un método ahí podemos validar
nuestros campos de forma más personalizada, ya sea con expresión regular o utilizando IF o también
utilizando una clase de utilidades princ para validar.
Bueno, cosa que queremos saber.
Pero la idea es comentar esto de acá.
Vamos a comentar el nombre porque el nombre lo vamos a aliar por la clase, la comentamos y también
comentamos identificador.
También lo vamos a validar en esta clase personalizada.
Bien, entonces nos vamos a los package y vamos a crear un РАМКАХ solamente por un orden.
Entonces App New Package.
Llegar le colocamos valid lechon o variadores.
En fin, el nombre que queramos por un orden nada más finalizar.
Y acá esta clase.
Una clase común y corriente.
Le vamos a llamar usuario validador.
Ven y implemento de interfaz.
Un interfaz especial de Spring.
La podemos implementar en mano con implemente o también le podemos agregar acá agregamos y acá buscamos
validador.
Pero es importante que sea del Package or Spring Framework Punto Valid, hecho muy importante que sea
framework y no otro.
No puede ser ni Hibari.
De hecho en solamente Spring Framework.
Ok, acá lo tenemos.
Finalizar bien, este fican crea métodos para validar y un método soporte el mero soporte.
Bueno, es super simple solamente para indicar qué clase Entity o POJO vamos a validar en este caso
usuario.
Ven acá.
Falto guardar como comentamos acá.
Voy a comentar también el import.
Perfecto, guardamos, volvemos y tenemos que dar soporte al Entity a nuestra clase usuario.
Punto class punto porque a buscamos?
Si es así, nable desde este método es así enable from los seleccionamos llega, colocamos el class
que se pasa por argumento.
Entonces si la clase usuario es asignarle a la clase que se esta pasando por argumento a este tipo,
entonces estaría correcto solamente para soportar y para validar que el objeto que estamos validando
o que vamos a leer corresponda al tipo usuario y no otro.
Esto lo quitamos el comentario perfecto.
Bien, lo segundo muy importante es anotar con component para que se pueda inyectar después en el controlador
y validar.
Entonces lo marcamos como componentes Brink.
Se registra y después lo podemos inyectar.
Bien, perfecto.
Acá recibimos el objeto, el target, en este caso del tipo usuario.
Por lo tanto, tenemos que hacer un cast.
Puede quitar esto del tipo usuario igual target, pero con el cast va a ser cast.
Recuerden que con paréntesis usuario y listo.
Acá tenemos el usuario y podemos validar su campo.
Por ejemplo, el nombre, como lo dejamos comentado, el identificador y puede ser con if o como queramos.
Acá validamos.
Lo que sí, tenemos que registrar el error acá.
Por eso se pasa el objeto errors y acá registramos el error con el método Reye Valium.
Pero bueno, ahí lo vamos a ver.
Primero vamos a validar que el nombre no sea ácido.
Es decir.
Esto mismo.
Not empty.
Pero usando la forma de una clase personalizada, entonces podemos utilizar la clase Halpert o de utilidades
princ.
Se llama validacion útiles.
Punto.
Bueno, ya que tiene metodos se fijan Reye if empty.
Esto significa que rechaza la validación con un mensaje de error y estas osea un campo.
Bien, hacemos un clic en raya if empty.
Bueno, también está or espacio en blanco roget if empty or wait space.
Pero después lo vamos a ver.
Primero partamos por este y después vemos la diferencia entre uno y otro.
Bien, primero el objeto error se pasa por argumento.
Primer argumento.
El segundo, el nombre de campo que queremos validar.
Un string nombre mismo nombre que el nombre del atributo acá nombre.
Nombre.
Atributo del objeto usuario se fija y acá?
Bueno, vamos a pasar otro string con el mensaje error, pero no es el mensaje error literal, tiene
que ser el mensaje error que está registrado en el properties.
Por ejemplo, not empty usuario nombre.
Podemos usar este mismo o podríamos crear otra entrada con otro nombre.
Da lo mismo.
Incluso le podríamos poner cualquier nombre en la llave con el texto, pero como ya lo tenemos, podríamos
usar este mismo.
Entonces lo copio.
Y lo pego acá es super simple.
Entonces, con esta clase de utilidad podemos validar.
Bueno, otra alternativa también sería con IFF, por ejemplo.
Esto no es necesario que lo hagan solamente para explicar if, por ejemplo usuario, punto nombre.
Recuerden que con get punto llega tenemos is blank is.
Ente podríamos validar y es cierto.
Entonces si es vacío.
Acá hacemos un reyecito pero utilizando este objeto.
Erros erros.
Punto raya valio.
Porque acá tenemos el reye valio.
El campo nombre y el código.
Error Kot que apunta al properties.
Se fijan entonces esto de acá es prácticamente lo mismo que esto es lo mismo, pero acá es más directo,
se fijan, pueden usar cualquier dos y también tenemos Is blank.
Y acá también es blank.
Es decir, claro, porque podrían escribir nada puro espacio vacío en el nombre.
Entonces con eso también lo valida.
Pero bien, vamos a dejar este que es más directo.
Vamos a quitar este IF y lo vamos a cambiar por otro if porque vamos a validar el identificador entonces.
Usuario.
Punto get identificador por acá.
El objeto Street ya maneja expresiones regulares.
Por acá tenemos matches, acá tenemos el método matches.
Que argumento recibe una expresión regular.
Se fijan, pero ya la tenemos.
Vamos a ir a la clase usuario.
Vamos a copiar esto tal cual, con las comillas.
Incluyendo Comillas, es un string, lo pegamos acá.
Entonces, si toda esta expresión del IF es igual a fours.
Lo mismo erros, punto Reyes Balu, porque lo tenemos.
El nombre campo bueno, en este caso.
Sería identificar este nombre.
Error, Koz, no lo tenemos, no tenemos ningún código de error para identificar, pero no importa,
lo podemos crear.
Por ejemplo, por aquí abajo le vamos a llamar Patten.
Darle un nombre puede ser cualquiera, en este caso porque se coloca el código de forma literal.
Entonces le vamos a colocar Patten todo minuscula o la P con mayúsculas lo mismo.
Punto usuario.
Punto identificar.
Formato de la expresión regular.
Incorrecto, perfecto, y voy a copiar esto tal cual.
Y luego a pegar acá como un strength.
Guardamos acá en Messages Properties y guardamos acá también nuestra clase personalizada.
El balear, y así podremos paliar muchos campos, lo que queramos.
Entonces, una alternativa usando anotaciones.
Otra alternativa es de forma personalizada con la clase validacion útiles Reye if empty.
En fin, diferentes alternativas o de forma más personalizada usando presiones regulares con nuestro
propio algoritmo.
En fin.
Y siempre para rechazar una validación que incorrecta.
Usamos el objeto errors reye válido el nombre el atributo del entity del objeto target en este caso
usuario y el código del error que está registrado en Message Properties y lo tenemos que registrar.
Es decir.
Por cada mensaje error.
Tenemos que colocarlo en el properties.
Bien, igual, igual a FOLS se podría simplificar, por ejemplo, si le quito.
Y acá?
Bueno, esto ya lo saben, pero en el DIF colocábamos la negación sin declamación invertida, dice con
aclamación si es distinto a matches, es decir, si no coincide entonces esto, porque el match lo que
hace, si coincide.
Si está correcto.
Acá tenemos que negar que sea thru o que sea correcto.
O que sea válido esta expresión regular.
Guardamos.
Bueno, lo siguiente el controlador.
Tenemos que utilizar el usuario validad itor que implementa interfaz, pero bueno, para eso lo tenemos
que inyectar.
En este caso lo vamos a inyectar por el tipo concreto, porque es una clase de validador.
No vamos a tener más de una implementación en nuestra aplicación.
Ahora, en caso de que tuviéramos más de una implementación, podríamos crear nuestra propia interfaz
que sea distinta a válida y distinta a la Spring.
Tendríamos que implementar validad Itor de Spring Koma nuestra propia interfaz y ahí podríamos inyectar
por nuestra interfaz, pero la nuestra no la de Spring, porque validad Itor es propia de Spring y podría
haber otros objetos, otro pings, otra clase, batidoras que la implementen.
Entonces, para no tener conflicto con los nombres de componentes en el QUALI, fallen o selector,
es mejor usar una interfaz propia nuestra.
Pero nuestro caso para el ejemplo vamos a inyectar la clase.
El tipo concreto, no la interfaz LaHaye Como digo, la mayoría de las veces vamos a tener un solo validador
o clase válida ahora para el usuario.
Nos vamos a controlador.
El atributo del tipo usuario validador validador importamos.
Atura Importamos.
Perfecto.
Ahí lo tenemos.
Y para variar eso simple, usamos la instancia que se inyecta validador acá.
Entonces por acá.
Punto validad.
Y qué pasamos?
El objeto target, en este caso el usuario este de acá, que se pasa por argumento y errors, error
sería resulto.
Pasamos resulto el bitten resulto al final el Binet resultan bien es del tipo error errors para la validación.
Perfecto, estamos listos.
Hay validamos de forma explícita usando el método Valides, el mismo método que tenemos acá valide acá
pasamos el usuario, el target y acá el result o errors para registrar los errores.
En caso de que no sea válido, en caso de error, de que no cumpla con la validación.
Guardamos, levantamos y probamos.
Nos vamos a el formulario.
Primero voy a quitar John, voy a quitar también identificador validamos enviar formato.
La expresión regular.
Incorrecto.
Perfecto.
El campo nombre no puede ser vacío también.
Tavian Entonces acá.
Por ejemplo, Andrés.
Desaparece.
Así que lo validad bien.
Y acá?
Bueno, cualquiera.
Por ejemplo este de acá.
12.
Punto 3.
Dígito punto 3.
Dígito guión con mayúscula o guión A con mayúscula.
Enviar.
Perfecto.
Se fijan?
Funciona bien.
Lo valía.
Si colocamos la con minúscula.
Enviar incorrecto tiene que ser con mayúscula.
Bueno, y también pueden probar con cualquier tipo de carácter, con coma.
Enviar se fijan, tiene que ser con los puntos.
Bueno, tal cual como en nuestro patrón punto a enviar.
Funciona bien.
Nada más continuamos en la siguiente clase.