1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
[[constraints]]
== Constraints
Constraints are validation and conversion functions applied
to user input.
They are used in various places in Cowboy, including the
router and the `cowboy_req` match functions.
=== Syntax
Constraints are provided as a list of fields. For each field
in the list, specific constraints can be applied, as well as
a default value if the field is missing.
A field can take the form of an atom `field`, a tuple with
constraints `{field, Constraints}` or a tuple with constraints
and a default value `{field, Constraints, Default}`.
The `field` form indicates the field is mandatory.
Note that when used with the router, only the second form
makes sense, as it does not use the default and the field
is always defined.
Constraints for each field are provided as an ordered list
of atoms or funs to apply. Built-in constraints are provided
as atoms, while custom constraints are provided as funs.
When multiple constraints are provided, they are applied in
the order given. If the value has been modified by a constraint
then the next one receives the new value.
For example, the following constraints will first validate
and convert the field `my_value` to an integer, and then
check that the integer is positive:
[source,erlang]
----
PositiveFun = fun
(_, V) when V > 0 ->
{ok, V};
(_, _) ->
{error, not_positive}
end,
{my_value, [int, PositiveFun]}.
----
We ignore the first fun argument in this snippet. We shouldn't.
We will simply learn what it is later in this chapter.
When there's only one constraint, it can be provided directly
without wrapping it into a list:
[source,erlang]
----
{my_value, int}
----
=== Built-in constraints
Built-in constraints are specified as an atom:
[cols="<,<",options="header"]
|===
| Constraint | Description
| int | Converts binary value to integer.
| nonempty | Ensures the binary value is non-empty.
|===
=== Custom constraints
Custom constraints are specified as a fun. This fun takes
two arguments. The first argument indicates the operation
to be performed, and the second is the value. What the
value is and what must be returned depends on the operation.
Cowboy currently defines three operations. The operation
used for validating and converting user input is the `forward`
operation.
[source,erlang]
----
int(forward, Value) ->
try
{ok, binary_to_integer(Value)}
catch _:_ ->
{error, not_an_integer}
end;
----
The value must be returned even if it is not converted
by the constraint.
The `reverse` operation does the opposite: it
takes a converted value and changes it back to what the
user input would have been.
[source,erlang]
----
int(reverse, Value) ->
try
{ok, integer_to_binary(Value)}
catch _:_ ->
{error, not_an_integer}
end;
----
Finally, the `format_error` operation takes an error
returned by any other operation and returns a formatted
human-readable error message.
[source,erlang]
----
int(format_error, {not_an_integer, Value}) ->
io_lib:format("The value ~p is not an integer.", [Value]).
----
Notice that for this case you get both the error and
the value that was given to the constraint that produced
this error.
Cowboy will not catch exceptions coming from constraint
functions. They should be written to not emit any exceptions.
|
