Formex - a form library for Phoenix inspired by Symfony

Does it require a schema or how does it work? It initially looked like it could work off of a map to pull the information, but it looks like you look up associations, but is that hard-coded? Reason I ask is I almost never send a schema directly, I always have them massaged to only send the necessary data (which might be coming from a dozen tables/schemas), so how would this fit in that style? Also what all does it gain from making more form helpers via phoenix forms?

Looks nice overall though.

EDIT: I am a bit iffy on the fact it hides the association database calls from the caller though, it looks like those happen in the view, which is very bad for reasoning about data flow, plus it prevents the user from being able to optimize those lookups via a join query or so.

Does it require a schema

Yes, for now it only works with Ecto schemas. I have plans to make a possibility for create forms without Ecto, which is also possible in Symfony.

It hides the association database calls .. it prevents the user from being able to optimize those lookups via a join query

Another thing to my todo list
BTW. If you talking about my SelectAssoc - you can always use a standard :select.

Also what all does it gain from making more form helpers via phoenix forms?

The main reason why I started developing that lib was the <select>'s. I had to create own queries to get data for <option>'s from database, then pass it to the view, from this view to another view… there was a lot of code which I didn’t had to write in a Symfony.

Another thing is readability - why to write whole form in the view?

And there is one additional validation in Formex for selects - it checks if value of select sent by user exists in a generated form.

Well you don’t. ^.^

I have quite a sizable selection of helpers for my views that I’ve built over time, one of which is just a simple generator based on a schema that I pass in, but most of my templates are just things like:

<div class="card">
  <%= alert_error assigns %>
  <%= Auth.Request.form @conn, @callback_url, @provider %>
</div>

Where alert_error is just a normal function with an eex template embedded in it that basically just generates:

def alert_error(assigns, tag \\ :error) do
  case assigns[tag] do
    nil -> nil
    errors ->
      ~e"""
      <div class="alert">
        <input type="checkbox" id="error-message">
        <label for="error-message">Dismiss</label>
        <div><%= format_errors errors %></div>
      </div>
      """
  end
end

And the form just calls the Auth.Request.form function that takes the stuff it is interested in and returns a usual Phoenix.HTML form_for setup. My only really long template is my layout.

Ok, I also used to use helpers like this.

Another benefit from using Formex is that, you have a one place where you define a form structure. You don’t create separately changeset and the view, it’s generated by data from the same source.

What would this ‘same source’ be? Because in my ‘Auth.Request’ case it is pulling from 6 different tables across two different databases (one PostgreSQL, one Oracle) and an LDAP server. Almost none of my forms anywhere pull from just a single table, and that is a rare thing on any website I’ve built in decades. I’d love to find a library to help simplify all this.

EDIT: Oh how much I wish elixir had sum and prod types and that Ecto used them to be able to build up a schema tree… ^.^

Sadly Ecto is built very much with a singular world view, cannot cross schema (in the postgresql sense) join, cannot mix database types in a singular way (Ecto.Multi would be awesome there if so), etc… ^.^

Also wish there were a way to pick values out of Ecto.Multi to inject into queries later in the path without needing to hide it all within Ecto.Multi.run commands, those are about impossible to introspect for testing…

I meant a Type file where you declare your form.

In “vanilla” Phoenix to create a form you have to:

1. create changeset, where you have to put all fields that will be used in form
2. create template and again list all of fields

When you want to add or remove a field, you need to do it in two places. Doesn’t it breaks the DRY rule?

In Formex you have just one file with the form. Changeset and template (if you used formex_rows) will be automatically generated based on this one file.

Even if you will not use the formex_rows but just formex_row you still have situations when you don’t have to open template file, but you would have to do that in standard Phoenix. For example, when you want to set that some field is required you have to set it in the changeset and then put an asterisk inside the template. In formex you just set the required: true option.

Not as of yet? My forms are only defined where they are, just as functions that take arguments, and I pass in the arguments to them to generate the form template. Remember that I rarely use changesets on my front-end, I pull from way too many sources, many of which are not even via Ecto, so no, no changesets.

For required fields I just add required to the html, I let html5 deal with making it required though I still confirm on the server as well (inside Ecto.Multi, I use a lot of Ecto.Multi).

I should make an image animation, hmm, here we go, for the above code and the simple controller that accesses complex domain code, I have this, there is no javascript (not even for the dismissing) and this computer is heavily lagged (Windows 10 does not handle being out of memory very well, the very Windows interface is laggy):

There is no changeset to pull the username/password from, no data, etc… How would this be done (and elsewhere I have very complex forms as well)?

So this package isn’t for you. Someday I will add possibility of using it without changesets.

I have added the ability to create a collection of forms. Here is an example of use:

formex_collection.png1250×2648 369 KB

Docs

I believe that a form tool for Phoenix would be best if it did not assume the availability of a library like Ecto, because requiring Ecto creates a coupling between the view and the storage layer, which would then make a couple of decoupling refactors much more difficult in the future.