>> All modern browsers have a facility to turn off JavaScript.
sure. but for our app, if they did that the whole thing would collapse - the tab
system, the menu, the tool tips, context help, dynamic tab order, alerts ...and form
control validation. and if that happens then [EMAIL PROTECTED] 'em - that's what the
boss wants.
in the absence of building it in Flash/FLEX, to get any advanced functionality leans
on the crutch of javascript. but if you want to be afraid of people turning off
javascript then be prepaired to not use JS at all - anywhere. we *have* to use JS so
we go all the way.
but you're right. don't trust the bastards. that's why I mentioned that there was a
simple validation within each (public) method as a last line of defence before any
processing is done - eg:
<cfset args.data.CODE = valStringFormat(arguments.CODE, "^UD[0-9]{1,3}_DESC$")>
<cfset args.data.UD_CODE = valMinLength(valMaxLength(arguments.UD_CODE, 3), 1) />
<cfset args.data.UD_DESC = valMinLength(valMaxLength(arguments.UD_DESC, 20), 1) />
if any of these (additional) server validation routines fail, a general "you're trying
to hack in, aren't you?" exception is thrown.
They shouldn't get to this point. the JS validates the control with the view of
providing user feedback if anything is wrong. the dates should be in a yyyy-mm-dd
format, the strings the right length, all required values present, etc.
While CF isn't Eiffel, you can still apply "design by contract" ideas. If the contract
isn't fufilled then don't be afraid of throwing a big fat exception and kill it there.
the data comming out of the controls is either kosher or it isn't. the business
objects are available via a known API. any deviation means the contract is invalid.
I suppose there isn't that much difference between what you do and what we have. the
bottom line is that there has to be server-side validation somewhere. we do it within
the methods. You have a validation CFC tightly coupled to each form. But part of the
problem is that CFPROPERTY is useless and you have to build in smarts just to get an
"invalid property assignment" and to work out why. we don't bother - it's all or
nothing.
did I mention that the UI (form) and what methods are run can change with what
permissions the user has? "bits" are turned on or off depending on the user (not
often, admittedly)
With multiple methods to run on (nearly) every form submit, almost a hundred forms to
build for this app and over a thousand UI elements used, we rely on re-usable UI
controls that have JS to do the grunt validation, a very simple "all or nothing"
server-side validation on any public inputs and try and keep it as simple as possible.
we've got cftransaction over the multi method calls so if any (server found) invalid
data throws an exception, the whole lot rolls back.
have you seen how ASP.NET does validation? it's just setting a couple of attributes on
each control. That's what we're aiming for.
cheers
barry.b
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
