Thinking about AssociationFu as complex_forms

Been thinking about the AssociationFu plugin lately, about how it will be important for the rental contract form, which is very complex, containing fields for several associations objects of the contract (account, contract_line_items and associated_account_users).

First of all, a post by Aaron Pfeifer, "acts_as_what?" thankfully made me think about the plugin again. The name always bugged me a little. A "Fu" plugin in my mind is one that is powerful, does a lot and takes a lot of burden off the developer/programmer. However, it is pretentious sounding and hackneyed. So I'm thinking of renaming it to hint at its origins, Ryan Bate's complex forms series, since its purpose is solely to make complex forms easier. So I'm thinking of eventually renaming it the "complex_forms" plugin.

But that's not the motivation behind this post. My thoughts for the plugin are to give it unobtrusive javascript hooks and provide the Javascript to give it AJAXy behavior.

I've got it most of the way there but there's the pesky problem of having the form work without Javascript. The ID for any new_attributes object will have to be filled in by the plugin with a sequential number starting at "1" when the new object is built -- but then set to nil before being saved and then set back to a sequential number should the object fail validation and the new objects are not saved.

Yeesh. The reason for assigning fake IDs to new objects is to allow checkboxes to operate properly on new objects. Rails creates hidden fields to indicate unchecked boxes and the browsers transmit the hidden fields and checked boxes in a jumbled mess unless there are IDs present in the field name (like user[email][ID][wants_spam], where wants_spam is a checkbox).

(TODO: add examples of params hash from browser with and without ID.)

But cracking this nut, making it simple and failproof will have the nice side effect of making the Javascript simpler. Both the RJS and unobtrusive Javascript code won't have to worry about setting IDs (as the RJS code does now).

The problem with AJAX calls to add new objects, the temporary ID for a new object should be unique within the set of those new objects. One solution would be to embed the last-used ID in the AJAX call somehow, either from the button or link that initiates the call, and have the view code that is generated include a new button or link that replaces the old one.

Another weakness of the current plugin is that it produces view code. The designer should be allowed to use the plugin to create whatever view code is wanted.