So a few people asked me about my comment i made on my new javascript validation grails plugin about blank vs nullable constraints.
Well the problem i have is. In javascript validation on strings "blank" and "nullable" checks are the same thing. By default grails adds nullable constraints to all attributes of a domain object. So:
When I generate javascript validation checks based on these default constraints I generate a "required" check for each attribute. So the "nullable" constraint maps to a "required" check in javascript.
The problem is the "blank" constraint also maps to a "required" check. So a string attribute has a nullable=false constraint (which it has by default) AND a blank=false constraint then the use will end up seeing TWO message: Eg
You must enter a name (nullable message)
You must enter a name (blank message)
To the user this is duplicate messages.
I have this idea:
When processing the constraints and generating the javascript validation. The nullable constraint is ignored for String attributes and the blank contstraint is used instead. This would mean if you want to have a javascript required check for a string you must use the blank constraint.
What do you think ?
4 comments:
if two messages
"You must enter a name (nullable message)
You must enter a name (blank message)" happened, showing one of them to user is ok.
Maybe someone only likes to use blank or nullable, it is not a good idea to change someone's idea.
Do you think so?
Can't you just check if both are present and then give the "blank" error message? I don't think I'd want to require that strings be nullable: false as that really means something different.
In grails, if nullable: false, but blank: true, that means if there is a value, it can't be an empty string. but there doesn't have to be a value.
An example might be a middle initial. A tab character (i.e. blank) can't be a middle initial, but you wouldn't want to require that everyone enter one.
I realize I'm a bit after the fact, and fair warning: I'm a complete Grails noob... so I'm making some assumptions which could be incorrect.
I agree, from a user perspective 'blank' and 'nullable' are pretty much the same thing, but as a database guy they are very different. In some cases not null is a good idea and in some cases it's not... and the blank: false is a nice way to be sure that whitespace isn't used as a value.
I have a mix in the system I'm building: most cases where nullable: false, blank:false is set as well. Sometimes I have nullable: true, blank: false. If there's no entry, I don't want whitespace to be included accidentally (in other words: enter something or don't!) I don't think I make use of the reverse (nullable: false, blank: true).
I think the prior user's suggestion of really combining at least the output of the nullable and the blank check into a single error message is a good idea. That and/or being a little less literal than 'null' and 'blank'.
A single message indicating the presence of either/or both condition would make sense too if the messages are clearer than 'null' and 'blank'. Those meanings could be ambiguous to non-techies, but 'empty' and 'characters other than spaces and tabs' individually carry clearer messages and would apply equally rather than just be seemingly redundant.
My two bits. I'm about to try it out now and thanks for the effort!
Steve
I suppose, there is a more general and formal concept that extend the nullable type concept, it comes from option types, which enforce explicit handling of the exceptional case
Post a Comment