En primavera, después de la validación obtenemos un objeto BindingResult en el controller.de primavera: ¿Cómo resolver un error de validación -> código de error -> mensaje de error
Bastante simple, si me da errores de validación que desea volver a mostrar mi forma con el mensaje de error anterior cada campo afligidos.
Así que para comprobar si hay errores de campo en el campo de mi usernameFormObject Me llaman:
FieldError usernameFieldError = bindingResult.getFieldError("username");
Grande, ahora sostienen un objeto FieldError el que, en el supuesto que estoy usando el DefaultMessageCodeResolver ahora contiene algo así como 4 error posible códigos.
¿Cómo voy desde FieldError -> Una cadena que es consumible para el usuario?
Tengo un MessageSource definido en mi contexto de aplicación web, por lo que puedo asignar un solo código de error a un mensaje.
Pero a veces el mensaje por defecto será mejor, ya veces esperar que dos de los códigos de error puede tener un mensaje relevante, así que tenemos que escoger la mejor opción.
¿Qué método debo utilizar para determinar el mejor posible mensaje de error para presentar un error de campo?
- ¿Debo escribir algún algoritmo para revisar todos los códigos de error y elegir uno de los más específicos?
- ¿Proporciona la primavera algún soporte para ayudar a determinar el mensaje de error más específico?
- Todo este proceso parece tan larga y complicada, pensé que la primavera se supone que debe hacer esta materia fácil. Tal vez estoy totalmente fuera de base de alguna manera?
Oooh, ya veo, no coger MessageSource.get (MessageSoureResolvable, ...), sólo se dio cuenta de la get (String, ...) opciones, que es el vínculo clave (De hecho, probablemente lo noté y lo perdí en la miríada de detalles que nos perdemos al aprender un nuevo framework/api). ¡¡Gracias!! –
Punto interesante sobre el taglib de JSP, estoy usando Velocity, pero Spring ofrece el mismo en forma de macro. Pero aún no lo he empleado, ya que me pareció bastante anti-resorte vincular incluso la presentación de mi vista al marco de primavera. Pensé que era suficientemente malo que mi controlador ahora llame al MessageSource específico de primavera en lugar de un ResourceBundle estándar de Java.Pero tal vez estoy pensando demasiado? Es la primera vez que salgo con Spring. –
Cierto, pero en lo que respecta a las tecnologías de visualización, en general terminarás acoplado a * algo. * ¡Reinventarás mucho la rueda si tratas de usar solo JSTL y la API de servlet! WebMVC y WebFlow son bastante no intrusivos, y con las bibliotecas de etiquetas puede crear fácilmente sus propios archivos .tag que los envuelven y "aislar" la dependencia en un solo lugar que la implementación podría cambiar posteriormente. Usar la etiqueta también eliminaría la dependencia de la interfaz Errores en su objeto de respaldo, permitiéndole usar un pojo sin resorte. – Affe