1
00:00:00,390 --> 00:00:04,290
Bien, en esta clase vamos a agregar la validación del formulario.

2
00:00:04,410 --> 00:00:10,890
Vamos a usar anotaciones en la clase Entity a través del estándar de validación de Java, también conocido

3
00:00:10,890 --> 00:00:13,480
como la especificación Beans Valid.

4
00:00:13,490 --> 00:00:15,690
De hecho, nos vamos a la clase Entity.

5
00:00:18,180 --> 00:00:22,710
Y por ejemplo, por cada campo, por el nombre, el apellido, el email, la fecha.

6
00:00:22,740 --> 00:00:29,400
Podemos anotar con reglas de validación propias del estándar, por ejemplo, todo lo que sea del tipo

7
00:00:29,400 --> 00:00:29,790
String.

8
00:00:30,150 --> 00:00:35,450
Podemos anotar que sean requeridas usando la anotación Not empty.

9
00:00:37,200 --> 00:00:41,730
Entonces empty es básicamente que sea requerido el campo.

10
00:00:41,880 --> 00:00:48,630
Anotamos importante Yaks Valid Echols Constraint, que es el estándar y Vernet de precaver.

11
00:00:48,900 --> 00:00:50,700
Tenemos que utilizar ya Bax Valid.

12
00:00:50,700 --> 00:00:54,210
De hecho, por lo menos en Spring puntos importamos.

13
00:00:54,270 --> 00:00:59,220
Vamos a copiar y también NMI porque son del tipo String.

14
00:00:59,760 --> 00:01:05,970
Entonces por detrás va a validar que el string sea distinto de ácido, que el largo sea mayor que 0.

15
00:01:06,000 --> 00:01:10,860
Por lo tanto, que al menos escribamos uno o más caracteres en el campo.

16
00:01:11,310 --> 00:01:16,920
Bien, pero qué pasa con el tipo de con tipos que son de otras clases distinta del string?

17
00:01:17,260 --> 00:01:22,830
Hoy podemos validar que sea distinto de nulo con not null.

18
00:01:23,010 --> 00:01:25,450
Importamos también de yaks validacion.

19
00:01:26,220 --> 00:01:29,460
Ven válida que la fecha no sea nula.

20
00:01:29,550 --> 00:01:31,660
Básicamente sea distinta.

21
00:01:31,680 --> 00:01:31,920
Nula.

22
00:01:32,280 --> 00:01:38,670
Entonces la diferencia en Not Empty solamente se utiliza con string con cadenas para que sea requerido

23
00:01:38,790 --> 00:01:40,080
y todos los demás tipos.

24
00:01:40,170 --> 00:01:46,800
Por ejemplo, un tipo doit incluso también puede ser un tipo de otra clase Entity o un tipo numérico

25
00:01:46,830 --> 00:01:51,300
como un decimal, un big decimal, un double, un float.

26
00:01:51,420 --> 00:01:52,920
Podemos balear con not null.

27
00:01:52,980 --> 00:01:55,350
Solamente los string con not empty.

28
00:01:55,470 --> 00:01:56,190
Esa diferencia.

29
00:01:56,280 --> 00:02:02,880
Porque por ejemplo, si anotamos con un null en un string, por ejemplo, el nombre nunca se va a aplicar

30
00:02:02,940 --> 00:02:03,540
esa validación.

31
00:02:03,570 --> 00:02:04,110
Por qué?

32
00:02:04,170 --> 00:02:05,710
Porque un string.

33
00:02:05,880 --> 00:02:09,780
Incluso si en el campo no escribimos nada, lo dejamos vacío.

34
00:02:09,840 --> 00:02:15,810
Cuando se envía ese string es con carácter cero, pero no es nulo, es distinto, nulo.

35
00:02:15,840 --> 00:02:17,730
Por lo tanto, no se va a validar.

36
00:02:17,820 --> 00:02:25,170
Por eso tenemos que validar que el string tenga caracteres mayor que 0 sea requerido con Not empty bien

37
00:02:25,400 --> 00:02:26,660
y email.

38
00:02:26,910 --> 00:02:29,910
También queremos validar que el formato sea correcto.

39
00:02:29,970 --> 00:02:31,740
Un formato de correo electrónico.

40
00:02:32,910 --> 00:02:33,940
Anotamos con email.

41
00:02:34,170 --> 00:02:39,860
Podemos importar también el estándar porque si usamos internet es de preset.

42
00:02:39,930 --> 00:02:46,860
Por ejemplo, lo de marcar realmente para el ejemplo se marca como despégate en amarillo se fijan el

43
00:02:46,860 --> 00:02:52,230
tipo email de precaver, ya que lo estamos importando del paquete de internet.

44
00:02:52,500 --> 00:03:00,000
Voy a volver atrás y voy a importar de jabas valid, hecho que es el estándar perfecto.

45
00:03:00,240 --> 00:03:01,650
Hoy lo porta correctamente.

46
00:03:01,770 --> 00:03:08,700
Entonces, por lo menos en Spring puntos siempre tenemos que importar de yaks, Validacion Constraint,

47
00:03:08,850 --> 00:03:11,850
el email y también el Not Empty y todo lo demás.

48
00:03:13,850 --> 00:03:20,120
Bueno, y qué pasa si quiero validar que un string, por ejemplo el nombre, el apellido, esté dentro

49
00:03:20,120 --> 00:03:23,330
de un rango, por ejemplo, entre 4 y 12 caracteres?

50
00:03:23,420 --> 00:03:25,910
Bien, ahí podemos usar la notación 6.

51
00:03:26,270 --> 00:03:28,610
No es necesario que lo hagan solamente para explicar.

52
00:03:28,670 --> 00:03:31,850
Para el ejemplo 6 voy a importar.

53
00:03:32,090 --> 00:03:38,990
Acá tenemos el atributo mínimo 1000 igual a cuatro coma máximo igualados.

54
00:03:39,110 --> 00:03:41,990
Entonces el nombre va a estar entre 4 y 12 caracteres.

55
00:03:43,460 --> 00:03:45,470
Y así tenemos muchas anotaciones más.

56
00:03:45,710 --> 00:03:49,770
Pero para el ejemplo voy a dejar solamente not empty.

57
00:03:50,150 --> 00:03:54,970
Y también el email y la fecha con nube y estamos listos.

58
00:03:54,980 --> 00:03:55,880
Vamos a guardar.

59
00:03:56,020 --> 00:03:58,610
Cliente Nos vamos al controlador.

60
00:03:59,370 --> 00:03:59,570
Ven.

61
00:03:59,630 --> 00:04:06,830
Es importante, fundamental en el método Guardar que recibe el objeto mapeado al formulario.

62
00:04:06,980 --> 00:04:08,000
En este caso, el cliente.

63
00:04:08,540 --> 00:04:12,580
Acá tenemos que habilitar la validación para que se valida el client.

64
00:04:12,770 --> 00:04:14,360
Para eso usamos Valli.

65
00:04:15,590 --> 00:04:16,780
Importamos de yaks.

66
00:04:16,880 --> 00:04:17,630
Validación.

67
00:04:18,500 --> 00:04:20,180
Bien, este paso es importante.

68
00:04:20,630 --> 00:04:25,970
Tenemos que anotar con Paly en el argumento que se recibe el objeto de formulario.

69
00:04:26,550 --> 00:04:33,440
Bien, pero claro, si falla el formulario, tenemos que validar que preguntar si contiene errores.

70
00:04:33,560 --> 00:04:35,600
Si contiene errores es porque falló.

71
00:04:35,730 --> 00:04:42,800
Ahí tenemos que cargar la vista formulario y volver a la plantilla del formulario con mensaje de error.

72
00:04:42,920 --> 00:04:46,040
Mostrar estos mensajes al usuario para que los corrija.

73
00:04:46,220 --> 00:04:49,640
Bien, para eso tenemos que agregar otro objeto.

74
00:04:49,730 --> 00:04:58,190
Como argumento del método Binding resulto importamos de Spring Validación.

75
00:05:00,220 --> 00:05:08,080
Y a través del resultado, mediante un if, por ejemplo, if result si contiene errores en plural,

76
00:05:08,260 --> 00:05:13,840
haz errors, entonces acá manejamos cuando ocurre el error.

77
00:05:13,930 --> 00:05:22,000
Por ejemplo, retornamos la vista del formulario con todos los mensajes de error y si todo sale bien,

78
00:05:22,070 --> 00:05:26,290
bueno, guardamos al cliente con nuestro dado bien.

79
00:05:26,350 --> 00:05:30,490
Un detalle aparte que es bien importante que lo tengan presente.

80
00:05:30,940 --> 00:05:35,770
El binding result siempre va junto al objeto del formulario.

81
00:05:35,830 --> 00:05:36,770
En este caso el cliente.

82
00:05:37,030 --> 00:05:42,310
Estos dos tienen que ir siempre junto como argumento el método uno al lado del otro.

83
00:05:42,430 --> 00:05:48,970
Primero el objeto que está mapeado, en este caso el cliente koma, el binding result y después lo demás

84
00:05:49,000 --> 00:05:49,520
parámetros.

85
00:05:49,540 --> 00:05:56,140
Por ejemplo, el model y todo lo demás que tengamos siempre estos dos van juntos.

86
00:05:56,500 --> 00:05:57,340
Bien, continuemos.

87
00:05:57,430 --> 00:06:04,210
Si falla, también tenemos que pasar el título, ya que el formulario lavista tiene el atributo título,

88
00:06:05,560 --> 00:06:12,970
entonces con atributo y pasamos formulario de cliente como valor.

89
00:06:13,510 --> 00:06:14,830
Bien, pero qué pasa con el cliente?

90
00:06:14,980 --> 00:06:21,700
Acá pasamos el cliente también en el formulario y acá nos lo estamos pasando, pero en realidad lo pasa

91
00:06:21,790 --> 00:06:25,010
de forma automática al formulario cuando falla.

92
00:06:25,090 --> 00:06:31,690
Pero siempre y cuando acá hay una regla que importante, cuando el tipo de la clase, en este caso el

93
00:06:31,690 --> 00:06:38,520
cliente, el nombre de esta clase se llame igual que el nombre con el cual lo estamos pasando a la vista

94
00:06:38,620 --> 00:06:39,090
cliente.

95
00:06:39,130 --> 00:06:45,190
Si se llama cliente y la clase cliente está todo bien, lo pasa de forma automática, sin tomar en cuenta

96
00:06:45,310 --> 00:06:50,620
que las clases comienzan con mayúscula y que el atributo se escribe completamente minúscula sin tomar

97
00:06:50,620 --> 00:06:50,980
en cuenta.

98
00:06:50,980 --> 00:06:53,140
Eso sí, se llama igual está todo perfecto.

99
00:06:53,260 --> 00:06:55,780
Ahora, qué pasa si se llamase distinto?

100
00:06:55,900 --> 00:07:01,840
Bueno, hoy tenemos que indicar el nombre con el cual lo estamos pasando la vista a través de la anotación

101
00:07:01,900 --> 00:07:02,750
modal atributo.

102
00:07:03,130 --> 00:07:10,660
Entonces, al lado del cliente o del tipo con model atributo, importamos.

103
00:07:11,110 --> 00:07:13,900
Esto no es necesario que lo hagan solamente para explicar.

104
00:07:13,990 --> 00:07:18,160
Así que esto no lo haga, ya que la clase se llame igual no sería necesario.

105
00:07:18,190 --> 00:07:24,400
Pero si se llama distinto, acá en los paréntesis indicamos el nombre con el cual lo pasamos a la vista.

106
00:07:24,430 --> 00:07:29,920
Por ejemplo, si lo pasamos como cliente, otro acá hoy día el cliente otro, es decir, acá mismo,

107
00:07:29,920 --> 00:07:31,690
nombre con el que le pasamos a la vista.

108
00:07:32,130 --> 00:07:37,270
Bueno, en nuestro caso se llama igual client, así que se lo dejamos de forma explícita.

109
00:07:37,390 --> 00:07:40,840
Igual va a funcionar, pero sería redundante.

110
00:07:41,060 --> 00:07:46,210
Bien, vamos a dejar como estaba, ya que se llama igual.

111
00:07:46,240 --> 00:07:48,070
Por lo tanto se pasa de forma automática.

112
00:07:48,160 --> 00:07:53,740
No es necesario el modal atributo listo y estamos completamente listo con el controlador, con el método

113
00:07:53,740 --> 00:07:54,160
guardar.

114
00:07:54,220 --> 00:07:57,820
Estamos validando si todo sale bien, guardamos si falla.

115
00:07:57,880 --> 00:08:00,310
En el caso erros pasamos el título.

116
00:08:00,430 --> 00:08:03,440
El cliente se pasa de forma automática al modelo Attribute.

117
00:08:03,550 --> 00:08:07,720
Cargamos la vista y vamos a mostrar el mensaje de error al usuario.

118
00:08:07,930 --> 00:08:13,120
Guardamos y nos vamos a la vista a la plantilla en recursos template formulario.

119
00:08:14,170 --> 00:08:19,570
Entonces acá por cada campo, por el nombre, apellido y mail y la fecha, tenemos que mostrar el mensaje

120
00:08:19,570 --> 00:08:19,840
error.

121
00:08:19,900 --> 00:08:26,860
Para eso utilizamos, utilizamos la etiqueta small o cualquiera puede ser small o label.

122
00:08:26,980 --> 00:08:32,140
Básicamente usos moll para que se vea un poco más pequeño, no más un detalle bien, pero bueno, con

123
00:08:32,170 --> 00:08:40,210
Taine LIF acá tenemos que validar, preguntar con TH if con este atributo esta directiva preguntar de

124
00:08:40,210 --> 00:08:47,980
alguna forma si este campo nombre contiene errores antes de mostrarlos, pero para eso tan LIF tiene

125
00:08:48,070 --> 00:08:53,410
objetos que son kelpers para trabajar en la validación en el formulario.

126
00:08:53,500 --> 00:09:03,700
Por ejemplo, el objeto fields en plural termina en s es importante fields punto jass errors también

127
00:09:03,790 --> 00:09:12,340
en plural si contiene errores as errors paréntesis indicamos el nombre del atributo.

128
00:09:13,390 --> 00:09:18,550
En este caso nombre bien y si contiene errores, tenemos que mostrar este error.

129
00:09:18,670 --> 00:09:27,430
Este texto th errors también en plural th errors igual asterisco la llave.

130
00:09:27,640 --> 00:09:34,030
Por qué hacemos referencia al campo al atributo que este mapeado a la clase entity nombre igual que

131
00:09:34,030 --> 00:09:35,570
acá, igual que en Field.

132
00:09:39,050 --> 00:09:48,920
Lo mismo acá mostramos el error correspondiente al campo nombre, faltaría una clase de vostra para

133
00:09:48,920 --> 00:09:50,180
que el texto esté de color rojo.

134
00:09:51,650 --> 00:09:55,400
Usamos el estilo form text y text danger.

135
00:09:56,670 --> 00:10:03,650
Bien, entonces ahora vamos a copiar esto mismo por cada input justo debajo para el apellido.

136
00:10:09,380 --> 00:10:10,130
Para el email.

137
00:10:16,150 --> 00:10:18,040
Y también para la fecha cred at.

138
00:10:23,050 --> 00:10:26,050
Bien, problemas en el input por cada campo.

139
00:10:26,140 --> 00:10:30,310
Podemos pintar también de color fondo rojo con un margen rojo.

140
00:10:30,430 --> 00:10:31,870
Además del texto.

141
00:10:31,960 --> 00:10:35,810
Para eso usamos el atributo details diff error class.

142
00:10:37,510 --> 00:10:38,140
Todo junto.

143
00:10:38,140 --> 00:10:39,430
Todo en minúsculas.

144
00:10:40,060 --> 00:10:42,190
Igual comilla simple.

145
00:10:42,280 --> 00:10:47,980
Dentro de la comilla doble indicamos el nombre del estilo de la clase de vostra.

146
00:10:48,100 --> 00:10:57,040
En este caso fueron control para mantener el mismo estilo del input form control y además alert danger.

147
00:10:58,900 --> 00:11:01,240
Vamos a copiar esto por cada uno.

148
00:11:02,810 --> 00:11:06,170
En el apellido, en el e-mail y en la fecha.

149
00:11:06,420 --> 00:11:07,460
Bien, estamos listos.

150
00:11:07,580 --> 00:11:08,510
Vamos a guardar.

151
00:11:10,280 --> 00:11:11,150
Íbamos a probar.

152
00:11:19,780 --> 00:11:24,460
Bien, nos vamos a la página del formulario y vamos a enviar, se fijan?

153
00:11:24,490 --> 00:11:25,090
Perfecto.

154
00:11:25,180 --> 00:11:27,490
Acá pinta cada campo de color rojo.

155
00:11:27,970 --> 00:11:31,360
Y el mensaje no puede estar vacío por cada campo.

156
00:11:31,450 --> 00:11:33,820
Y el último, la fecha no puede ser nula.

157
00:11:33,940 --> 00:11:34,330
No puede ser.

158
00:11:34,330 --> 00:11:35,800
No ven estos mensajes.

159
00:11:35,890 --> 00:11:37,660
Después lo podemos personalizar.

160
00:11:37,780 --> 00:11:43,300
Después, en la próxima clase, vamos a ver cómo personalizar estos textos de error de forma automática.

161
00:11:43,430 --> 00:11:46,900
Spring De acuerdo a nuestra localización.

162
00:11:47,020 --> 00:11:55,000
De acuerdo al Time, Son va a mostrar los textos en el idioma correspondiente a nuestro país, a nuestra

163
00:11:55,060 --> 00:11:55,510
zona.

164
00:11:55,600 --> 00:11:56,950
Pero bien, cómo explicaba esto?

165
00:11:56,950 --> 00:11:58,150
Se puede personalizar?

166
00:11:58,270 --> 00:12:01,330
Estos son los mensajes mensaje queda por defecto bien colocamos Andrés

167
00:12:04,570 --> 00:12:08,080
Crear cliente perfecto valida nombre y apellido correctamente.

168
00:12:08,110 --> 00:12:09,350
Qué pasa con el email?

169
00:12:09,730 --> 00:12:15,730
Está validando bien para que sea requerido, pero si escribimos un correo invalido, cualquier cosa

170
00:12:16,780 --> 00:12:20,290
acá está validando con HTML5 y no con sprint.

171
00:12:20,410 --> 00:12:20,800
Por qué?

172
00:12:20,830 --> 00:12:29,440
Porque nos vamos a la dicta el tipo input del tipo email HTML5 al ser del tipo de email válida automáticamente

173
00:12:29,440 --> 00:12:32,510
que sea un correo, un correo bien formateado.

174
00:12:33,220 --> 00:12:38,650
Entonces, para poder probar con Spring la validación y mail que vimos en la clase cliente, tenemos

175
00:12:38,650 --> 00:12:40,530
que cambiar al type text.

176
00:12:40,930 --> 00:12:44,800
Vamos a guardar, tenemos que volver a cargar nuestro formulario.

177
00:12:45,730 --> 00:12:52,930
No vamos a cliente crear cliente Andrés Guzmán Cualquier cosa crea cliente perfecto.

178
00:12:52,990 --> 00:12:55,720
Ahora sí que está goleando por el lado de Spring.

179
00:12:55,960 --> 00:13:02,710
No es una dirección de correo bien formada, claro, le falta la година y le falta el nombre del dominio,

180
00:13:03,190 --> 00:13:03,790
por ejemplo.

181
00:13:03,850 --> 00:13:04,190
Hola!

182
00:13:04,420 --> 00:13:06,580
Punto com crear.

183
00:13:06,610 --> 00:13:07,240
Perfecto.

184
00:13:07,600 --> 00:13:09,610
Ahora, qué pasa si omitimos el punto com?

185
00:13:10,330 --> 00:13:17,080
Bueno, si lo omitimos también es un email correcto, válido porque hay mucha corporaciones que contienen

186
00:13:17,080 --> 00:13:22,060
correos corporativos sin extensión, sin el punto com, sin el punto, lo que sea.

187
00:13:22,150 --> 00:13:25,330
Entonces si colocamos crea cliente se valida perfecto.

188
00:13:25,720 --> 00:13:26,260
Es válido.

189
00:13:26,560 --> 00:13:31,030
Lo importante que tenga el nombre, el arroba y el dominio.

190
00:13:32,450 --> 00:13:33,380
Qué pasa con la fecha?

191
00:13:33,500 --> 00:13:39,470
Otro tema también un poco más complicado, porque tienen un formato válida que no puede ser nula.

192
00:13:39,510 --> 00:13:43,970
Pero si colocamos cualquier cosa, obviamente va a fallar.

193
00:13:44,090 --> 00:13:49,190
El problema es que el mensaje es bien duro por decir es bien feo al cliente final.

194
00:13:49,340 --> 00:13:55,220
La idea es que este tipo de mensajes se puedan personalizar y mostrar algo mucho más amistoso al usuario

195
00:13:55,220 --> 00:13:55,550
final.

196
00:13:55,820 --> 00:14:00,680
Pero esto lo vamos a ver la próxima clase con lo vamos en la fecha valia.

197
00:14:03,290 --> 00:14:09,650
Bueno, si colocamos con Latch año, mes, día, pero con esa larch también va a fallar.

198
00:14:09,800 --> 00:14:10,370
Por qué?

199
00:14:10,490 --> 00:14:12,800
Revisemos nuestro código cliente.

200
00:14:13,340 --> 00:14:15,080
Acá tenemos el data, informan.

201
00:14:15,230 --> 00:14:18,530
Lo indicamos con año, mes, día, pero separado con guión.

202
00:14:18,920 --> 00:14:23,270
Entonces, como Estaco se larch, obviamente el formato también es incorrecto.

203
00:14:23,330 --> 00:14:30,290
Si enviamos falla, entonces nuevamente la idea de colocar un mensaje amistoso que diga al usuario que

204
00:14:30,290 --> 00:14:34,730
la fecha de tener el siguiente formato y mostrar un ejemplo del formato.

205
00:14:36,140 --> 00:14:42,620
Por ejemplo, con guión Yaí lo haría perfecto y guarda el nuevo cliente.

206
00:14:42,860 --> 00:14:43,100
Bien.

207
00:14:43,190 --> 00:14:44,870
Así que por ahora nada más.

208
00:14:44,990 --> 00:14:50,480
Y la próxima clase continuamos con personalizar estos mensajes de errores del formulario.

209
00:14:50,660 --> 00:14:51,500
Hasta la próxima.