Setting params for a connection-based form_for

I’m trying to create a simple CRUD app without ecto or changesets. Creating works fine, but I don’t see how to get the values into for form for the edit action: It is expecting them in params, which I can’t change from the controller.

I fell back to setting the value: parameter on the input fields on the form, but that seems kinda tacky.

Dave

1 Like

Another thing I noticed recently is that a conn powering form_for cannot supply any error values.

1 Like

You can always just create a changeset on the fly. Or you can make a module that fulfills the protocol implementation for form_for’s protocol that wraps whatever data you want. :slight_smile:

1 Like

Not without ecto.

1 Like

Which is why I keep saying the Changeset part of Ecto should become it’s own library, it is more generically useful than just in Ecto. ^.^

You can always depend on Ecto without using it though.

But otherwise, just implement the protocol to handle your own data structure. :slight_smile:

3 Likes

Yeah, I’m working on it.

This whole coupling is the reason I’ve been pushing hard to keep the database out of the web tier. Phoenix/ecto didn’t, and now picking them apart is difficult. And when the frameworks are coupled, it’s hard to keep the apps built with them uncoupled.

4 Likes

True true yeah. I use Ecto’s Changesets all over the place, not just with database stuff. I’ve been tempted to make a kind of ‘copy’ of it (with extras) into a standalone library for data piping and validation with pre-built protocols like for Phoenix.HTML.FormData and so forth that I’d use often. Ecto’s Changeset really should just be pulled into it’s own library that Ecto then depends on though. ^.^

4 Likes

Have you guys mentioned extracting it to José and @michalmuskala? I think we often get things get mentioned on the forum but (due to the sheer amount of posts we get) don’t get seen by everyone…

//Off topic// Any ETA on your new course Dave? I literally can’t wait!! :blush:

1 Like

I’ve seen them speak of it before but I have no clue as to their plans about it. ^.^;

2 Likes

That’s why I’m playing with this. I’m a little stalled until I find a way I’m comfortable recommending. I thought I had it, when when I ot down to creating detailed content, I discovered all the ugliness.

My current plan is to create a simple library to hide all this and allow decoupled apps. I’m slowly getting there.

4 Likes

Dave, how did it go with your own implementation of Phoenix.HTML.FormData? I think it is either that or we decouple changesets from Ecto, right?

3 Likes

:purple_heart:

Personally I would prefer less reliance on (potential duplication in) extra libraries if at all possible - so from my point of view splitting Ecto to decouple Changesets seems like a great option (if that achieves the goal as per the posts above).

I also think Elixir making easy or having pre-built ‘support’ (i.e Changesets lib as official/semi-official to the degree Ecto is now) for building your apps as a series of components will be highly beneficial in terms of how Elixir is perceived - particularly in regards to using it in conjunction with really smart coding principles/architectures, such as the Replaceable Component Architecture :003:

(JMO :blush:)

4 Likes

+1 for Changesets as a separated app!

But in my case, for another reason: there were a couple of times that I needed a type casting and validation lib just like ecto changesets, but didn’t want to add ecto to my deps just for this feature.

3 Likes

Why? Because you don’t want to review the entirety of Ecto’s source? Would you be willing to review the Changeset module?

I know that Ecto is a large library, but:

  • Compile times are pretty good
  • Disk space is very cheap these days (not cheap enough to run a full bitcoin node, for example, but certainly cheap enough to store Ecto inside your project)

Splitting Ecto into two packages brings an additional maintenance burden to the Ecto developers: two repositories, two issues trackers, two test suites, two sets of versions to manage and release, two libraries that should evolve in lockstep and which now have independent releases, two sets of guides, etc. It might have the good side effect of making the Changeset stand out on its own, but is it worth it?

I see people decrying npm’s micro packages as a horrible thing and wishing Javascript had a larger standard library so that there would be no need for such deep dependency trees. At the same time there is this push to split packages into the “least usable unit” until we get the likes of lodash (each of which exports a single function, with the package configuration taking up more space than the actual code - yes, JS has a different set of constraints, but still). In all fairness, these might be two distinct groups of people, of course.

What I see here is the following: Elixir has an excellent standard generic data management library called Ecto. This library contains functionality both to deal with data on its own and on to interface with external data stores. And now people are talking about splitting it into two packages, so that projects that depend on one part don’t have to depend on the other.

I’m not an Ecto developer, so this doesn’t affect me directly, but I don’t think the minimal advantages of splitting the packages are worth the maintenance burden just to say that you don’t “depend on Ecto”. Is this just about “bragging rights” about how minimal a program is? Is it a question of being easier to review a smaller number of modules (Changeset) vs a large number of modules (Ecto)?

With Elixir’s very principled approach to metaprogramming this doesn’t seem like a very compelling reason: the effects of a module is necessarily local unless it’s imported or used. We’re not dealing with Python’s level of monkey patching and thread locals.

I wonder if this decoupling thing isn’t being taken too far sometimes. My Elixir code depends on the Standard Library, of which I use only a couple modules per project. Should we split that? (hint: look at JS for the answer).

3 Likes

I don’t have such a strict opinion as @tmbb, but I would support his reasoning. Having only changeset support split out of ecto would probably mean no access to embedded schemas, which I use almost all of the time when not working with db schemas. Schemaless changesets are nice, but often the explicitness of the embedded schema is better. Also without setting up a repo module in the own code one is essentially skipping database access anyways.

Nontheless I’d like to see phoenix having some way to use a form without changesets, even if it’s not as pretty or consice. No need for validation, but just a way to set values/errors for fields.

1 Like

That’s already possible today by passing a connection. If anybody has ideas on how to integrate that better with errors and other features, it would be great, the starting point is there.

1 Like

Isn’t that just reinventing changesets?

Not really. One can already use the conn to power forms, I just noticed the lacking possibility to assign error messages to fields. Changesets are far more than just a containers for error messages.

2 Likes

I strongly believe that coupling the web front end to the database is bad. So I don’t want to encourage ecto to be a dependency of any phoenix app, because once there for changesets, it will always be a temptation for people to start adding queries, and …

Turn it around. You have a web front end. You want to take a map and display its contents in a form, allow the user to edit them, and the display any invalid fields on submission, along with useful errors.

This shouldn’t require a database mapping layer…

9 Likes

I’m working on it :slight_smile:

3 Likes