Re: [Reactor for CF] validation and errorcollection problem

Fri, 15 Sep 2006 07:20:37 -0700

Thanks for the history of this, Mark. It's great to know a little background information about how this has been an issue and some potential workarounds. I'd love to spend some time thinking about a good way to solve this. Right now, however, I have to finish a project and go live within the next few weeks. It's my first MG:Unity project and overall I've been very pleased. Perhaps after that is over I will have some time to contribute to Reactor. 

Clint

On Sep 14, 2006, at 6:33 PM, Mark Stanton wrote:


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/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 







-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Reply via email to