Bien, pero se puede mejorar un poco más?
Claro, por supuesto que sí, porque el formulario también de forma automática se mapea a una clase
POJO, por ejemplo, al usuario se podría mapear siempre cuando los campos del formulario lo naïve Yussef
en password y mail o cualquier campo atributo que tenga coincida con los nombre atributos de la clase
de tu objeto POJO.
Bueno, por supuesto que se va a mapear y se van a poblar los datos cuando se envía.
Entonces, claro, podríamos quitar esto.
El new usuario y todo acá los Shet y todo esto y este objeto usuario lo pasamos por argumento.
Acá por ejemplo, voy a cortar esto.
El tipo y el usuario lo corto y lo dejamos acá como primer argumento.
Primer argumento coma.
Después vienen Modell.
Esto lo podemos quitar.
Se fijan y esto no será necesario.
Lo podemos dejar, pero si no lo vamos a ocupar de forma manual, estos parámetros del rico se separan,
lo quitamos total, igual se pueblan acá de forma automática.
Entonces todo esto acá lo rico es para lo podría Mezquital, se fijan.
Queda mucho más limpio, mucho más simple y mucho más automatizado.
Los import.
Bueno, esto lo puedo quitar ahora, claro, yo estoy modificando el código, si quieren ustedes lo
comentan.
Yo estoy quitando estas líneas.
La pueden comentar?
No hay ningún problema, lo pueden dejar.
También se fijan que queda mucho más limpio, mucho más automatizado.
Por lo tanto, se envía el formulario, se recibe el usuario, automáticamente se pueblan los datos
de los campos cuando coinciden los atributos.
Pero sí es importante que tenga presente en el POJO entre clase, usuario, los lletra, etcétera.
Muy importante los sets, sobretodo para poblar los datos.
Y acá lo recibimos y lo pasamos a la vista.
Vamos a probar.
Voy a levantar de que lo tengo abajo, con click derecho, como siempre.
El resultado debía ser exactamente igual, pero con menos líneas de código, mucho más limpio y automatizado.
Bueno, la ventaja de utilizar un framework ya localhost.
Recuerden que form.
Así que acá tira el 404 for defecan.
Bueno Yussef Username, Andrés Password cualquiera y el correo también cualquiera.
Envianos se fijan.
Funciona perfecto.
Se puede de forma automática.
Bien, volviendo acá al formulario, voy a actualizar si hago clic por ejemplo en password en el label
automáticamente se posiciona el cursor en el input.
Si hago clic en el Yussef Nep acá se fijan en correo acá.
Bueno, eso es lo que hace el for a través de Heidy del campo esta enlazado, se fijan, pero algo funcional
nada más.
Aunque también puedes equili directamente en el input, pero también en el label se fijan.
Eso es todo.
Bueno, y el correo es del tipo texto.
Qué pasa si el tipo email vamos a cambiar?
Vamos a la vista formulario por acá, tipo email, guardamos, volvemos, actualizamos, refresh o f5
como quieran.
Y por ejemplo acá coloco cogé cosa que no sea un correo.
Se fijan?
Acá dice, es decir, de forma automática antes de realizar el Summit lo valida.
Entonces, por ejemplo, completo con cualquier cosa.
Andrés y el correo de cualquier cosa.
Y no me deja, no me deja enviar incluye.
Es decir, debe incluir un signo arroba es una dirección electrónica, es decir, está legando por el
formato se fijen.
Entonces, si agregamos el arroba, cualquier cosa.
Ahora sí que lo valida.
Se fijan?
Eulàlia.
Bueno, eso es lo que hace el atributo email.
Una validación del formato del correo.
Pero esta forma vamos a validar por el lado de Spring y no por el lado cliente, aunque podríamos dejar
las dos, pero para poder revisar y chequear en el lado del paquete de Spring vamos a quitar el email
para que nos valide en el cliente.
Si no por sprint, entonces lo dejamos estar como estaba de tipo texto, porque después a partir de
la próxima clase vamos a comenzar con el tema de validación.
Nada más.
Nos vemos.