If you validate the parent, it will validate the parent and all child objects. I believe you can just validate the child objects without validating the parent. Child objects extend the parent, but have their own utility object.
I have not looked at the child objects recently.
Teddy
On 9/14/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/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
<cf_payne />
Blog: http://cfpayne.wordpress.com/
Atlanta CFUG: http://www.acfug.org
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Reactor for ColdFusion Mailing List
[email protected]
Archives at: http://www.mail-archive.com/reactor%40doughughes.net/
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
