Review design and completeness of validation concept

[MarcoRose]

Validation and error-handling shall be investigated to be sufficiently designed and implemented in the sample (server and clients)

documentation to be revised and aligned with examples.

[henning-cg]

The current state in OASP is, that the RestServiceExceptionFacade simply converts validation exceptions to a JSON object containing "message", "code" and "uuid" attributes.

Although the message string will contain a readable description of the validation errrors, it seems fragile to have to parse this on the client-side.

A possibility to enrich the information would be to add a new attribute which would list the validation errors individually, allowing the client to show more detailled error messages to the user.

[dsanche2]

I have done a pull request so we now list every validation error for each attribute individually, so it can be parsed on the client side.
Validation format example:
{
"message": "validation message",
"code": "validation code",
"uuid":generated uuid,
"errors" : {
"fieldname1" : [
"message1",
"message2"
],
"fieldname2" : [
"message3"
]
}
}

In addition, I have added a test for Constraints Validation Exceptions. I needed to add hibernate libraries to pom.xml (as test scope) because it was neccesary a provider for validation. I guess you didn´t do it because you didn´t want to add dependencies with hibernate to the rest module. If you consider it´s wrong, let me know.

[amarinso]

I think we can close this issue as the patch is already accepted.

[amarinso]

Too fast from my part. We still need the samples aligned and the documentation.

[hohwille]

I will close this for 1.2.0 and we continue with #237 to complete.

[tbialecki]

Sorry for writting it now, but i didn`t have time earlier.

This validation concept is only valid for forms. I think that this meta
protocol should also allow to pass some feedback from server like working,
success messages and so on.
The second think is, have you thought about i18n in context of validation
?
I think we should return simple message keys instead of real messages from
server and then translate them in client.

2015-05-25 15:07 GMT+02:00 Jörg Hohwiller [email protected]:

I will close this for 1.2.0 and we continue with #237
#237 to complete.

—
Reply to this email directly or view it on GitHub
#218 (comment).

[hohwille]

have you thought about i18n in context of validation?

jep. However, your suggestion does not work properly with JSR 303. The error message also needs to contain dynamic parameters. We have to ensure that the locale on the client is part of the metadata so the server locale for the request is in sync. Then the server can localize the messages and send plain strings. Everything else is simply too complex. The I18N concept of JSR 303 is not so great but we have to live with it and can not use advanced I18N such as offered by NlsMessage here.