Barney, a while back you wrote: "Some of my BOs are nothing more than get/set/validate (where the validation is generated based on the DB schema), and some are masses of composition and business logic methods, including custom validation."
I'm curious, if you want to validate your BO before, say, you send it to a DAO, are you concerned about instantiating a potentially "heavy" CFC just to set for valid data? I'm just curious. On advantage I can see to having a "Bean" that validates itself before you create a BO is that you avoid unnecessarily creating a complex BO if the data isn't valid. I know in general we shouldn't design around possible performance issues but rather actual performance issues, I just thought I'd get your take. Thanks. On 9/1/05, Brian Kotek <[EMAIL PROTECTED]> wrote: > I'd do something like this in real life: > > <fuseaction name="register" access="public"> > <xfa name="processRegistration" value="processregistration" /> > <invoke object="application.userManager" > methodcall="getUser( 'User', variables )" > returnvariable="user"/> > <invoke object="user" > methodcall="getValidationErrors()" > returnvariable="validationErrors" /> > <do action="v_components.formatValidationErrors" > contentvariable="content.validationErrors" /> > <do action="v_user.registerForm" > contentvariable="content.pageContent"/> > </fuseaction> > > <fuseaction name="processregistration" access="public"> > <invoke object="application.userManager" > methodcall="getUser( 'User', variables, attributes )" > returnvariable="user"/> > <if condition="#user.validate()#"> > <true> > <!-- Was the registration successful? --> > <invoke object="application.userManager" > methodcall="processRegistration( user > )"/> > <relocate url="#myFusebox.originalCircuit#.success"/> > </true> > <false> > <!-- If registration was not successful, display the > registration > form again. --> > <do action="register" /> > </false> > </if> > </fuseaction> > > An empty user object won't have any validation errors (empty array), > but when validate() is run the error array is populated within the > user object. > > On 9/1/05, wolf2k5 <[EMAIL PROTECTED]> wrote: > > On 8/26/05, Brian Kotek <[EMAIL PROTECTED]> wrote: > > > In fact I know I'm on a posting blitz, but if you handled the creation > > > of the TO, the BO, and validation check in the manager CFC, you could > > > actually simplify it to this: > > > > > > <fuseaction name="storeContact"> > > > <invoke object="application.contactManager" > > > methodcall="save( attributes )" > > > returnVariable="result" /> > > > <if condition="#result.status#"> > > > <true> > > > <do action="success" /> > > > </true> > > > <false> > > > <do action="showContactForm" /> > > > </false> > > > </if> > > > </fuseaction> > > > > This code looks even better (shorter), but how would you let the user > > know of the errors in the form if the validation fails? > > > > Thanks. > > > > > > ---------------------------------------------------------- > > 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]
