Bulk edit form items

Phoenix Forum Questions / Help
,
#1

I would like to bulk edit a list of items. Let’s call them Todos. There is no parent entity, no ‘List’. The todos themselves are regular Ecto schemas and have changesets.

Now I would like to render one form, with all todos in there, using the regular Phoenix HTML helpers. So that, upon submitting, all changesets can be checked and if any - or multiple - items contain errors, the form is presented to the user again, with the necessary error messages on the erroneous fields.

I can not seem to find a way to generate a ‘parent’ changeset to pass to the form to make this happen. After submit, I can loop the lists of items and validate each one individually. But I need one ‘main’ changeset to pass to the form.

Any ideas? I can do it all manually but that would be a pitty. Thanks!

#2

Are you… talking about this?

https://hexdocs.pm/ecto/Ecto.Repo.html#c:insert_all/3

Cause this is what I do with many to many relationship with multiple select input form.

Oh maybe I misread.

Repo.insert!(%Post{
  title: "Hello",
  body: "world",
  comments: [
    %Comment{body: "Excellent!"}
  ]
})

So for you example would be:

Repo.insert!(%List{
  title: "Hello",
  todos: [
    %Todo{body: "Excellent 1!"},
    %Todo{body: "Excellent 2!"},
    %Todo{body: "Excellent 3!"}
  ]
})

?

#3

He doesn’t have a parent record. He’s not managing an embedded association either. He wants to mass edit stand-alone records in the same form.

I remember a RailsCasts episode on doing the same thing in Rails. Maybe it can prove inspirational?

Just shooting off ideas, but you might have loop over the todo items and create a changeset for each, then manually use those changesets in the form. I suspect the form itself would not be backed by a changeset. You could simply post it using @conn.

Perhaps someone with more experience than me can chime in.

1 Like
#4

Like @abitdodgy is saying, this is indeed not what I mean :slight_smile:

Thanks for the tip @abitdodgy, I might try that.

1 Like
#5

I do this pretty often, I just display the form as a row in a table with the overall form wrapping the entire table and each row being indexed by some unique identifier (just adding [#{blah.id}] to the row) then just compare the changes to the original information on submission and build a list of changes to apply (I have a helper function on my repo module to do that).

2 Likes
#6

You should start open-sourcing things! What for you might be a small footnote of code during a busy day might be a lifesaver for many others. :024:

5 Likes
#7

A lot of them are very situationally specific, and the overall code is awfully tiny to wrap an entire library around… Like my comparison thing has knowledge about my removed_at timestamp fields (never delete or change anything, a new entry with the old entry with a removed_at date added is done instead, which is very much not helpful for most projects). ^.^;

#8

In the end, it turned out I had a parent anyways, so I was able to go with the usual nested changesets. Thanks for all your replies!

1 Like