In Mach-II, there is the notion of writing a "bean" CFC that models your form data and also does validation on it. I like the idea of creating an object that has properties that map to all my form fields, and then writing a single validate() method on the CFC that contains all of the data validation logic. It bundles all of the code about a form together in one place instead of spreading it out all over and making it difficult to maintain.
Jon Block's Bean Creator is a great tool for quickly generating the CFC code for your bean: http://cf2.jonathanblock.com/bean.cfm Once the bean is created, you can write all your data validation logic inside the validate() method. Depending on how your application is structured, you really just need to provide for a few things: (1) After the form is submitted, get your form data into the bean using the various set methods, (2) Perform your validation (3) Do the calculation (4) Redisplay the form to the user In a more traditional app, you'd just do #1 and #2, and then based on whether validate() returns true or false, either continue with your app flow (writing to the DB in most cases) or generate an error message and redisplay the form to the user. Here you're introducing a few new steps, but this isn't uncommon since many, many applications have the user submit the form, redisplay the data so they can verify it's correct, and then "confirm" to save their data. If you don't want to use Mach-II or already have your own framewor, all you really need to do is write a few CFCs to help you with a few things... (1) Taking your form data and an instance of the bean and populating it with the form data, (2) Calling the validate method and handling the result appropriately, (3) Providing for a quick way to preserve state of the form when an error message occurs, making sure the user doesn't lose the data they entered into the form, (4) Displaying error messages appropriately This is a topic very near and dear to my heart because I HATE form validation :) Apologies if my response was long winded or not what you're looking for... -Cliff On 7 May 2005 16:33:54 -0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > This may not be the answer you are looking for, but I had a similar code > seperation > problem this week. > > I needed to calculate some numbers and display them > BEFORE they were saved to the database. I didn't want to write the display > calculations in javascript and the database calculations in coldfusion. I > wrote cfc methods to do the calculation, and them used those methods for both. > > I used some XMLHTTPRequest stuff (Ajax) to call a coldfusion script that > invoked the calculation functions, and then returned the result to the > browser. > > When the data was saved, I again called the calculation functions, and stored > the results. > > It may sound like alot of work, but I only wanted the calculations > in one place to prevent the two sets of code from getting out of sync. > > It wouldn't be too difficult to put all your form validation into a function, > and then pass the form contents to the server via a similar method, displaying > the validation results before they ever submit the form. > > This may not be > what you were thinking of at all... > > -Sam Curren > > --- [email protected] > wrote: > > Hi guys, > > > > > > This may be a little of topic but possibly not. With > regards to form > > > validation, client side validation is helpful but can > be side-stepped as can > > > the use of hidden fields, so logically this makes > server side validation a > > > neccessity. Consequently my code ends up riddled > with validation logic; is > > > it the right type, does it fit in a range, does > it match a pattern etc. Is > > > there a design pattern I could use that would > make doing this sort of thing > > > cleaner or possibly a server-side validation > library / cfc available to help > > > with this? > > > > > > Cheers, Pete (aka lad4bear) > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > You are subscribed to cfcdev. To unsubscribe, send an email to > > [email protected] > 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/[email protected] > > > > > > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] 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/[email protected] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]
