Re: [CFCDev] Form Validation

[Peter J. Farrell]

Dawson, Michael wrote: Peter, I'm back to the issue of how you validate non-string values with your process.  (I love your bean creator and how easy it generates these objects, BTW.) Thanks Mike...hopefully inprovements are on the way in version 2 (I'm waiting my ISP to upgrade to MX7 is a few weeks - otherwise there won't be an online example).  I need to clean up the JS in the beaner as it's rather messy. Do you use the setErrors/getErrors methods?  I've abandoned them for a more favorable method described below.  I'm wondering if I should release them as a tool kit. Let's say you have two variables: firstName and birthDate.   firstName is a string, of course, but birthDate is a date type.  If you set "date" to the argument type in the setBirthDate, but pass it a non-date value, where do you handle the errors? It depends on how your bean is populated.  If I'm populating from a form, I'll usually set the data type to "any" for a date field to accept anything (unless I'm sure it's really a date - such has a js calendar event etc).  I use "any" to show a difference between plain old strings and something special being done in the validate. In the end, it all depends on how your UI is done.  Dates can be set from drop downs, fields or a combination of both.  Your init() might require a few extra arguments and some string concatenating.  If I recall correctly, mach-ii init() beans with argumentCollection anyways, so any extra arguments in your init() won't be a bother. I'm still rather new to Mach-II and I'm still learning a lot every day...I expect some of my thoughts to change over time. Do you, personally, type all your arguments as strings and then validate the data, or do you type them correctly, then wrap with try/catch blocks? I usually just "catch" errors inside my validate function.  I don't consider the bean "good" until validation has been done anyways.  I have a special generic form error handler that I use to "hold" error codes on validation (error code, field name and location [the bean name] - it's easy to track down where errors are being set) and I pass in the errorHandler to the validate() method in which it returns the error handler.  I also have a errorMessage class that reads my errorHandler and outputs html with the correct message text for the error code inside a cfsavecontent for display on my form (I also have dev and production mode - so the output differs [i.e. more debug info]). I hate to re-hash this, but it's been a while since it was last discussed and I was hoping for some newer experiences and thoughts on this topic.   M!ke No problem...I don't pretend to have all the answers here and I'm open to suggestions on improvement.  I know that all forms are just strings anyways - I just don't think you have to have your bean be all strings too...  In the end, you have to fudge things a bit sometimes as well and it depends on how your UI is designed. Sorry for replying so late...I was out sick yesterday and barely did anything except watch 8 episodes of Alias on DVD. Best, .Peter -- Peter J. Farrell :: Maestro Publishing blog :: http://blog.maestropublishing.com email :: [EMAIL PROTECTED] Create boilerplate beans! Check out the Mach-II Bean Creator - free download. http://blog.maestropublishing.com/mach-ii_beaner.htm Shields up, Mr. Sulu. Arm phasers. Ready photon torpedoes. -- ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org