James Reeves wrote:
> On 7 April 2011 20:03, Joost <[email protected]> wrote:
> > Yup. I'm mostly in the same boat. That's why all the predicates I've
> > produced for now are in the pretzel.strings namespace. I expect to end
> > up with few non-string predicates, but those will have to go into
> > pretzel.numbers or whatever make sense.
>
> What about predicates that operate on numbers encoded as strings? e.g.
> "1" or "4.2".
IMO, they should be in the strings package.
> > For your specific example of (integer-string? "foo"), that should
> > just return false. The idea - for strings - is that any kind of input
> > string can be supplied, and the function should just test whether it
> > conforms to some kind of formatting. The same logic should, I think,
> > apply to functions operating on numbers and other types such as files,
> > if there's a need for those kinds of predicates.
>
> I think we differ a little in our end goals, then. I'm less concerned
> about general use, and more concerned about generating good error
> messages for form-data validation. For instance, with normal
> predicates, one might get error messages like:
>
> {:score ["is not present" "is not an integer" "is not between 1 and 10"]}
>
> But in my view, it would be better to have a error message like:
>
> {:score ["is not present"]}
>
> Because if a value is blank, there's no point in telling the user it's
> also not an integer or between a certain range. Also, one might have
> integer fields that can be blank.
Sure, but that's part of the validation mechanism that uses the
predicates; the predicates all return just true or false. The messages
associated with that aren't (and IMO, shouldn't) be part of the
predicates.
Basically the problem is one of combining validations (the functions
that generate feedback); some validations can be "parallel", that is,
each validation should be run and the messages they return should be
compounded, but others are dependent on each other, in your example,
the test for integer-formatting should only be run if the test for
existence doesn't return an error message.
In clj-decline you can specify this by using the valiations function
to combine parallel validations and validate-some to specify dependent
validations.
A simple example from
https://github.com/joodie/flutter-decline-demo/blob/master/src/flutter_decline_demo/validations.clj
(defn required
[param]
(validate-val param seq {param ["this is a required field"]}))
(def validate-entry
(validations
(required :name)
(validate-some
(required :email)
(validate-val :email str/looks-like-email?
{:email ["must contain an @ sign, and a dot in the
domain name"]}))
(validate-some
(required :phone)
(validate-val :phone str/looks-like-phone?
{:phone ["this doesn't look like a phone
number."]}))
(required :address)))
There's a related question on how to merge predicates (instead of
validations) which is what the pretzel.combine namespace is for, but
that's on a lower level since it really just merges predicates into
new ones without doing anything with messages.
> So I think Valip needs its own predicate library, but I can probably
> factor out a lot of the general stuff to Pretzel (e.g. email-address?
> integer? etc.)
I'm not so sure you actually need to have another level of predicates
to do what you want, but of course, if it's possible to merge the
useful predicates from valip into pretzel, I'd be happy with that :)
Joost.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
