Rails - Jan 2009 - should I use the validation framework (e.g. add_to_base) to pass back multiple data errors that are identified???

Hi,

I have an "automation" model with some config data.  When it runs it
looks
across other models and does some matching, however it also builds up a list
of "duplicate data" type issues identified as part of the routine.

In terms of how I capture this array of duplicate data issues and pass to a
view for display what would Rails best practice suggest? For example:
* use validation framework (e.g. add_to_base, and then the helper tags to
display) even though the data is not associated with attributes in the model
* extend an application_error Exception to include an Array
* just use an array to pass back to controller, which stores as an instance
variable (@duplicates) and write custom code to display in view (i.e.
won''t
use error/validation tags)

thanks


-- 
Greg
http://blog.gregnet.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

(bump)

On Tue, Jan 20, 2009 at 5:00 PM, Greg Hauptmann <
greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi,
>
> I have an "automation" model with some config data.  When it runs
it looks
> across other models and does some matching, however it also builds up a
list
> of "duplicate data" type issues identified as part of the
routine.
>
> In terms of how I capture this array of duplicate data issues and pass to a
> view for display what would Rails best practice suggest? For example:
> * use validation framework (e.g. add_to_base, and then the helper tags to
> display) even though the data is not associated with attributes in the
model
> * extend an application_error Exception to include an Array
> * just use an array to pass back to controller, which stores as an instance
> variable (@duplicates) and write custom code to display in view (i.e.
won''t
> use error/validation tags)
>
> thanks
>
>
> --
> Greg
> http://blog.gregnet.org/
>
>
>

-- 
Greg
http://blog.gregnet.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I don''t necessarily see what''s wrong with add_to_base.  Seems
somewhat
logical to me but I don''t really know what you''re attempting
to do :)

On Tue, Jan 20, 2009 at 7:09 PM, Greg Hauptmann
<greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> (bump)
>
> On Tue, Jan 20, 2009 at 5:00 PM, Greg Hauptmann
> <greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Hi,
>>
>> I have an "automation" model with some config data.  When it
runs it looks
>> across other models and does some matching, however it also builds up a
list
>> of "duplicate data" type issues identified as part of the
routine.
>>
>> In terms of how I capture this array of duplicate data issues and pass
to
>> a view for display what would Rails best practice suggest? For example:
>> * use validation framework (e.g. add_to_base, and then the helper tags
to
>> display) even though the data is not associated with attributes in the
model
>> * extend an application_error Exception to include an Array
>> * just use an array to pass back to controller, which stores as an
>> instance variable (@duplicates) and write custom code to display in
view
>> (i.e. won''t use error/validation tags)
>>
>> thanks
>>
>>
>> --
>> Greg
>> http://blog.gregnet.org/
>>
>>
>
>
>
> --
> Greg
> http://blog.gregnet.org/
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I suppose I was questioning whether from a best practice position whether
using Rails input validation framework (focused at the model level), for
collecting non-severe error messages that cut across a whole controller
action (e.g. multiple models may be involved), and for which they are not
focused at input validation but rather error that occuring during
processing, for the purpose of bundling these up and passing to a view and
displaying?   hope this makes sense in terms of clarifying my Rails best
practice question.

On Wed, Jan 21, 2009 at 11:32 AM, Brian Hogan
<bphogan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I don''t necessarily see what''s wrong with add_to_base. 
Seems somewhat
> logical to me but I don''t really know what you''re
attempting to do :)
>
> On Tue, Jan 20, 2009 at 7:09 PM, Greg Hauptmann
> <greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > (bump)
> >
> > On Tue, Jan 20, 2009 at 5:00 PM, Greg Hauptmann
> > <greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> >>
> >> Hi,
> >>
> >> I have an "automation" model with some config data. 
When it runs it
> looks
> >> across other models and does some matching, however it also builds
up a
> list
> >> of "duplicate data" type issues identified as part of
the routine.
> >>
> >> In terms of how I capture this array of duplicate data issues and
pass
> to
> >> a view for display what would Rails best practice suggest? For
example:
> >> * use validation framework (e.g. add_to_base, and then the helper
tags
> to
> >> display) even though the data is not associated with attributes in
the
> model
> >> * extend an application_error Exception to include an Array
> >> * just use an array to pass back to controller, which stores as an
> >> instance variable (@duplicates) and write custom code to display
in view
> >> (i.e. won''t use error/validation tags)
> >>
> >> thanks
> >>
> >>
> >> --
> >> Greg
> >> http://blog.gregnet.org/
> >>
> >>
> >
> >
> >
> > --
> > Greg
> > http://blog.gregnet.org/
> >
> >
> >
> > >
> >
>
> >
>

-- 
Greg
http://blog.gregnet.org/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

You could always go with the "business logic always goes in models"
rule, and the easy implementation is to do what you''re doing.  Or you
could build a brand new model with its own errors collection to
encapsulate what it is you''re doing (presenter pattern?).  I
don''t
think there''s really a *best practice* for this... if you can justify
the use to yourself based on what business rules you''re trying to
implement, that may be your best practice. :)

My rule is always that NOTHING goes in the controller.  A lot of times
I''ve done an after_validation callback and shoved stuff into the
errors.base before. Done stuff with cc processing that way too.

I''d love to hear from others on this too.

On Tue, Jan 20, 2009 at 8:13 PM, Greg Hauptmann
<greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I suppose I was questioning whether from a best practice position whether
> using Rails input validation framework (focused at the model level), for
> collecting non-severe error messages that cut across a whole controller
> action (e.g. multiple models may be involved), and for which they are not
> focused at input validation but rather error that occuring during
> processing, for the purpose of bundling these up and passing to a view and
> displaying?   hope this makes sense in terms of clarifying my Rails best
> practice question.
>
> On Wed, Jan 21, 2009 at 11:32 AM, Brian Hogan
<bphogan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> I don''t necessarily see what''s wrong with
add_to_base.  Seems somewhat
>> logical to me but I don''t really know what you''re
attempting to do :)
>>
>> On Tue, Jan 20, 2009 at 7:09 PM, Greg Hauptmann
>> <greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>> > (bump)
>> >
>> > On Tue, Jan 20, 2009 at 5:00 PM, Greg Hauptmann
>> >
<greg.hauptmann.ruby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I have an "automation" model with some config data. 
When it runs it
>> >> looks
>> >> across other models and does some matching, however it also
builds up a
>> >> list
>> >> of "duplicate data" type issues identified as part
of the routine.
>> >>
>> >> In terms of how I capture this array of duplicate data issues
and pass
>> >> to
>> >> a view for display what would Rails best practice suggest? For
example:
>> >> * use validation framework (e.g. add_to_base, and then the
helper tags
>> >> to
>> >> display) even though the data is not associated with
attributes in the
>> >> model
>> >> * extend an application_error Exception to include an Array
>> >> * just use an array to pass back to controller, which stores
as an
>> >> instance variable (@duplicates) and write custom code to
display in
>> >> view
>> >> (i.e. won''t use error/validation tags)
>> >>
>> >> thanks
>> >>
>> >>
>> >> --
>> >> Greg
>> >> http://blog.gregnet.org/
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Greg
>> > http://blog.gregnet.org/
>> >
>> >
>> >
>> > >
>> >
>>
>>
>
>
>
> --
> Greg
> http://blog.gregnet.org/
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---