...
The data for the configuration should be an object with “validationType” and validationRules“validationRules.”
If “validationType” is “enum,” “validationRules” should be an object mapping language codes to arrays of possible values. If “validationType” is “number_range,” “validationRules” should be an object with optional “min” and “max” specifying the bounds of the range.
...
| Code Block | ||
|---|---|---|
| ||
{
"validationType": "enum",
"validationRules": {
"en": [
"Never attended school or only attended kindergarten",
"Grades 1 through 4 (Primary)",
"Grades 5 through 8 (Middle school)",
"Grades 9 through 11 (Some high school)",
"Grade 12 or GED (High school graduate)",
"1 to 3 years after high school (Some college, Associate’s degree, or technical school)",
"College 4 years or more (College graduate)",
"Advanced degree (Master’s, Doctorate, etc.)",
"Prefer not to answer"
]
}
} |
Internals
Validation configs are stored in Dynamo. Hash key is appId + “:” + studyId (blank if null). Range key is categoryName.
Validation configs need to be deserialized twice in separate places (once when saved, in order for them to be validated, and once when fetched from Dynamo, in order to actually validate a demographic), but the deserialization logic should be common. Therefore, the design I went with was to add a method to the validation type enum which returns a DemographicValuesValidator. DemographicValuesValidator is an interface for an opaque type which first accepts validation rules as a JsonNode, and then can either validate the rules themselves or validate a demographic using the rules.
Previous Discussion (now outdated)
...