Customizable error messages

[jgarbers]

I was considering a modification to allow replacing one or more of the validation error messages with alternatives -- perhaps phrased differently (to meet an application's style guidelines) or in different languages. The basic idea would be to have all of the places that generate error messages use a function that pulls the template from a dictionary in the Validator instance, and fall back to the "stock" messages if none is found. Would this be a welcome addition?

[Julian]

Hm. I'm inclined to believe that this deserves to be done at the application level. ValidationErrors as they stand now are for developers to deal with – if you have something that faces your users you're going to want to wrap them in your own exception presumably (or some other application specific method of displaying errors – HTML elements or whatever). That part should certainly be easy to do (I hope it's easy to do now, via ErrorTrees and just wrapping ValidationError objects, but if you've got suggestions there I'm open to hear them certainly.)

So, you'd presumably add any localization at that level, or if you had some other messages you wanted to display instead, or whatever.

I think I'd need some more convincing to hear why the added complexity here is worthwhile :).

[jgarbers]

Thanks for your response, Julian! If you're suggesting that user-facing validation happen at a completely different level -- in client-side JavaScript, for example -- I agree, and I am indeed doing that sort of thing in my Backbone.js models and forms. But if an invalid object is passed in for validation, perhaps because client-side validation was incomplete or outdated, I would rely on my JSON Schema validation to provide a useful error message that could be relayed back to the user. If I use iter_errors to get the validation errors, the only information I have is the path (a property name) and a message string which has already had arguments interpolated into it. I don't see how I would go about converting that message to a different phrasing or language (except, perhaps, by using regexps to match the messages, which seems unappealing).

I guess the basic question is whether error messages returned from the validation process are only for developers for review in a "this shouldn't happen" context (that is, your "user-level" validation failed you) or, as I'm suggesting, that the messages be suitable for inclusion into a user interface as-is. If your feeling is that these are developer messages, not user messages, I'll be happy to close the issue and thank you kindly for the code as it is!

[jgarbers]

Reviewing the error objects returned by iter_errors, I just noticed that there is also an error.validator string that I could use as a key into my own dictionary, so that gets me part of the way to what I'd want. However, at that point I've still lost some of the context from the schema. For example, I could use the key minLength to look up a message, but at that point I wouldn't know what the minimum length was or what user-provided value was too short, etc.

[Julian]

A ha! Cool, so we're getting somewhere :).

In addition to the path and the message attributes, you also have the validator attribute, which will tell you which validator failed. So, that'd be useful for reconstruction (certainly don't want to have you using regexps :).

Given the validator, and assuming you still have your schema around, you'd be able to pull out any useful information to use to construct your error message I think.

I think we could benefit from including a helper function or two to help getting a property off the instance from a path and getting a property from the schema using one, that'd probably be useful here.

EDIT: So yeah, given your last message, to get the rest of the way, if what you're missing is the schema, I think that's going to be the dirty part. Because to implement that you'd need each validator to set a bunch of extra things on the error object, which are going to be validator-specific, and add a lot of code. I'm open to hear what you think would benefit you here though certainly.

I think I'm open to adding a method to error objects that would do what you're asking if we can come up with a reasonable API for it.

[Julian]

Hi. Hope you were successful. If not feel free to reopen. Cheers.

[jgarbers]

Thanks, Julian - funny how this worked out. Our plan had changed to use XML instead of JSON, so jsonschema kind of dropped off my radar. But we just recently decided to return to JSON, so I'm back. Before I deal with the error messages, I've been trying to figure out if there's a way to define a reusable component -- say an "address" definition that needs to be used in multiple places -- within the same schema document. Thanks!