"There's not reason you have to abort after the first error." Well, there seems to be no way around it if your setter's argument tag checks for type. Which logically implies that wherever you do that, either in your BO, or in a Validate object as Spike suggests, it winds up to be somewhat "useless". To validate within an object, you need to let everything in first.
"The business object shouldn't attempt to deal with an invalid parameter type, because it doesn't know anything about where that parameter came from, and that's essential for knowing how to respond to the exception." OK, but if the BO is smart enough to require a parameter type, i still think it should be smart enough to respond to all it's requirements in a comprehesive way, instead of one at a time. It may not know what should be done on the UI level, that's true, but using the setter's argument tag to check for type seems to force a one-parameter-at-a-time *this isn't valid* response - so far as parameter type is concerned. "but it's not trying to convert that error into something meaningful to the client (which is a UI issue)." Yes, of course - just answering the generic IsValid questions and passing that out to the UI to intepret. "Just to through another idea out there, have generic setters that don't check type, or even a single set method that takes both a field and a value. Then have a validate method that rolls typechecking and semantic validation into a single method for the whole object. It should generate a collection of validation errors (missing password, birth date isn't a valid date, email is invalid, etc.) which can then be processed however. This is the approach that I've generally taken, and it seems to work quite well." Yes, that's what i've got at the moment, and i like how it's working. It's in the business object, as i've heard around that validation should be there, and it made sense to me. Now i'm wondering about Spike's approach of separating it out into a separate object... :) n. cheers, barneyb On Thu, 12 Aug 2004 17:51:14 +0200, Nando <[EMAIL PROTECTED]> wrote: > I know that could sound very right theroetically, but taking this case of an > object that models a person as an example, you're filling in a form. You do > your best but like all of us, you miss a few fields, 2 have wrongly typed > data, etc. > > Submit. > > The process hits the first argument tag with a mismatched type and throws an > error. I, the programmer, handle it outside the object and give you a > "Please correct ..." message. You correct the first mismatched type and > > Submit. > > Bam. The process hits the second argument tag with a mismatched type and > throws another error and renders another "Please correct ..." message. You > think "Idiot! Who built this thing!" and somewhat angrily correct the second > error. > > Submit. > > Unknowingly, you forgot 2 required fields, and although the process now > clears all the argument tags in the business object, my validation routine > catches the 2 empty variables and returns you to the form with yet another > message. Now you're really pissed. > > Obviously, that's not the way it should work. > > Even if you're handling validation in a separate object for instance, > talking the "It's not the business object's responsiblity to handle wrongly > typed data", the above scenario would still play out in the same way, one > error at a time. Hence, it still seems "irresponsible" to me, and users > would immediately pick it up. > > And so it seems to me that the object asking for validation should be able > to handle all validation comprehensively. Hmmm? Or am i talking myself into > a corner here? > > n. :) -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
