userValidator.validate(userDto, bindingResult);
if (bindingResult.hasErrors()) {
throw new ValidationMessageException(bindingResult.getFieldError().getDefaultMessage());
}
if (bindingResult.hasErrors()) {
return new ResponseEntity<>(getErrors(bindingResult), HttpStatus.BAD_REQUEST);
}
I like the fieldErrors approach — its something easy enough to tack on, and I think we could make this data structure recursive if we ever had reason to (and it could be ignored by clients that don't get it)
I'm not 100% in love with using the 'fieldErrors' key name and feel we should use abstract terminology (incase we don't match a form submission... somehow)
I'd suggest the key 'details'
Our response body might look like:
{
"messageKey": "foo.bar",
"message": "foo",
"details": [
{
"id": "some.key", // optional? not sure about this name, but could be "name"
"messageKey": "bar.go.to",
"message": "You are not at the bar",
"details": [ ..... ] // yes, this could be a bad idea
}, {
....
}]
}
Nick Reid | nick...@villagereach.org
Friendly Neighborhood
Spiderman, Information Systems Group
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
I like the fieldErrors approach — its something easy enough to tack on, and I think we could make this data structure recursive if we ever had reason to (and it could be ignored by clients that don't get it)
I'm not 100% in love with using the 'fieldErrors' key name and feel we should use abstract terminology (incase we don't match a form submission... somehow)
I'd suggest the key 'details'
Our response body might look like:
{
"messageKey": "foo.bar",
"message": "foo",
"details": [
{
"id": "some.key", // optional? not sure about this name, but could be "name"
"messageKey": "bar.go.to",
"message": "You are not at the bar",
"details": [ ..... ] // yes, this could be a bad idea
}, {
....
}]
}
Nick Reid | nick.reid@villagereach.org
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/7140df2b-ef19-45a8-9191-1005e0254335%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CY1PR02MB1754BEB1D5A33B3CF307270394080%40CY1PR02MB1754.namprd02.prod.outlook.com.
"fieldErrors": { "requisitionLineItems": { "0c4b5efe-259c-44c9-8969-f157f778ee0f": { "stockOnHand": { "message": "Stock on hand cannot be negative", "messageKey": "requisition.error.validation.stockOnHand.cannotBeNegative" }, //and other field errors for this same line item go here }, //and different line items errors go here } }
"fieldErrors": { "requisitionLineItems[0].stockOnHand": { "message": "Stock on hand cannot be negative", "messageKey": "requisition.error.validation.stockOnHand.cannotBeNegative" }, //other field errors for this same line item and errors for different line items go here }
So, I'd like to say that I really want the nested fields solution....
I've said the following comment in internal reviews, I'm just making it public on the dev list (so our discussion tomorrow can mention this)
My only concern with the flattened fields solution is I'd like the flattened keys to be more meaningful. The current suggestion uses an indexed array in the error response, and that just worries me because its brittle. Lists can change, and the order of items in a list can change.
I would replace the array with a string-ified UUID. I'd imagine it could look like this:
VillageReach Starting
at the Last Mile
2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA
CELL: +1.510.410.0020
SKYPE: nickdotreid
www.villagereach.org
So, I'd like to say that I really want the nested fields solution....
I've said the following comment in internal reviews, I'm just making it public on the dev list (so our discussion tomorrow can mention this)
My only concern with the flattened fields solution is I'd like the flattened keys to be more meaningful. The current suggestion uses an indexed array in the error response, and that just worries me because its brittle. Lists can change, and the order of items in a list can change.
I would replace the array with a string-ified UUID. I'd imagine it could look like this:
"fieldErrors": {"requisitionLineItems.0c4b5efe-259c-44c9-8969-f157f778ee0f.stockOnHand": {"message": "Stock on hand cannot be negative","messageKey": "requisition.error.validation.stockOnHand.cannotBeNegative"}, //other field errors for this same line item and errors for different line items go here}
- nick -
Nick Reid | nick.reid@villagereach.org
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/e7eeacbf-187c-4b12-b904-27c620872e03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CY4PR02MB2199C1005EF6D0C1B8282BBD94370%40CY4PR02MB2199.namprd02.prod.outlook.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAAdp53zDq-_ON28%3Dey7_W%3DAS0ewgPWCEi5%2B0eBKfg-cbGycLCA%40mail.gmail.com.
Paweł Albecki
Software Developer
palb...@soldevelo.com