About what I expected Barney. Something like this would, I think, not
only be closer to what you describe but also closer to bringing my
terminology into line with the standard (as far as such a standard
exists):
<fuseaction name="processregistration" access="public">
<!-- Populate a TO with the data posted from the form. -->
<invoke object="application.TOManager"
methodcall="getTO( 'User', attributes )"
returnvariable="userTO"/>
<!-- Pass the TO to the User Manager, which will create, validate,
and store the User BO.
It will return a struct called result, with keys for success
and
validationErrors. -->
<invoke object="application.userManager"
methodcall="save( userTO )"
returnvariable="result"/>
<if condition="#result.success#">
<true>
<relocate url="#formatURL(
'#myFusebox.originalCircuit#.success' )#"/>
</true>
<false>
<!-- Format the validatioErrors array returned in the
result struct. -->
<do action="v_components.formatValidationErrors"
contentvariable="content.validationErrors" />
<!-- Redisplay the form. -->
<do action="register" />
</false>
</if>
</fuseaction>
On 9/1/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
> Nope, sure aren't. Validation is really the fundemental entity-level
> business operation, in my view. If you are concerned, implementing a
> pooling mechanism (perhaps where pool management is handled
> asynchronously via the async event gateway), will alleviate the
> instantiation problem, because you'll just be pulling an unused
> instance and populating it.
>
> That'd be the first tact I'd consider if I found instantiation
> overhead to be a problem, but I haven't gotten to that point yet (I.e.
> hardware is still cheaper than optimizing). And really, I suspect
> that "do something" request are almost never the most heavily loaded
> parts of an application, so this bottleneck won't arise very often.
>
> You said "if you want to validate your BO before, say, you send it to
> a DAO", as if implying that sometimes you don't do that, and therefore
> potentially allow persistance of invalid entities? My managers (which
> are also autogenerated) are the only objects that get to talk to the
> DAOs, and they never do insert or update without a valid BO. I will
> say that I've broken that rule once, for user accounts that were
> migrated and the old structure had different requirements than the
> new, and so it was possible for old accounts to be invalid. We had to
> deal with that, so I added a flag that allowed persistance of a
> invalid user object when explicitly requested, because we needed to do
> some operations that weren't user initiated (like updating expired
> passwords), and so couldn't force the "user" to fix the invalid info.
>
> cheers,
> barneyb
>
----------------------------------------------------------
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]
