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

Support validation before and after conversion #37

Open
t6d opened this issue Jan 17, 2016 · 6 comments
Open

Support validation before and after conversion #37

t6d opened this issue Jan 17, 2016 · 6 comments
Labels
Milestone

Comments

@t6d
Copy link
Owner

t6d commented Jan 17, 2016

In some scenarios, it might be necessary to perform validation before performing the conversion. This is currently unsupported.

@t6d t6d added the feature label Jan 17, 2016
@t6d t6d added this to the 2.0 milestone Jan 17, 2016
@fabrik42
Copy link
Contributor

Example use case: I want to use a smart properties class to validate/handle a ISO8601 date string.

So I want smart_properties to do the following:

  • Check the input, that it is a valid ISO8601 string (not implemented yet)
  • Convert the string to a ruby Date object (currently converts)
  • Make sure, that it is a Date object (currently accepts)

In this case, you need to check accepts before the converts - otherwise it could lead to a date parser error, in case the date string is not valid.

@benedikt
Copy link
Contributor

While I understand that having this as a core feature would be nice, I can think of two other ways to implement this without the need for a core feature:

  • Just raise an exception in the converter method (accepts would raise anyways)
  • Let the converter return nil or something else to indicate that converting failed and check for that value in accepts

If I understand it correctly, you'd nonetheless need both a accept before and after the conversion. Just because the string has a valid format, doesn't necessarily mean that the value makes any sense (think leap years)

@fabrik42
Copy link
Contributor

In my specific use case, I don't want to raise an exception. The whole point of the class would be to validate/prepare a combination of given params. If it raises, I would need another layer above the class to handle these exceptions.

I don't want the converter to return nil, because this would basically move the validation logic into the converter and I can not determine, if the input was just invalid or not given at all.

I personally think that smart_properties can become very handy for input validation - but in real world scenarios with user input, we should have one more callback before the converter to make sure the converter does not crash.

@t6d
Copy link
Owner Author

t6d commented Jan 22, 2016

There is no harm in adding a prepares hook, so that the execution order would be prepares -> converts -> accepts. I'll actually try and release this as a feature to SmartProperties v1.x..

@t6d t6d modified the milestones: 1.x, 2.0 Jan 22, 2016
@t6d
Copy link
Owner Author

t6d commented Jan 22, 2016

By the way, I can highly recommend using dedicated objects for complex validation and conversion operations: SmartProperties advanced input validation.

@fabrik42
Copy link
Contributor

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants