On Sun, Apr 10, 2011 at 11:42 AM, James Reeves <jree...@weavejester.com> wrote:
> On 10 April 2011 09:49, Ken Wesson <kwess...@gmail.com> wrote:
>> (def age-invalid-en
>>  {:low "age must be at least 1"
>>   :high "nobody is THAT old!"
>>   :blank "age is required"
>>   :non-integer "age must be a whole number"})
>>
>> (def qty-invalid-en
>>  {:low "quantity must be at least 1"
>>   :high "maximum 10 per customer per order"
>>   :non-integer "quantity must be a whole number"})
>>
>> (if-let [err (age-invalid-en (not-int-in-range? age 1 120))]
>>  (println err)
>>  (if-let [err (qty-invalid-en (not-int-in-range? qty 1 10))]
>>    (println err)
>>    (process-order age qty)))
>
> IMO, that's not as as simple or as easy to read as:
>
> (validate thing
>  [:age present? "age is required"]
>  [:age integer-string? "age must be a whole number"]
>  [:age (at-least 1) "age must be at least 1]
>  [:age (at-most 120) "nobody is that old"]
>  [:qty integer-string? "quantity must be a whole number"]
>  [:qty (at-least 1) "quantity must be at least 1"]
>  [:qty (at-most 10) "maximum 10 per customer per order"])

I thought you were the one who wanted the strings moved out to a data
structure that could be swapped with localized versions? :)

> But I guess to an extent that's a matter of opinion.

Obviously.

>> I don't agree. Everything that is not forbidden is allowed. Specific
>> chunks of the input-space are "wrong" for specific reasons; what's
>> valid it what's left after whittling all of those away.
>
> My perception of validations is that they are a contract that a
> particular map of data has to conform to. I don't like the idea of
> encouraging people to think in terms of "allow by default", as that's
> not considered good security practise.

On the contrary, if you don't think carefully about each specific
thing that could cause a problem and forbid that thing, you can end up
accidentally allowing corner cases that break the security model. If
you work backwards from the security model to derive a set of
constraints, though, those constraints are often mostly "shalt-nots".

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to