Mathieu Decaffmeyer

For distinguishing types see * https://github.com/mathieuprog/polymorphic_embed/blob/v1.10.0/lib/polymorphic_embed.ex#L344 * https://github.com/mathieuprog/polymorphic_embed/blob/v1.10.0/lib/html/form.ex#L9 `{:array, PolymorphicEmbed}` works with polymorphic_embed_inputs_for. Maybe requires to tweak input names when working with lists, and lib might need improvements, not sure....

I think what would be interesting is to see the rendering phoenix template and generated html). It's probably the names of the inputs that are wrong.

I think the key was to change the `cast` function to accept a struct instead of map of attributes? Could you explain why `cast` receives a struct?

Why did you decide to change the `cast` function if it's kinda unused? Just curious

There will be complaints. What if we check if we are in the test environment and that `ex_machina` is a dependency?

You mean stop using `cast_polymorphic_embed` in favor of `cast`? That won't work. The library at first worked through `cast`. Only recently `cast_polymorphic_embed` has been introduced. To receive the changeset. https://github.com/mathieuprog/polymorphic_embed/issues/10

That's awesome 😐 of course this is the way to go... We need to update the readme as well in order to document the ex_machina strategy and how to use...

The reason why we added `cast_polymorphic_embed` is to get the changeset to retrieve the existing data. That's why you could see in the code the merge of the data with...

You decided to return the `:error` atom instead of raising eventually? What are your reasons?

Raising an error allows to send a message to the developer, e.g. use cast_polymorphic_embed for field X instead