Sam Slotsky

The validation could simply be contacts.all?(&:valid?). Contact defines its own validation of course.

There is nothing wrong with accepts_nested_attributes_for. This is what you should use in your typical case. My post describes a non-typical case. ContactListForm is not an ActiveRecord object, it is an object that includes ActiveModel::Model, which does not support accepts_nested_attributes_for.

Good question! If you include ActiveModel::Validations you can write the same validators as you would with ActiveRecord.

However, in this case, our form is just a collection of Contact objects, which are ActiveRecord and have their own validations. When I save the ContactListForm, it attempts to save all the contacts. In doing so, each contact has its error_messages available.

I enjoyed this post, and was extremely impressed by the free tacos, although it did give me the impression that you'd probably really hate the title of the post I made about inheriting from JavaScript's Array... https://coderwall.com/p/3jenzw?i=1&p=1&q=author%3Asslotsky&t%5B%5D=sslotsky

I see. This sounds pretty difficult, but maybe define a Tax class with ActiveModel::Model setup and then your Invoice model can override self.reflect_on_association so that when :taxes is passed in, it will return an object where the klass method returns your Tax class (your method will call super if anything else is passed in). Then you should be able to get your fields in the form by defining attributes in your Tax class.

How to handle submission would be a different story. You might have to start with an ActiveModel::Model object that encapsulates the Invoice and displays it in a f.fields_for :invoice do |invoice_fields|, and then the taxes would show up as a nested form within invoice_fields.

I think I see what you mean. You're trying to dynamically add tax information using Ryan B's technique, but you don't have a tax class of any kind. In your case you wouldn't even use reflect_on_association. You would have to do something else to generate the fields you need and add them to the form.

So you have multiple taxes for an invoice, but you're not storing tax records in their own table. How do you store them on the invoice then? Do you have a field for each possible type of tax? A single field that stores a JSON string?

The answer for you might be to use an ActiveModel form object for your main object. When it's submitted, you can do whatever calculations you need to with the tax parameters and then create your Invoice.

@geordee I'm not sure what your use case is but this doesn't sound very clean. If you can make that input part of the form for the master entity that would make a whole lot more sense.

Having said that, in general you probably could use ActiveModel as a detail entity if there were a good use case for it. You'd probably have to define the detail entity as a virtual attribute on your ActiveRecord model and maybe add a before_save hook that validates your detail entity if it's present. But this doesn't sound all that clean either. Maybe understanding your use case would be helpful.

I like where you're going with this. Question: what if you want to use this class on both the client side and the server side? How would you solve this problem?