Confirmation Checkboxes - any good ideas?

I have a site in development that I need to customer to confirm a few
things before they can proceed to the payment page. I intend to
present them with the relevant questions and then check that they have
answered them e.g. have you read the T's & C's. Are you over 18? Are
you resident in the UK etc etc. I do not need to record these
necessarily.

Is there a simple way of validating these in the controller and then
returning the messages in the same way as Active Record would do so I
can use the same form builder as the rest of the site (I do inline
errors with ToolTip)?

I have considered just implementing a model called "Confirmation" with
a 1-1 relationship with order but I think this is a little overkill
and the number of confirmations may change over time and vary. So I
would need a to implement a confirmation answer model and a
confirmation question model. All seems a bit complex. How about just
serializing a hash as a database column with the questions as the key
and the values entered?

Has anyone got any good ideas?

Thanks,

O.
--~--~---------~--~----~------------~-------~--~----~
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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

My approach on things like this has been to add the attribute to the
model with attr_accessor, and then setting up whatever validations I
need. E.g.

attr_accessor :terms_of_service

validates_acceptance_of :terms_of_service

Seems to work fine (I've had issues where I've been passing such a model
along a multi-action process by storing it in the session, though).

(Still not sure from a business/legal sense why you wouldn't need these
to be persistent attributes, however)

dwh


icke wrote:

I have a site in development that I need to customer to confirm a few
things before they can proceed to the payment page. I intend to
present them with the relevant questions and then check that they have
answered them e.g. have you read the T's & C's. Are you over 18? Are
you resident in the UK etc etc. I do not need to record these
necessarily.

Is there a simple way of validating these in the controller and then
returning the messages in the same way as Active Record would do so I
can use the same form builder as the rest of the site (I do inline
errors with ToolTip)?

I have considered just implementing a model called "Confirmation" with
a 1-1 relationship with order but I think this is a little overkill
and the number of confirmations may change over time and vary. So I
would need a to implement a confirmation answer model and a
confirmation question model. All seems a bit complex. How about just
serializing a hash as a database column with the questions as the key
and the values entered?

Has anyone got any good ideas?

Thanks,

O.

--~--~---------~--~----~------------~-------~--~----~
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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Denis Haskin wrote:

My approach on things like this has been to add the attribute to the
model with attr_accessor, and then setting up whatever validations I
need. E.g.

attr_accessor :terms_of_service

validates_acceptance_of :terms_of_service

Seems to work fine (I've had issues where I've been passing such a model
along a multi-action process by storing it in the session, though).

(Still not sure from a business/legal sense why you wouldn't need these
to be persistent attributes, however)

Agreed on all counts. Booleans are cheap, and you probably want to
store something that proves acceptance.

dwh

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen (AT) marnen (DOT) org
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

You would need to add an attr_accessor and validates_presence_of in
your model...

class Model < ActiveRecord::Base

attr_accessor :field_to_validate
validates_presence_of :field_to_validate

end



On Nov 5, 8:10*am, icke <owain.mcgu... (AT) gmail (DOT) com> wrote:

I have a site in development that I need to customer to confirm a few
things before they can proceed to the payment page. *I intend to
present them with the relevant questions and then check that they have
answered them e.g. have you read the T's & C's. *Are you over 18? *Are
you resident in the UK etc etc. *I do not need to record these
necessarily.

Is there a simple way of validating these in the controller and then
returning the messages in the same way as Active Record would do so I
can use the same form builder as the rest of the site (I do inline
errors with ToolTip)?

I have considered just implementing a model called "Confirmation" with
a 1-1 relationship with order but I think this is a little overkill
and the number of confirmations may change over time and vary. *So I
would need a to implement a confirmation answer model and a
confirmation question model. *All seems a bit complex. *How about just
serializing a hash as a database column with the questions as the key
and the values entered?

Has anyone got any good ideas?

Thanks,

O.
--~--~---------~--~----~------------~-------~--~----~

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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Ha, should have refreshed before I submitted my answer.

On Nov 5, 9:42*am, lardawge <larda... (AT) gmail (DOT) com> wrote:

You would need to add an attr_accessor and validates_presence_of in
your model...

class Model < ActiveRecord::Base

*attr_accessor :field_to_validate
*validates_presence_of :field_to_validate

end

On Nov 5, 8:10*am, icke <owain.mcgu... (AT) gmail (DOT) com> wrote:

I have a site in development that I need to customer to confirm a few
things before they can proceed to the payment page. *I intend to
present them with the relevant questions and then check that they have
answered them e.g. have you read the T's & C's. *Are you over 18? *Are
you resident in the UK etc etc. *I do not need to record these
necessarily.

Is there a simple way of validating these in the controller and then
returning the messages in the same way as Active Record would do so I
can use the same form builder as the rest of the site (I do inline
errors with ToolTip)?

I have considered just implementing a model called "Confirmation" with
a 1-1 relationship with order but I think this is a little overkill
and the number of confirmations may change over time and vary. *So I
would need a to implement a confirmation answer model and a
confirmation question model. *All seems a bit complex. *How about just
serializing a hash as a database column with the questions as the key
and the values entered?

Has anyone got any good ideas?

Thanks,

O.


--~--~---------~--~----~------------~-------~--~----~

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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thank you all for your replies.

I agree that Booleans are cheap in terms of storage but I not really
want to keep adding database columns through the model as the number
of questions vary over time and I do not really want to go through all
of the hassle of a child table to hold them. I'm thinking of having
one (persistent) attribute on the model which is a serialized hash of
the questions and the answers. Any thoughts. Am I just being lazy?

O.
--~--~---------~--~----~------------~-------~--~----~
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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

As long as you don't need to query on those values ("send email to all
users who haven't yet agreed to the latest T&Cs"), the serialization
approach will work.

(and with accepts_nested_attributes_for and fields_for, how much work is
a child table, really? ;-) )

dwh

icke wrote:

Thank you all for your replies.

I agree that Booleans are cheap in terms of storage but I not really
want to keep adding database columns through the model as the number
of questions vary over time and I do not really want to go through all
of the hassle of a child table to hold them. I'm thinking of having
one (persistent) attribute on the model which is a serialized hash of
the questions and the answers. Any thoughts. Am I just being lazy?

--~--~---------~--~----~------------~-------~--~----~
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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Use validates_acceptance_of

See
http://stackoverflow.com/questions/445293/ruby-on-rails-confirmation-page-for-activerecord-object-creation

Euwyn


On Thu, Nov 5, 2009 at 11:22 AM, Denis Haskin <denis (AT) haskinferguson (DOT) net>wrote:

As long as you don't need to query on those values ("send email to all
users who haven't yet agreed to the latest T&Cs"), the serialization
approach will work.

(and with accepts_nested_attributes_for and fields_for, how much work is a
child table, really? ;-) )

dwh

icke wrote:

Thank you all for your replies.

I agree that Booleans are cheap in terms of storage but I not really
want to keep adding database columns through the model as the number
of questions vary over time and I do not really want to go through all
of the hassle of a child table to hold them. I'm thinking of having
one (persistent) attribute on the model which is a serialized hash of
the questions and the answers. Any thoughts. Am I just being lazy?

--~--~---------~--~----~------------~-------~--~----~
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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Denis Haskin wrote:

As long as you don't need to query on those values ("send email to all
users who haven't yet agreed to the latest T&Cs"), the serialization
approach will work.

It will work, but it's smelly in DB terms.

(and with accepts_nested_attributes_for and fields_for, how much work is
a child table, really? ;-) )

And with proper use of migrations, how much work is adding columns,
really?

dwh

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen (AT) marnen (DOT) org
--
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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 (AT) googlegroups (DOT) com
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe (AT) googlegroups (DOT) com
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---