Request: Quick'n'easy field validation

burnchar

The number one feature that I would find most useful in Editor is quick'n'ease form validation.
I know about the validation example: https://editor.datatables.net/release/DataTables/extras/Editor/examples/clientValidation.html
However, in my opinion that is a bit low-level for what I suspect is a common task.

I think a fairly small set of canned tests for really common validation plus a few generic solutions would handle most cases:
- Numeric range or perhaps separate min/max
- Text length (possibly with an optional whitespace trim)
- Field required or not
- isAlpha, isAlphaNum, isPrintable
- regex match
- Provide your own validate function
- Warn values vs. mandatory values. Man that would have saved time. e.g. entering "1900" for birthyear may get an "Are you sure?" whereas entering "201" would get "Invalid entry".
A real-world example: in our manufacturing databases, when an engineer enters an unusual requirement, it may be a typo 80% of the time, but we do a lot of R&D so if they really do want to use a temperature of 5000°K instead of the usual 500, they are allowed after confirmation. (I found it tricky to do this and store the confirmation status reliably).
Another real-world: When entering a new manufacturing process, 99% of the time it starts with the letter 'C' indicating the fab being used. Occasionally, someone may need enter 'B' (the old, shut-down fab) to store a record of an old process, but they should be warned that such an entry may be a typo before committing it to the database.

I use a third and fourth level server-side: Hard-coded limits for 3rd and, of course, database constraints for 4th and final.



Rough idea in my head of what the API could look like:
[code]
...

"aoColumns":
[
{
"mData": "birth_year",
"validate": { "warnrange": [0, 9999], "requirerange": [1800, new Date().getFullYear()], "required": true }
},
{
"mData": "serial_no",
"validate": { "warnlength": [8, 10], "requirelength":[ 5, null ], "match": { "regex": "/[^a-zA-Z0-9]/", "error": "Only numbers and letters are allowed" } }
}
]
...
[/code]

If it's practical to do this with a plug-in, I'll be glad to get it going if you'd save me some research by writing a quick skeleton to get me started.

allan

The approach that I've taken with Editor is that validation should be done on the server-side, and in the provided libraries (which I know you aren't using - sorry) the validation is quite trivial. The reason I've taken that approach is that the validation must be done at the server-side anyway, so why repeat the code, when the Ajax request is normally answered within milliseconds. No need to bog the client down with extra code, and the server can do additional validation such as ensuring unique values that would be possible on the client-side.

Allan

burnchar

Sounds good. I was previously using client-side for warnings and server-side for errors, but I suppose there's no special reason to do either at client-side, especially if it will help keep DT lean_and_mean.