Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom error message mapping #34

Closed
repli2dev opened this issue Nov 9, 2020 · 5 comments
Closed

Custom error message mapping #34

repli2dev opened this issue Nov 9, 2020 · 5 comments

Comments

@repli2dev
Copy link

The error messages created by the library are quite nice (they contain path, expected type and actual values). However in usability in real world APIs (at least at our company) we need programatically to map these error messages to either our error codes (numbers or strings) or custom error messages for example to provide more details, links or just keep consistent with our documentation language.

@dg
Copy link
Member

dg commented Dec 7, 2020

There is also codes in error messages.

@repli2dev
Copy link
Author

Thanks for pushing it forward...

I have tested today and attempted to use it to reimplement our validation structure these our my findings:

  • Better granularity of Nette\Schema\Message::code would be nice as invalid values (such as "12" on int) and min/max violations have the same code schema.unexpectedValue.
  • DateTime (including range) validations would be really nice (though I understand that this is a pain in current PHP). It is however solvable by custom validators.
  • In Nette\Schema\Message the variable assertion has " around its value, it this a purpose? (I see `string(5) ""foo"" in the dump).

Not any of this is a blocker for our purpose, though they make the nice validation structure a bit harder to read due to high number of custom validators.

Feel free to utiilize this feedback or close the issue :-)

@repli2dev
Copy link
Author

My note about readability could be addressed by creating custom Scheme implementations (with custom rules), however from docs I am not sure if it is a supported way we could potentially rely on.

@dg
Copy link
Member

dg commented Dec 15, 2020

@repli2dev I added two new errors Message::OUT_OF_RANGE & Message::LENGTH_OUT_OF_RANGE for min/max violations

ad DateTime: try to create a separate issue on it, so that it is not forgotten

@repli2dev
Copy link
Author

@dg created #36 for the DateTime, thanks for the new codes.

@dg dg closed this as completed Dec 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants