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
Another thing I noticed recently is that a conn powering form_for cannot supply any error values.
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. 
Not without ecto.
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. 
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.
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. ^.^
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!! 
I’ve seen them speak of it before but I have no clue as to their plans about it. ^.^;
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.
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?
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 
(JMO 
)
+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.
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:
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).
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.
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.
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.
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…
I’m working on it
© Copyright Elixir Forum | Terms | Privacy & Cookies
