search

jaspervdj / digestive-functors

A general way to consume input using applicative functors
149 stars 71 forks source link

Adds "conditions" function to allow for the composition of multiple independent validation functions. #85

Closed mavenraven closed 10 years ago

mavenraven commented 10 years ago

See haddock documentation for more detail.

jaspervdj commented 10 years ago

I can see how that's really useful, thanks a lot!

mavenraven commented 10 years ago

You're welcome! I'm started working on digestive-functors-validations project, which will be kind of like http://edgeguides.rubyonrails.org/active_record_validations.html for a lot of common validations and data types, like phone numbers. Do you know if anything like that already exists on Hackage (doesn't have to be digestive-functors specific)?

jaspervdj commented 10 years ago

I don't know anything like that, unfortunately. Such a project should come in super useful for other people as well, thanks for tackling it!

mightybyte commented 10 years ago

@mavenraven I also have not seen any project like that. We're using d-f heavily, so I will be very interested in seeing what you come up with.

mavenraven commented 10 years ago

@jaspervdj , @mightybyte , I've done a phone number proof of concept as far as how I think the validation and localization should work. Take a look if you get a chance, especially if you can think of any edge cases for the parsing, or something that seems off about the localization strategy. Thanks for any help! https://github.com/mavenraven/digestive-functors-validations

mavenraven commented 10 years ago

@jaspervdj , @mightybyte , I've continued working on the validation stuff, and I've split it into two packages.

validations - http://hackage.haskell.org/package/validations-0.1.0.1 - is a more flexible way to solve https://github.com/jaspervdj/digestive-functors/issues/87 , and it includes an adapter for digestive-functors. validations-checkers (which I haven't made a separate project yet) is where all the generic checkers will be. I'll probably end up putting "conditions" into validations as well, as it makes more sense there.

Since they're now split, validations-checkers doesn't need the digestive-functors dependency, and validations doesn't need the parsec dependency. Also, validations should be fairly API stable, but I expect that validations-checkers will probably be fairly unstable for the time being.