Hi Clint
We have been confused by the same thing on a number of occasions.
Here is an example of what we do:
Imagine you have a car object which can have a trailer associated with it...
<cfset objCarRecord.setTrailerUUID(arguments.strTrailerUUID)>
<!--- the Trailer can be NULL so only load one up if one is supplied --->
<cfif len(arguments.strTrailerNumber)>
<cfset objTrailerRecord =
objCarRecord.getTrailer().load(TrailerUUID=arguments.strTrailerUUID)>
</cfif>
<cfif len(arguments.strTrailerUUID) AND objTrailerRecord.exists() AND
objTrailerRecord.validated()>
<cfset
objCarRecord._getErrorCollection().merge(objTrailerRecord._getErrorCollection())>
</cfif>
You then end up with all the trailer errors merged into your car's
errorCollection. The trouble is that this won't give you the trailer's
translated errors even if you run_getTranslatedErrors().
Ryan and I have been knocking around ideas on this at
http://trac.reactorframework.org/reactor/ticket/61 and
http://trac.reactorframework.org/reactor/ticket/62.
We have solved the problem using a pagelet/custom tag at the view
level to display our errors:
<cfparam name="attributes.record" type="any">
<cfset reactor = application.baseServiceFactory.getBean('reactor')>
<cfoutput>
<cfif attributes.record.validated() AND attributes.record.hasErrors()>
<cfset errorCollection =
attributes.record._getErrorCollection()>
<cfset errorCodes = errorCollection.getErrors()>
<cfset errorMsgs = errorCollection.getTranslatedErrors()>
<div id="error-message">
<p>Your form has #errorCollection.count()# errors</p>
<ul>
<cfloop from="1" to="#arrayLen(errorMsgs)#" index="i">
<cfif errorMsgs[i] EQ errorCodes[i]>
<cfset alias =
listFirst(errorCodes[i],'.')>
<cfparam name="request.dictionaries"
default="#structNew()#">
<cftry>
<cfparam
name="request.dictionaries[alias]"
default="#reactor.createDictionary(alias)#">
<li>#request.dictionaries[alias].getValue(errorMsgs[i])#</li>
<cfcatch>
<!--- TODO: me need
some better way of detecting if a
dictionary object exists for this error "alias" --->
<li>#errorMsgs[i]#
(temp)</li>
</cfcatch>
</cftry>
<cfelse>
<li>#errorMsgs[i]#</li>
</cfif>
</cfloop>
</ul>
</div>
</cfif>
</cfoutput>
hth
Mark
On 9/15/06, Clint Miller <[EMAIL PROTECTED]> wrote:
I'd love some community input on this. It's not like I have tons of
time to devote to this, but I think it's a good idea that just needs
a little improvement. One of the things that I dislike the most is
the way Reactor validation leads to spaghetti code in Model-Glue form
processing. I always end up with lots of branches in one function
whether I put it's a method in a controller or a member of the
service layer.
I think it would also be desirable to have toggle-able validation of
related records. There's times where you want to validate a record
and all of it's related records, but there's also times where you
want to validate just the record you've modified and not concern
yourself with any children. I suppose there's even the case where
you're concerned with just a subset of a record's children.
Interesting stuff.
Clint
On Sep 14, 2006, at 12:42 PM, Ryan Blatz wrote:
> Clint, I haven't been 100% satisfied with reactor's validation either
> and unfortunately haven't had enough free time to work on improving it
> beyond the ticket I've submitted to trac. I look forward to seeing
> your
> work on this.
>
> Ryan
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Clint Miller
> Sent: Thursday, September 14, 2006 11:56 AM
> To: [email protected]
> Subject: Re: [Reactor for CF] validation and errorcollection problem
>
> Ryan, I tried the code you posted and I can see where you're going
> with that. It has revealed the problem to me: an error in one of the
> child records. Now, it's great that it's found, but that really
> needs to be addressed in Reactor. I like the way that Reactor has
> addressed validation conceptually, but there are some real warts
> getting it to work well. I guess that's my opportunity to jump in
> and contribute a better idea...
>
> Thanks!
>
> On Sep 14, 2006, at 10:06 AM, Ryan Blatz wrote:
>
>> I posted some code to the trac
>> <http://trac.reactorframework.com/reactor/ticket/62> that may
>> help. It
>> retrieves all the translated errors for all children objects. To
>> use you
>> can either put it in model\data\record\[tablename]Record.cfc for all
>> tables that are linked or you could put it in reactor's
>> abstractRecord.cfc if you want to modify reactor's core.
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of Clint Miller
>> Sent: Thursday, September 14, 2006 10:56 AM
>> To: [email protected]
>> Subject: Re: [Reactor for CF] validation and errorcollection problem
>>
>> Yes there are linked tables and I suppose it is possible that there
>> could be errors in one of those records. Now the task is finding the
>> errors (which could be daunting in say, a case where there's 5 linked
>> tables....oh wait, that IS the case!).
>>
>> On Sep 14, 2006, at 9:39 AM, Ryan Blatz wrote:
>>
>>> Clint,
>>>
>>> Is it possible that a linked table could have errors in it? If
>>> so haserrors() will return true but getErrorCollection() wont
>>> return any
>>> errors. You would have to do getErrorCollection on the linked
>>> table to
>>> get the errors for that specific table.
>>>
>>> Ryan Blatz
>>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On
>>> Behalf Of Clint Miller
>>> Sent: Wednesday, September 13, 2006 11:34 AM
>>> To: [email protected]
>>> Subject: [Reactor for CF] validation and errorcollection problem
>>>
>>> I'm having some issues with Reactor validation. The user
>>> variable is
>>> a reactor record object. This is the scenario where I'm editing
>>> user information and saving the changes back to the DB. This
>>> anomaly
>>> occurs whether I actually have changes to save or not (i.e., I can
>>> just open the edit form, and do nothing but click save; or I can
>>> open
>>> the edit form, make changes, and click save).
>>>
>>> <cfset arguments.event.trace("errors:", user.validated())>
>>> <cfset user.validate()>
>>> <cfset arguments.event.trace("errors:", user.validated())>
>>> <cfset arguments.event.trace("errors:", user._getErrorCollection
>>> ().count())>
>>> <cfset arguments.event.trace("errors:", user.hasErrors())>
>>> <cfset arguments.event.trace("errors:", user._getErrorCollection
>>> ().getErrors())>
>>> <cfif NOT user.hasErrors()>
>>> <cfset user.save()>
>>> <cfset arguments.event.addResult("editSuccess")>
>>> <cfelse>
>>> <cfset arguments.event.setValue("editErrorCollection",
>>> user._getErrorCollection())>
>>> <cfset arguments.event.addResult("editError")>
>>> </cfif>
>>>
>>> When the code above runs, I'm seeing the output below from Model-
>>> Glue
>>> debugging:
>>>
>>> 16ms errors: NO
>>>
>>> 8672ms errors: YES
>>>
>>> 8672ms errors: 0
>>>
>>> 8672ms errors: true
>>>
>>> 8672ms errors: array [empty]
>>>
>>> So the way I read that, the validated state is being set properly,
>>> there are no errors on the user object, but for some reason
>>> hasErrors
>>> () is returning true. Can anyone help me here? I've loaded up
>>> records outside my application (with a test CFM page) and they
>>> validate correctly (at least as I see it---the error collection
>>> count
>>> () returns 0 and hasErrors() returns false).
>>>
>>> Thanks!
>>>
>>> Clint Miller
>>>
>>>
>>>
>>>
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> -- --
>>> -- -- --
>>> Reactor for ColdFusion Mailing List
>>> [email protected]
>>> Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> -- --
>>> -- -- --
>>>
>>>
>>>
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- -- --
>>> Reactor for ColdFusion Mailing List
>>> [email protected]
>>> Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> -- -- -- -- --
>>>
>>
>>
>>
>>
>>
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> -- --
>> -- -- --
>> Reactor for ColdFusion Mailing List
>> [email protected]
>> Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> -- --
>> -- -- --
>>
>>
>>
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> -- -- -- -- --
>> Reactor for ColdFusion Mailing List
>> [email protected]
>> Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> -- -- -- -- --
>>
>
>
>
>
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- --
> -- -- --
> Reactor for ColdFusion Mailing List
> [email protected]
> Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- --
> -- -- --
>
>
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- -- -- -- --
> Reactor for ColdFusion Mailing List
> [email protected]
> Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- -- -- -- --
>
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
Mark Stanton
Gruden Pty Ltd
http://www.gruden.com
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
