[erlang-questions] How do I elegantly check many conditions?

Geoff Cant geoff.cant@REDACTED
Sat Mar 21 06:37:42 CET 2009

ryeguy <ryeguy1@REDACTED> writes:

> So when a user sends a request to register an account, they send their
> username, password, email, and other info. The registration function
> must verify all of their data. An example would be:
>  - verify email not in use
>  - verify username not in use
>  - verify username is alphanumeric
>  - verify all fields are above X characters long
>  - verify all fields are less than Y characters long
> Now I don't want to have a 5 level deep if or case statement, but what
> other options do I have? Splitting it into separate functions sounds
> like a good idea, but then I just have to check the return value of
> the functions in some sort of conditional and it's back to the
> original problem.
> I could separate them into functions and then call an if statement
> with all of the conditionals OR'd together, but that wouldn't give me
> what I want because I need to be able to tell the user the specific
> error if there was one.
> How does one handle this kind of situation in erlang?

I ran into this when building a website recently and ended up building a
form validation
library. (http://github.com/archaelus/ejango/tree/master - the form
validation checking engine is located here,
You can see examples of almost all the validation rules you gave above
in the unit tests for the form_validator module. There's some
documentation on how to specify them around line 109 in the
form_validator file.

I was trying to create a DSL for declaratively specifying forms and the
rules for validating particular fields. E.g. {"user_email",
[email_address, not_empty, {predicate, fun
yourcode:check_email_in_use/1}]} Checks that the value of the form field
"user_email" is not the empty string, matches the regex for email
address validation and calling yourcode:check_email_in_use(<value of the
"user_email" field>) returns true. The validation engine will report
errors for each rule given for a field so that you can give meaningul
error messages such as "Email address in use" and localise them if

The library has patchy edoc and some eunit test coverage - the validator
itself has edoc, but unfortunately the high level declarative form API
isn't documented well yet. It's on my todo list, but if someone beats me
to it I'd be happy to apply any patches. The library works well
enough that it has been used in a website I'm about to unveil soon.

Geoff Cant

More information about the erlang-questions mailing list