On a side note, if your application primarily relies on user generated
forms, a documentbased/key-value database might be a better option.
I'm talking about databases like MongoDB and the likes.
http://www.slideshare.net/wonko/using-mongomapper-to-store-dynamic-data
As mentioned below, the whole stack for implementing dynamic fields in
a relational database adds up to 4 or more models. If you want to
retrieve all the data, you'll end up with quite a few joins, which
might impact performance quite a bit.
On 27 Aug 2010, at 18:24, Ratnadeep wrote:
Ok, now i have implemented something similar to this from database
perspective, but not from views and actual html generation thing.
Will give try to above idea of for generating actual html using
form_for method itself.
On Tue, Aug 10, 2010 at 11:48 PM, Nat Budin <[email protected]>
wrote:
This is a pretty common use case in lots of applications, and
depending on what sorts of customization you want to allow your users,
you can get quite complex with it if you like. But in the simple
case, you basically want four model classes, divided roughly into a
set of two for the form creators, and two for the users filling out
the forms. Here's an example using your terminology:
UserForm is a form created by a user
FormField is a field on a UserForm, which contains a caption, a type,
and a txtname
UserForm has_many :form_fields
...
Of course, this is only one way to do it, and I'm sure others have
differing opinions on approaches... :)
Best regards
Peter De Berdt
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
