dm-accepts_nested_attributes
Martin Gamsjaeger
I just pushed http://github.com/snusnu/dm-accepts_nested_attributes/tree/master
It's not complete yet, but it's already reasonably specced (still lots
of specs to add of course!)
and also quite functional.
Current status:
* belongs_to: create/destroy/update(FAIL)
* has(1): create/update/destroy
* has(n): create/update(FAIL)/destroy
* has(n, :through): create(FAIL)/update(FAIL)/destroy(FAIL)
Also, since I need this rather soon for my current (merb) project, I
wrote it for 0.9.11
I definitely want it to be available for next branch (of course) but I
cannot spend
any time on it now, since from what I heard, next branch is not
production ready yet.
Anyways, I think it'd be really cool to have this in dm! (a plugin is
perfeclty fine, needn't be core)
The API is almost the same (one minor change for now - have a look at
the README)
like the one activerecord has, which should mean, that once rails3 comes out,
multimodel forms are totally possible with datamapper as ORM.
As for merb, I don't really know if merb has support for nested model
assignment in
its form_for and fields_for helpers. I have to say though, that I
don't really care, since
I don't use these helpers, but write the html that my designer
colleague wants to see.
Any help, ideas, discussions on irc/email, forks, patches, whatever
... are really appreciated!
cheers
snusnu
Martin Gamsjaeger
It's actually the same than my last post to this group, but maybe
(just maybe) someone reads it, and comments over there, but not
here ...
cheers
snusnu
On Apr 8, 8:18 pm, Martin Gamsjaeger <gamsnj...@gmail.com> wrote:
> Hey everyone,
>
> I just pushedhttp://github.com/snusnu/dm-accepts_nested_attributes/tree/master
michael
Saw that guy drenched in sweat and struggling next to me for the last
three days ;)
Thanks you for that one! :)
Can't wait to build my next nested form :D
Michael
On Apr 8, 8:45 pm, Martin Gamsjaeger <gamsnj...@gmail.com> wrote:
> I also wrote a blogpost athttp://sick.snusnu.info/2009/04/08/dm-accepts_nested_attributes/
Martin Gamsjaeger
Rupert Voelcker
> ... are really appreciated!
This time to the mailing list (and to the right mailing list!)
OKay ....played some more - not sure if this is in nested attributes
territory or not but here's my setup:
class Team
has n, :team_memberships, :class_name => "TeamMember"
has n, :team_members, :through => :team_memberships,
:class_name => "User",
:child_key => [:team_id],
:remote_name => :user,
accepts_nested_attributes_for :team_memberships
end
class TeamMember
belongs_to :team
belongs_to :user
end
class User
has n, :team_memberships, :class_name => "TeamMember"
end
Then on a form for creating a team I have dropdowns for selecting the
team member names which result in the following attributes being sent
back to the Team model:
Team.new({"name"=>"adds",
"team_memberships_attributes"=>[{"user_id"=>"5"}, {"user_id"=>"42"}],
"short_name"=>""}
)
Now if the validation fails on the team model (cause the short_name
has been left blank) then I can't see how to recover the selections
made for the team memberships so that when the form is re-displayed
with errors it looks like it did when it was submitted.
Any thoughts???
Cheers
Rupert
Martin Gamsjaeger
maybe is the best option to "remember" the nested attributes that
couldn't be saved in some ivar on the resource. This way, a failing
create action that renders the :new form, should have the already
POSTed information available, and thus be able to rebuild the form to
the same state that it was in before it got POSTed to the server.
Rupert is kind enough to work on this in his fork, thx again Rupert!
Rupert Voelcker
and tis done - and I presume it'll be in Martins repo too once he's
had a chance to look it over.
Rupert
Martin Gamsjaeger
Rupert, thx a lot for the patches! I integrated them into my master
branch, right after adding (experimental) support for dm-validations.
Check it out at
http://github.com/snusnu/dm-accepts_nested_attributes/commits/master
There is definitely still a lot to be done to make support for
dm-validations solid. Things that come to my mind are basically specs
and wrapping everything inside a transaction. The only currently
specced (auto)validations are not-null constraints - without
dm-constraints in action. A small and probably incomplete list of
things to do would be:
* specs for custom validations
* specs for adding associated resource errors to the saving resource
* the code is in place but completely unspecced, didn't even check in irb
* specs for atomic commits (transactions)
* i was playing with wrapping every save inside a transaction =>
http://pastie.org/446060
* i can see that this would produce nested transactions ... is this
a problem?
I was talking to Michael Klishin and Dan Kubb on irc, and we seem to
agree that (at least parts of) the specs for the integration of
dm-accepts_nested_attributes with dm-validations should probably live
in the dm-validations specsuite. The main reason for this is that it
seems wrong to spec every possible (or worse, only some) usage of a
validation in combination with nested model assignment, inside the
dm-accepts_nested_attributes specsuite. It should be possible to write
specs that prove once and for all, that the way
dm-accepts_nested_attributes alters the Resource#save behavior plays
well with the way dm-validations alters this behavior. Since saving
nested models with validation is basically a matter of validating and
saving all associated resources *in the right order* (belongs_to
first, then has) within one atomic commit (transaction), it seems
logical to place these specs inside dm-validations specsuite.
That being said, it's obvious that there is still some work to do. I
will work on things as I need them for my main project, but me and
Rupert would still appreciate any additional feedback or help in any
possible way :-)
cheers
snusnu