If you store the fields in a serialized Hash like in this episode then there's no convenient way to select/sort by these values using ActiveRecord (but you could sort them in Ruby using Enumerable#sort_by. You should check out Hstore (episode #345).

Wow! I feel like I need to watch this several times in slow motion to absorb it. It's amazing how much you can pack into 14 minutes. It also seems like really understanding dynamic forms could simplify my database architecture.

I'm not sure if I'm thinking this through correctly. Would people agree that ProductField names should not be update-able. In the serialized hash the key would remain what it was originally as, so unless the developer goes back and sanitizes all of the product properties in the database, or adds some method_missing translations to the ProductType class a back end client name update would break all of the existing products of that type. Maybe?

Actually had this problem in a project a while back. Ended up using a UUID as the property's hash key, but using a display_name when displaying them, allowing the field names to change without breaking the rest of it. It was complicated, though, and I'm not sure doing so would work well with Hstore. It did add a few extra layers of abstraction and wasn't very fun to work with. @phillyslick also makes a good point that deleting fields doesn't delete the data from the properties hash. The only way we found to work around that was to update all the items of a certain type if the type changed.

This is a great cast, but in my experience doing this kind of thing can bring you down a pretty slippery slope if the users aren't warned of the consequences. With great flexibility comes great responsibility, and diligence and well tested rake tasks should be built into the system.

Absolutely unbelievable. My partner and I just finished building this very type of functionality into an app. It took us months to figure out a plausible approach, and here it is in 15 minutes. Someone give this man a medal.

I immediately cringed when I saw you eschewing the built-in ActiveModel::Validations validators for a custom validate_properties method. Then when your solution to allowing a more complex field to be added was to hard code it I lost all faith.

I actually had to do something similar about a year ago for a project collecting electronic signatures for forms. To meet my needs I used a dynamically defined proxy object that would allow the use of any built in validators on any of the attributes, then passed that to the form builder. I'd love to see this thought through better, but it already more effectively re-uses components that have already been built and tested.

Corey - could you go into a little more detail on the proxy object? I'm looking to do something along the lines of letting users (admins) make new forms for the public to submit data to. Following this screen cast I've got it implemented but I'm a Ruby and RoR n00bie.

I've the situation where what data I need to collect is custom per situation, so hard coding Models isn't an option so I am using the Admin's building of a collection of form fields and then dynamically building a model that is then used to make the form for the public and store the data in Mongodb. I've read a bit on factory design patterns and template patterns but I've not yet tried to apply this within rails to even see if it would work.

I'm throwing an error trying to recreate this example. Instead of products, I am using forms. Any help or explanation would be very helpful, because this is over my head, but i'd like to learn what is going on here.

NoMethodError in Forms#new

Showing /Users/Admin/Documents/development/form_builder/app/views/forms/fields/_text_field.html.erb where line #3 raised:

Alan - the issue was in the product_types_controller, but your solution is in the products_controller. There might also be a problem in the products_controller, but initially, since product_types contains the :fields_attributes hash, the solution needs to be in permitting params[:product[:fields_attributes]] or somesuch. I notice the solution link you gave from stack makes the same mistake. Or, is it a mistake?