Question

UPDATE: It was suggested in the comments that I create a wiki for this. I have done, you can find it here (should you wish to keep tabs on it and/or contribute).

http://vrs.tomelders.com

I’ve never worked on anything like this before, so I’m completely winging it.

---

I’ve never worked on anything like this before, so please

I’m want to work on an open “standard” or “language”, or… well, I don’t really know what to call it…. to make form validation easier. I’m calling it VRS (Validation Rule Sheets) but at this stage, everything is negotiable.

The idea is to create a sheet of rules, similar to CSS that define how forms should be validated. This will require

1. A Syntax / Specification
2. A VRS Parser to convert the VRS into something useable
3. A VRS Processor to compare the form data against the rules and return a response.
4. A response format.

The benefits of a system like this would be

1. A platform/language agnostic way to define form validations.
2. A cross platform, highly portable way to define form validations.
3. Easy to read, easy to setup, easy to modify.
4. Client side and backend integration.

First things first though. What should the syntax / specification look like.

The way I see this working online is that a VRS file could be specified as a hidden field and the application routes the supplied form data through the VRS processor before processing it.

By way of an example, you could validate the content type of the “name” field would look like this

name {
    content-type: alpha;
}

content-type could be one of three values: alpha, numeric or alpha-numeric.

Hopefully that makes sense. I’ve never done anything like this before so I’m eager to get other peoples input. Here’s as far as I’ve gotten

------------------------------------------------------------

content-type: (string) alphanumeric | alpha | numeric

Restricts content to either numeric, text or alphanumeric.

------------------------------------------------------------

is-fatal: BOOL

If the rule fails, is it fatal? This could be really useful
for AJAX responses.

------------------------------------------------------------

allow-null: BOOL

wether a field can be empty or not. Good for required fields
and checkboxes 

------------------------------------------------------------

pattern-match: (string) email | url | regex

match the field against a pattern. 

------------------------------------------------------------

field-match: (string) field_name

compares a field to another field. eg: password confirmation

------------------------------------------------------------

greater-than: INT | FLOAT
less-than: INT | FLOAT
within-range: INT | FLOAT, INT | FLOAT

Pretty self explanatory. With regard to strings however, 
the string length is compared against the params.

------------------------------------------------------------

is-unique: (func) connection(host,user,pass), (func) map(table, field)

Check the value against a field in the database to see if
it's unique.

------------------------------------------------------------

date & time validations

This i'm a bit worried about in terms of terminology. I also
want to include dynamic vars in VRS such as

@now
@today
@thisMonth
@thisYear

------------------------------------------------------------

before: STRING | VAR
after: STRING | VAR

Again, self explanatory. Although I'm unsure what the date/time
format should be. UTC?


------------------------------------------------------------

Elapsed Time:

I'm completely stuck on how to handle conditions like
"years elapsed since date is more than 16"

I don't relish the idea of rules as prolix as

years-elapsed-since-now-are-more-than:18;
years-elapsed-since-now-are-less-than:18;

Finally, I’m debating wether devs should be able to specify the errors/warnings in the VRS or should they do that when handling the response?

So, that’s a lot to take in and I hope it’s clear. My question(s) I guess are

1. Good idea / bad idea?
2. Is this the right kind of syntax?
3. Are there more elegant ways of naming the rules.
4. What’s missing.

thanks

---

UPDATE: A few people have stated that this proposed system is a bad idea. If you think so, please provide a scenario in which it wouldn’t work. Thinking it’s a bad idea is one thing, proving it’s a bad idea is another, and I’d like to see proof that it’s a bad idea sooner rather than later. If you really think form validation could not be made easier or less tedious, please explain why.

In addition, I’m aware that form validation is not a new issue. However, there is currently no portable, cross platform, cross language solution to address form validation, which is what this proposal is specifically addressing.

Answer 1

I like the idea of putting the error messages in the VRS too. But they should specific to the rule that failed.

Also, you might consider not developing an entirely new “language” but use something like YAML for which parses already exist.

I see this language as being useful as you could use the same VRS for both client- and server-side validation.

PS: This should be community wiki methinks.