magic.lambda.validators

This project contains argument validators for Hyperlambda. More specifically it contains the following slots.

[validators.date] - Verifies that some date input is a date, and optionally between [min] and [max] value
[validators.email] - Verifies that some input is a legal email address
[validators.enum] - Verifies that some input is one of a set of predefined legal values, found as values of children
[validators.integer] - Verifies that some integer input (long, int, etc) is between some specified [min] and [max] range
[validators.mandatory] - Verifies that some input valus is given (at all)
[validators.regex] - Verifies that some input is matching some given [regex] pattern
[validators.string] - Verifies that some string input is between [min] and [max] in length
[validators.url] - Verifies that some string input is a legal URL, either HTTP or HTTPS type of scheme
[validators.recaptcha] - reCAPTCHA validator, to avoid bots from invoking your APIs
[validators.default] - Default validator, adding default argument if not specified

All of the above slots takes an expression, or values, as its main input, and will throw exceptions if their input expression’s value(s), or its value, does not follow the rules specified by the validator. Some of the above slots takes additional arguments. This makes them perfect fits for “intercepting” the input specified to an HTTP REST endpoint, to verify the input data conforms to some sort of predefined validation scheme.

Commonalities between validators

.foo
   email:foo@bar.com
validators.email:x:@.foo/*/email

Most Hyperlambda validators requires some sort of argument(s) - However, some of these validators does not require arguments, such as the email validator, that simply verifies the input is a valid email address. To use the [validators.regex] validator, you should probably learn regular expression. However, this is beyond the scope of this article.

Notice - No attempt to invoke the type validator logic will be done unless the value is a non null value. If you want to enforce such logic, you’ll have to combine the specific type validators with the [validators.mandatory] validator, that enforces that a value must be specified and not have a null value.

Validator internals

You can use one invocation to any of the validators to validate multiple nodes, such as the following illustrates.

.arguments
   .
      no:5
   .
      no:10
   .
      // Throws if you remove the "."
      .no:11

validators.integer:x:@.arguments/*/*/no
   min:5
   max:10

First the above expression will be evaluated, then every resulting value will be validated, and if any of them are not validated according to the validator’s arguments - Which for the above example is number between 5 and 10 - The validater will throw an exception, providing the invalid value, and the name of the last iterator (effectively being the argument name) to the caller. This allows you to use one single validator to validate multiple arguments, such as the above illustrates. This might be useful if you for instance have an endpoint accepting multiple address fields, and zip code is a mandatory argument, and it needs to be an integer with a [max] and [min] value.