>> I'm liking Spikes idea of a separate Validation object more and more.
I'm sorry, but I can't see the point of creating a seperate object to do this. It's tightly coupled to the form sure, but each value is actually bound to the form "controls". our whole app's UI are form controls using taglibs: dozens per screen, hundreds of screens. We allows the form "controls" to validate themselves (we even have URL "controls"). these controls are then bound to the BO's method arguments. The bottom line is that each control need to know how to behave - even to the point of displaying it's own error messages and highlighting bad data. The idea comes from the fact you assemble a form to take input to eventually run a BO process. within each control is the datatype and required (T/F), etc. Controls that depend on others (dual textboxes, etc) are macro-type controls that still have the same idea behind them. The whole thing comes down to working with known API's (ie: you know what the BO process needs and you build the UI accordingly - the rest happen auto-magically). sure this is nothing new. It's a mixture of bog-standard VB form validation (and now ASP.NET) and "Design By Contract" (al la Eiffel) with the BO to supply certain values (there's an additional safety net at the start of the BO, but that just throws a basic error since they shouldn't ever get to that point - they've broken their contract) I just can't see the value of tightly coupling an object to a whole form. What happens if you add another textinput control because you've had to add another method argument? re-write the validation object? yuck... why bother when simply adding the UI element and setting attributes (eg datatype="date" required="true") will do this for you? just my 2c worth. 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]
