Validación en Wisej.NET

Cree el formulario de admisión ValidationClinic en torno a dos oportunidades para detectar errores: cuando el usuario abandona un campo y cuando el usuario guarda. En Wisej.NET, estas comprobaciones funcionan juntas para que un campo intacto no pueda escapar de la validación.

Ejecute comprobaciones rápidas en el evento de Validación, antes de que el usuario continúe. El navegador informa el cambio de enfoque, pero su controlador C sharp se ejecuta en el servidor. Mantener ese controlador breve evita que la navegación normal parezca lenta.

Utilice Validación para decidir si el valor es aceptable. Cancelar el evento y explicar el problema cuando no sea así. Validado sigue solo una verificación exitosa, lo que lo convierte en el lugar apropiado para la limpieza, como recortar un nombre aceptado.

Establezca el comportamiento AutoValidate del formulario en su constructor. En cada controlador, SetError explica un valor rechazado y e.Cancel lo rechaza. Borre el mensaje después de la corrección para que la interfaz refleje el valor actual en lugar de un error anterior.

Mantenga el foco en un campo no válido cuando el usuario necesite corregirlo. Dé a Cancelar una ruta de escape separada configurando CausesValidation en falso. De lo contrario, la validación podría impedir que alguien abandone un formulario incompleto.

Antes de escribir al cliente llame a ValidateChildren desde Save. Esto también verifica los campos que el usuario nunca visitó. Si algún controlador cancela la validación, detenga el guardado; sólo los valores aceptados deben llegar a la operación de escritura y su manejo de excepciones.

Observe cómo el nombre vacío mantiene el foco mientras el icono de error explica el motivo. Después de la corrección, se recorta el nombre aceptado. El correo electrónico con formato incorrecto se rechaza de forma independiente, mientras que Cancelar aún cierra el formulario sin necesidad de corregir ninguno de los campos.

Pruebe Guardar antes de tocar el campo de correo electrónico. ValidateChildren encuentra esa entrada faltante e impide la escritura aunque no se haya producido ningún cambio de enfoque allí. Corrija la dirección y guárdela nuevamente para confirmar que la entrada válida sigue la ruta exitosa.

Para esta práctica de laboratorio, conecte la validación de campos, la limpieza de valores exitosos y la verificación final de Guardar en un formulario de admisión. Prueba Cancelar con entrada no válida también. Su nota de laboratorio debe explicar cómo estas rutas evitan datos incorrectos sin atrapar al usuario.

Envíe comentarios en el formulario de contacto que sigan siendo útiles después del primer error. Un ErrorProvider maneja los íconos, los asistentes reutilizables deciden qué valores no son válidos y un resumen visible permite a los usuarios revisar todos los problemas juntos.

Separe comprobar un valor de mostrar su error. Los administradores de campo independientes pueden dejar íconos obsoletos o borrar mensajes no relacionados. Un enfoque compartido hace que cada corrección afecte al campo relevante preservando al mismo tiempo los problemas que aún necesitan atención.

Elige cómo llega cada mensaje al usuario. SetError agrega un ícono al lado de una entrada, mientras que InvalidMessage proporciona la información sobre herramientas propia del control. El resumen proporciona texto legible para todo el formulario, por lo que los errores no se pueden descubrir simplemente al pasar el cursor.

Configure un único ErrorProvider para el formulario, con íconos fijos ubicados a la derecha. Deje que ValidateEmail devuelva un resultado FieldValidation en lugar de cambiar los controles. Esa separación mantiene la regla reutilizable y deja la presentación a la forma.

Aplicar procesa cada resultado, incluidos los exitosos. Un mensaje vacío elimina el icono antiguo de ese campo; Los resultados no válidos también completan el resumen. Al devolver si se aprobaron todos los resultados, Save tiene una decisión clara antes de escribir cualquier dato.

Relacione los comentarios con el problema. Coloque una corrección de campo al lado de su entrada, explique una regla de negocios en el resumen guardado y brinde un mensaje amigable a una falla del sistema. Los usuarios deben comprender qué acción está disponible para ellos.

Guarde el formulario con los tres campos de contacto no válidos. Compare los íconos locales con el resumen: ambos deberían describir los mismos problemas restantes. La información sobre herramientas del código de cliente muestra la ruta de visualización alternativa sin reemplazar la explicación de todo el formulario.

Corrija solo el correo electrónico y abandone ese campo. Su ícono y entrada de resumen desaparecen, pero el nombre y los mensajes telefónicos permanecen. Esto demuestra por qué los resultados individuales deben borrar errores individuales en lugar de borrar a todo el proveedor.

Cree los asistentes, el ErrorProvider compartido y el método Aplicar como una ruta de retroalimentación. Verifique que corregir un campo preserve otros errores. Compare el código de cliente InvalidMessage con los iconos y el resumen para explicar cuándo es útil cada presentación.

Mueva las reglas de campo repetidas al extensor de validación. En Wisej.NET, describir los requisitos de cada campo permite al extensor ejecutar comprobaciones consistentes para ValidationClinic, mientras que el formulario sigue siendo responsable de presentar comentarios útiles al usuario.

El extensor se conecta a Validating y Validated en los controles. En lugar de repetir la misma verificación de valores vacíos en varios controladores, adjunte metadatos de reglas a cada campo. El flujo del evento sigue siendo familiar mientras las definiciones se vuelven más fáciles de compartir.

Elija una regla integrada para el tipo de valor que acepta, como correo electrónico, número entero, moneda o teléfono. Utilice una expresión regular cuando el patrón requerido lo necesite. Asigne a cada regla un InvalidMessage que explique la corrección en el idioma del usuario.

Agregue Validación en el diseñador, luego abra la colección ValidationRules de un control. Coloque Requerido antes de Correo electrónico. El orden de cobro también es el orden de ejecución, por lo que la organización de estas entradas determina qué explicación recibe primero el usuario.

Un error en una regla detiene las reglas restantes y cancela la validación. Es por eso que un correo electrónico vacío debería fallar. Requerido primero: solicitar una dirección faltante es más útil que informar un problema de formato antes de que exista una dirección.

La configuración del tiempo de ejecución sigue el mismo modelo de reglas. Cree las matrices una vez en ClinicRules, seleccione el destino de visualización y luego asigne cada campo a través de SetValidationRules. Mantener las definiciones juntas evita copias ligeramente diferentes de la misma regla en todos los formularios.

Compare una dirección vacía, una dirección con formato incorrecto y una válida. Cada intento debería producir sólo el primer error aplicable. Cuando el valor se vuelve válido, tanto el icono como la entrada de resumen se borran, lo que confirma que la presentación sigue el último resultado de validación.

Las reglas pueden enviar retroalimentación al control, a un ErrorProvider o a una etiqueta. Elija el objetivo deliberadamente y luego actualice el resumen de los propios eventos del extensor. Esto mantiene el resumen sincronizado con las comprobaciones que realmente se ejecutaron.

Reemplace los controladores repetidos con definiciones ClinicRules compartidas. Mantenga Requerido primero y conecte el resumen a los eventos del extensor. Su prueba debe mostrar que los valores vacíos, con formato incorrecto y corregidos producen el mensaje apropiado sin retener comentarios obsoletos.

Módulo cuatro. Validación personalizada en Wisej.NET. Un formulario puede aceptar valores formateados correctamente que aún infringen las reglas comerciales. Arreglemos eso.

Las reglas integradas verifican la forma de un valor. Pero una fecha válida aún puede venir después de una fecha de finalización, y una fecha de nacimiento válida puede pertenecer a alguien demasiado joven. Éstas son reglas comerciales. Cuando compare campos, calcule una edad o verifique valores juntos, escriba una regla de validación personalizada.

La validación personalizada tiene tres casas. Primero, un método que devuelve un mensaje de error. En segundo lugar, un servicio que devuelve registros ValidationMessage. En tercer lugar, una clase derivada de ValidationRule que ejecuta el extensor de validación. Elija la casa que se ajuste a la responsabilidad de su gobierno.

ValidateStartEndDates devuelve una cadena vacía cuando las fechas son válidas o un mensaje de error cuando no lo son. Aplique ese mismo mensaje a ambos selectores de fechas. El servicio ContactValidator no depende de los controles. Valida el modelo, por lo que puede probar la lógica empresarial sin la interfaz de usuario.

MinimumAgeValidationRule deriva de ValidationRule. Su método OnValidating devuelve verdadero o falso. Adjunte la regla al selector de fecha de nacimiento con SetValidationRules. ApplyModelValidation conecta los resultados del servicio a la pantalla. Asigna nombres de campos a controles, por lo que aparece cada mensaje donde el usuario puede solucionar el problema.

El controlador de guardado ejecuta la validación en orden. Primero, verifique las reglas de campo. Luego ejecute el servicio de validación y la regla de fecha. Regrese temprano si falla alguna capa. Llame al repositorio solo después de que pase cada verificación. La base de datos nunca debe recibir datos que su validación ya haya rechazado.

Ahora intenta guardar con la fecha de inicio después de la fecha de finalización. Ambos selectores muestran el mismo error y el resumen muestra un solo mensaje.

Corrija la fecha de finalización. Ambos errores se aclaran juntos. Debido a que esta regla compara dos valores, ambos controles comparten la retroalimentación.

Introduzca una fecha de nacimiento a partir de veintiún once. La regla de edad mínima la rechaza tan pronto como el usuario abandona el selector.

Corrija la fecha de nacimiento y el error desaparecerá. Guardar ahora ejecuta cada capa de validación con éxito y luego almacena el contacto exactamente una vez.

Para el laboratorio cuatro, implemente la verificación de fecha, el servicio de validación, la asignación de mensajes y la regla de edad mínima.

Conéctelos en un controlador de guardado que nunca guarda datos no válidos.

Módulo cinco. Validación vinculada a datos en Wisej.NET. El formulario de admisión ahora edita un modelo de edición de contacto. Sus reglas básicas de validación pertenecen a los datos, por lo que las mismas reglas pueden proteger el formulario, la cuadrícula y otras formas de cambiar un contacto.

Un controlador de formulario solo protege los cambios realizados a través de ese formulario. Una cuadrícula, una importación o un servicio pueden actualizar el mismo contacto sin ejecutar esos controladores. Coloque las reglas básicas en el modelo, luego haga que cada ruta de guardado las ejecute antes de aceptar los datos.

Primero, finalice la edición actual. Es posible que el valor que aún se está escribiendo no haya llegado al modelo todavía. Llame a End Edit en la fuente de enlace de contacto antes de validar. De lo contrario, el validador podría verificar un valor anterior aunque el usuario ya haya corregido el campo.

Las anotaciones de datos describen las reglas, pero no se ejecutan por sí mismas. Try Validate Object los aplica y recopila los resultados. Establezca validar todas las propiedades en verdadero. Sin esa opción, solo se marca Requerido, por lo que podría pasar un correo electrónico con formato incorrecto o una edad fuera de rango.

El validador devuelve nombres de propiedades, no controles. Utilice un mapa de campo para conectar cada resultado con la entrada correcta. Coloque el mensaje al lado de esa entrada y en el resumen. Si una propiedad no tiene ningún control coincidente, mantenga su mensaje en el resumen para que el error siga siendo visible.

Hay otro enfoque. Un modelo que implementa I Data Error Info responde preguntas de validación para cada propiedad. Un proveedor de errores vinculado a datos lee esas respuestas. Al cambiar de origen en tiempo de ejecución, Bind To Data And Errors establece el origen y el miembro juntos, evitando una discrepancia temporal.

Intente guardar el contacto no válido. End Edit primero confirma la entrada actual al modelo. Las comprobaciones de anotaciones rechazan el nombre, el correo electrónico y la edad. El mapa de campo coloca cada mensaje al lado de su entrada y en el resumen. La ruta de guardado se detiene antes de escribir algo.

Corrija los valores y guárdelos nuevamente. Las comprobaciones ahora pasan y el contacto se guarda. En el modelo I Data Error Info, al borrar el nombre, el icono de error vuelve a aparecer a través del enlace de datos. No es necesario que el formulario llame a Set Error para ese cambio.

Para la práctica cinco, vincule el editor al modelo, finalice las ediciones antes de validar y asigne los resultados de las anotaciones a los campos y al resumen. Luego conecte el modelo I Data Error Info a través de Bind To Data And Errors. Verifique que los datos no válidos nunca lleguen al repositorio.

La cuadrícula de contactos presenta una ruta de edición diferente a la del formulario de admisión. Una celda tiene su propio editor y eventos de validación, así que reutilice la misma intención comercial a través de controladores de cuadrícula en lugar de esperar que se ejecuten los controladores de campo de texto del formulario.

Separe los tres problemas antes de elegir un manejador. El formato del correo electrónico pertenece a la celda, la edad no numérica puede fallar en la conversión y un contacto cerrado sin una fecha de cierre viola una regla en todos los campos. Un solo cheque no puede explicar los tres de manera confiable.

Durante la edición, valide e.FormattedValue porque contiene lo que el usuario está escribiendo ahora. El Value almacenado en la celda todavía representa la entrada confirmada anterior. Verificar ese valor anterior podría aceptar el mismo error que acaba de introducir el usuario.

Utilice el nombre de la columna para seleccionar la regla en CellValidating. Borre el mensaje anterior de esa celda, inspeccione el valor editado y cancele con una explicación clara cuando falle. Esto mantiene al usuario al lado de la entrada que necesita corrección.

Coloque un error de valor único en la celda y un error de relación en la fila. Reserve DataError para errores de conversión o guardado que informe la grilla. Omita el marcador de posición de la nueva fila, ya que aún no es un contacto que requiere validación.

ValidateRow actualiza el mensaje de fila y la celda de fecha de cierre juntos, haciendo que la relación sea visible en ambos niveles. En DataError, explique las fallas de conversión en lenguaje común y registre la excepción por separado para que el diagnóstico no sea responsabilidad del usuario.

Pruebe primero con el correo electrónico con formato incorrecto: la validación mantiene la edición en su lugar y muestra el error de celda. Luego ingrese letras para la edad. El amigable mensaje de conversión demuestra una ruta de error diferente, aunque ambos errores ocurrieron al editar una celda.

El contacto cerrado aún no puede guardar hasta que esté presente la fecha de cierre requerida. El error de fila mantiene esa relación visible, mientras que se ignora el marcador de posición. Ingrese la fecha y guárdela nuevamente para verificar que corregir la regla permita la persistencia.

Cree comprobaciones de cuadrícula en torno al valor editado actual, las relaciones de filas y los errores de conversión amigables. Borre los errores de celda exitosos y proteja Guardar contra fallas restantes. Pruebe cada capa por separado para que una celda válida no pueda ocultar una fila de contacto no válida.

Lleve las comprobaciones ValidationClinic a una única ruta de guardado. La validación de campo, modelo, negocio y red ahora deben cooperar en Wisej.NET, por lo que una verificación exitosa en una capa nunca pasa por alto un problema no resuelto en otra.

Los validadores individualmente correctos no garantizan un guardado correcto. Una edición pendiente puede dejar el modelo obsoleto o es posible que un error de cuadrícula nunca llegue a las comprobaciones del formulario. Coloque las etapas en un orden fijo y exija que cada etapa tenga éxito.

Restablezca los comentarios y finalice la edición actual antes de verificar los campos, el modelo, las reglas comerciales y las filas de la cuadrícula. Deténgase en la primera etapa fallida. Esta secuencia evita que se ejecute trabajo posterior con entradas no válidas y mantiene la escritura final detrás de todas las comprobaciones.

Utilice el contrato IErrorProvider para enviar mensajes sin vincular la validación a una pantalla. SummaryErrorProvider conserva un mensaje para cada control y oculta su etiqueta cuando no queda ninguno. Por lo tanto, el resumen puede reflejar los mismos errores que los comentarios de campo.

Regrese temprano cuando falle la validación del campo o del modelo. Si el resultado final guarda, distinga un nombre duplicado que el usuario pueda corregir de una falla del sistema que no pueda corregir. Enrute el duplicado a su campo y explique otras fallas con calma.

Revise los comentarios como parte del flujo de trabajo, no solo como texto de error. Explique la corrección cerca del campo y en el resumen, conserve Cancelar y mantenga rastros técnicos fuera de los mensajes de los usuarios. Pruebe las entradas faltantes, no válidas, válidas y de límites.

Primero, el nombre que falta y el correo electrónico con formato incorrecto detienen el guardado durante la validación del campo. Corrija esos campos y vuelva a intentarlo. Luego, el modelo rechaza la edad de ciento treinta años, mostrando por qué pasar las verificaciones de campo no hace que las verificaciones posteriores sean opcionales.

La etapa de cuadrícula detecta los problemas restantes de correo electrónico y de fila cerrada, y el resumen explica ambos. Después de esas correcciones, cada etapa tiene éxito y se completa el guardado. La confirmación final ahora significa que se pasó todo el camino de validación.

Entregue la ruta de guardado completa con el proveedor de resumen y el asistente de mensajes compartidos. Incluya un manejo de excepciones que distinga las entradas corregibles de las fallas del sistema. Documente los casos de prueba para que otro desarrollador pueda reproducir tanto los guardados bloqueados como las correcciones exitosas.