One of the areas in which Blackstone should (I won’t say “will” until we ship as stuff could always change, so “should”) make our lives considerably easier is form field validation. I mentioned input masking a few days ago, and validation enhancements a while back. Both of these should play an important part in form field validation, input masking helps ensure that correct data is entered in the first place, and server-side validation via is the must-have last safeguard (you must never rely solely on client-side validation).
But that is not all, in Blackstone we also plan to simplify client-side and automatic server-side validation. But first, a review of how these are done right now.
Server-side validation is not optional, as already said you must never rely solely on client-side validation. Server-side validation can be as simple as a bunch of statements or tags on the action page, although it can get far more complex if needed. This type of validation provides the utmost control over both the validation testing, as well as the actions to occur if validation fails. ColdFusion also supports a simpler form of server-side validation, one that does not require code on the action page, and rather, uses validation instructions embedded in the form itself. For example, to make a field required you could do the following:

ColdFusion uses the hidden field as a validation instruction, and if login is not specified (in this example) the error message “Login is required!” would be displayed. This functionality has been in ColdFusion since the very early days, and a variety of validation types are supported. The upside of this feature is that the validation rules are within the form, as opposed to on the action page, and this makes keeping the rules and forms in synch much easier. The downside is that they are not failsafe (it would be possible to submit forms without those hidden fields), and there is limited control over how error messages are displayed.
Client-side validation is designed to make the experience better for the end-user. It must never be relied on as the only validation mechanism, but being able to trap errors before form submission does make for an improved user experience. ColdFusion supports client-side validation using JavaScript. While many users write their own JavaScript validation, ColdFusion has long been able to generate basic JavaScript validation code for you. (And although some ColdFusion developers stay away from and like the plague, the tags and the code is actually very good). So, the following code uses to make a field required:
In addition to the “required” flag, supports a range of validation rules via the “validate” attribute.
Thus far is what is supported in ColdFusion today. So, what does Blackstone change? Well, several things.
For starters, lots more validation types are planned, including the oft requested email and url.
In addition, the JavaScript error message that is displayed when using client-side validation will display all validation errors at once, not just the first.
But perhaps more importantly, it should be simpler to perform both client-side and server-side validation at once. has a new attribute named validateAt which accepts three values. onSubmit (which is the default) performs client-side validation when the form is submitted, just like client-side validation in currently. onBlur performs client-side validation as soon as a field loses focus (user tabs to next field or clicks on another field, for example). onServer performs server-side validation, the same validation that hidden fields perform, but without having to actually define those fields (they are still present, but are generated and embedded automatically). Look at the following code:





And the best part is that validation methods may be mixed. So, to validate on the client and server you could do the following:

Here validateAt is specifying both onSubmit and onServer, and so ColdFusion will both generate client-side validation code, and embed hidden form fields for server-side validation.
Pretty cool stuff.

9 thoughts

  1. Cool feature. I’ve never really used the hidden field method of server side validation. It always seemed like somebody could easily strip out my hidden form fields and bypass my validation.
    I usually just do a bunch of regular expression checks on the action page to validate data. If I’m feeling generous, I’ll do .js for the client side as well.

  2. Mike, they could, just as they could remove client-side validation. Which is why I said never to rely solely on them. These are no in lieu of full server-side validation, they are in addition to it.

  3. in the same sense on your action page you could check the http referer to see if it submitted from the correct url. That will make the hidden field approach a bit more secure.

  4. Yeah, I don’t understand the point of the "automatic" server-side validation. It’s like a false-crutch for novice or lazy developers to fail by. It provides fallback server-side validation for user agents without JavaScript, but with none of the security built in that server-side validation should have. It’s about as useful as Javascript-implemented authentication.
    Now if using CFFORM and CFINPUTS, what could be done – since this is all CF-generated – is to auto-generate a checksum that can invalidate the form submission if fields and their attributes and – in the case of hidden form parameters driving server-side validation – their values (reg-ex pattern, etc). Then CF could detect if the non-modifiable elements were modified on submission.
    Let’s extend the "never rely on" part a bit further for Bill and say that relying on any client information is a bad idea. Even referers and user agents can be modified (making the form fail if you rely on this) and spoofed (making it possible to submit a hacked form anyway).

  5. Ahhh, I don’s use this validation, I was just saying a quick check that can be used for anyone that does.

  6. I’m using:
    <cfinput type="submit" name="subscribe" value="Subscribe" validate="submitonce" />
    but it creates a JavaScript error:
    ‘_CF_submit_status’ is undefined
    Any ideas about what is wrong here?

  7. I’m using:
    <cfinput type="submit" name="subscribe" value="Subscribe" validate="submitonce" />
    but it creates a JavaScript error:
    ‘_CF_submit_status’ is undefined
    Any ideas about what is wrong here?

  8. Thanks Ben for highlighting this great new feature.
    I wanted to point out a weakness in it though.
    I recently tried using this and thought how great it was not to have to use the hidden fields and essentially write the same inputs twice.
    If you go to http://validator.w3.org/ to try and validate it, you’ll see that it fails. CF puts the hidden inputs in for you, but it does not close them.
    Thanks, Cliff

  9. Cliff, I know this may irk some, but, to be very honest, complete validation of all generated code is not promised by ColdFusion, nor was that even considered a product requirement. But, point taken, and I’ll pass the message along.
    — Ben

Leave a Reply to Chris Bowyer Cancel reply