What of the AJAX approach to validation? You can pass the form to a server side object for validation. Take the CF8 feature of cfajaxproxy.
Obviously, you can turn of JavaScript. As well as a client initiated validation would not solely suffice. Teddy R. Payne, ACCFD Google Talk - [email protected] On Thu, Feb 12, 2009 at 2:00 PM, Dawn Hoagland <[email protected]>wrote: > And this is why I never use it unless the "user" has their knickers in a > wad to know about the error before they go to the next page. Even then I > usually don't bother (especially if they are on an intranet) because the > server validation is so quick they don't realize that they've just *gasp* > submitted the form and received clear, concise error messages without the > developer writing reams of JavaScript code (which users can - and will > disable) since I have to check it on the server anyway. If they ask, I just > tell them that clicking the submit button triggers the validation code. > Well - it does :) > > Now Flex is a whole 'nother can of worms and many times I validate the > second the user changes the value or focus. > > Dawn > > > On Thu, Feb 12, 2009 at 1:16 PM, Charlie Arehart <[email protected]>wrote: > >> Thanks for all that, and fair enough. I missed the looping that was >> appending more to the field name, but the info may still help someone. >> >> >> >> And indeed what you've confirmed is what I would have said if you'd >> stopped at your first paragraph: the onserver validation is causing CF to >> create the hidden field (albeit in a new format, different from the old >> style _date kind—check out the HTML source generated to see it), and that >> new hidden field name is still clearly causing CF to continue to do the >> conversion to odbc dateformat. >> >> >> >> I'll grant it's as annoying now as the old approach was then, but at >> least what you tried confirmed things. >> >> >> >> You could raise the concern to Adobe to say, "hey, it's cool and all that >> your server-side validation (old or new approach) can validate dates, but >> why convert it also to odbc date format?" >> >> >> >> /charlie >> >> >> >> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Ajas >> Mohammed >> *Sent:* Thursday, February 12, 2009 12:22 PM >> *To:* [email protected] >> *Subject:* Re: [ACFUG Discuss] weird cfinput vs input stuff. date is >> shown as {d '2009-02-12'} vs 02/12/2009 >> >> >> >> Hi Charlie, >> >> >> Thanks for pointing out _date validation. That would make sense. But if >> you notice, from the code, I use a loop and I am *appending* the index >> number variable #thisrow# to the end of the cfinput absence_date#this_row#. >> So technically, CF should not have done the _date validation as you >> mentioned Ajas, what you're being tripped up by is the fact that >> you're using a suffix of _date for your input field. >> My take is that, this is not the case. >> >> >> >> ------------------------------------------------------------- >> To unsubscribe from this list, manage your profile @ >> http://www.acfug.org?fa=login.edituserform<http://www.acfug.org/?fa=login.edituserform> >> >> For more info, see http://www.acfug.org/mailinglists >> Archive @ http://www.mail-archive.com/discussion%40acfug.org/ >> List hosted by FusionLink <http://www.fusionlink.com/> >> ------------------------------------------------------------- > > >
