#nested forms

how to do has_many, :through relationships?

discussion https://github.com/nathanvda/cocoon/issues/48

http://www.sitepoint.com/complex-rails-forms-with-nested-attributes/

http://stackoverflow.com/a/21983998/1964078

if there's one overriding theme that i've learned from web development so far, it's FORMS and PARAMETERS. if you can understand those two things, and how your particular DSL, like rails, handles those, you're halfway home.

once again it's rails nested forms that is causing me trouble. from what i've seen the gem simple_form is mostly about formatting and automating other things that you can do manually; that, and the fact that it isn't updated for bootstrap 3, is preventing me from using it.

right now i have an embedded form, and within that embedded form i have checkboxes. rather than using a form_for and a fields_for syntax, and embedding multiple of those, i'm instead using a check_box_tag, which allows you to customize it a bit more.

i'm honestly stuck. trying to get this mothra code to work all day:

def link_to_add_fields(name, f, association, nested_association, locals={}) new_object = f.object.class.reflect_on_association(association).klass.new nested_new_object = f.object.class.reflect_on_association(association).klass.reflect_on_association(nested_association) fields = f.fields_for(association, new_object, :child_index => "new_#{association}") do |builder| debugger builder.fields_for(nested_association, nested_new_object, :child_index => "new_#{nested_association}") do |nested_builder| render(association.to_s.singularize + "_row", locals.merge!(:ff => builder, :fff => nested_builder)) end end link_to_function(name, "add_fields(this, \"#{association}\", \"#{nested_association}\", \"#{escape_javascript(fields)}\")") end

i know the code works if i only have the parent object new_object. but if i try to put a nested object in the same method, it breaks. i'm trying to do this in order to conform to rails' strong parameters. also, because this is the cleanest way to do it. otherwise, I'd have to separate it into two calls, and then bind the two calls onto one button using js. i will probably do that tomorrow morning unless i come up with something better.

Today we made a social media web app that mimics some of the properties of Google+'s circles features.

Users sign up and authenticate like normal. Except this time we added the functionality of allowing users to enter their email and (if they so choose) send a password reset email to them allowing them to change their password if they click the specific link we provide. We also DRYed up the usual code by breaking it down into more helpers and form partials etc. We're really hammering in these important features since they're pretty necessary for almost any web application we'd make in the future. Security and Authorization reigns supreme when information is power!

After signing up or logging in, users can create different groups of users called Friend Circles (thanks Google+!) for which separate groups of friends (other users) for tailored content. The user can then make posts, which include several links and descriptions of links. We actually made several different models to represent our data/objects, but used nested forms and associations to create them all at once (or not at all if the data entered was invalid).

Most of the challenge in this project was creating the nested forms that created all of our objects at the same time through their associations (if you named the form fields effectively) and only saving them all to the database if they were all valid. Some frustration might arise if you filled out a bunch of fields and then were redirected because of one typo or missing validation, say your password was accidentally below the minimum length. A cool feature we added was to auto populate those fields that were persisted through because they were valid so the user didn't have to type them in again. COOL. Using inverse_of option in the has_many relation allowed us to tell rails the other side of the relation so that they could completely be tied together (in transaction like status) by rails magic, enabling two associated objects to be saved simultaneously, and their relation preserved, while automatically assigning foreign_keys at the time they are saved to the database. Pretty cool.

Social Thingamajig

Today we built a social thingamajig... The app would allow users to log-in, sign-up, and log-out; wahoo. The great thing was that creating this logging in, logging out and signing up process felt way more natural than it had before... still required a bit of thought, but mostly around validations, rather than the concept. Other things this app would be able to do: a user could create a circle of friends to share posts with (friends had to be other users); posts would have a title, a body, and links => when a user created a post we needed to create the associated objects with ids(posts and friend circles) and the associated objects with attributes (links). To do this we used nested forms, mass assignment, and some handy methods that rails creates for us ( accepts_nested_attributes_for and #{attribute_name}_ids= ).

Exercise: Employee Database App

We reinforced our rails knowledge with another solo project.  We built an employee database web application in rails. I feel finally pretty good about my rails knowledge in that I think I understand everything.  Here's are some of things I learned today:

Nested Forms. Used when you create two objects with a single submit.  But there is a caveat: If one of the objects created is in a join table, then a nested form is not necessary.

Inverse of.  You use this in nested forms when the two objects you create haven't been saved in the database (ie. no id's) but they need to be linked to each other in order to pass validations.

Today, we set about to build a clone of Y Combinator's Hacker News. My partner, Eric, and I started from the bottom, and spent a good deal of time setting up some complex associations on the models. It was not a very agile way of going about things, I guess, as our approach had pretty much set the architecture in stone. Most of the complexity came in trying to model the relationship between nested comments. We ended up going with an ancestors table that joined the comments table on itself. Our comment model was a beast. Here's what it looked like:

  attr_accessible :article_id, :author_id, :body, :parent_comment_id

  validates :body, :author_id, :presence => true

  belongs_to :article, :inverse_of => :comments

  belongs_to :user

  belongs_to :parent_comment, :class_name => "Comment"

  has_many :child_comments, :class_name => "Comment", :foreign_key => :parent_comment_id

  has_many :comment_ancestors, :class_name => "CommentAncestry", :foreign_key => :descendant_id

  has_many :comment_descendants, :class_name => "CommentAncestry", :foreign_key => :ancestor_id

  has_many :ancestors, :through => :comment_ancestors

  has_many :descendants, :through => :comment_descendants

Crazy, huh? After that travail we proceeded to build the controllers, bake in authentication, and finally work on the views, with our first-ever implementation of nested forms. I introduced Eric to Twitter Bootstrap towards the end of the day, and we immediately made the site much prettier. I stayed a good bit of time after class completing the views, adding in validations, and refining the look.