Why? What? Who? How?

Why?

Creating forms to capture/edit content is the "bread and butter" of Web Applications.

Forms are also often the most time-consuming aspect of building Web Apps, this is mostly because the "designers" want non-standard UI/UX (i.e. they are trying to make the form look "unique" or "on brand") rather than focussing on what the user is trying to achieve by using that form (or your App).

Beautiful Forms that render Fast and "work" for all users/devices don't have to be difficult to build. With this project we are going to ensure that simply spending the time up-front to define the Schema using https://github.com/dwyl/fields will mean that capturing the data for the content types is automatic.

Note: django, rails, symphony, lift, sails, play all do this "out of the box" so we are not doing anything "revolutionary" ... we are simply applying the idea to a Phoenix app. Yes, we are aware that Phoenix has a "generator" command to create forms: https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Html.html What we want is a way of automating this even further such that the Developer (and eventually the Product Owner) can simply define the Content Type with the relevant Fields and the form is automatically rendered when the visit: example.com/content-type/new (to create a new item of that content) or example.com/123 (to edit that item of content)

What?

• Nothing for the Developer to Maintain, simply add af to your mix.exs file.
  • We need to decide if the form will be rendered by af by "hooking" into the Phoenix request lifecycle OR if af will generate the HTML template (and safe it to a file) which the Developer is then responsible for "wiring" up to a Controller/View. My preference is for simplifying the whole thing.
• Forms are automatically rendered based on the Ecto Schema (which in turn is defined using Fields https://github.com/dwyl/fields for higher precision/semantics ...)
• Form submission is handled and the contents of each field is checked against the Schema.

Note: for now we are building this to be "single purpose". i.e. just to render forms in CS app. We can work on making it truly "generic" (i.e custom/variable UI) later. For now we want to use the most "basic" or "default" UI/UX to keep the forms simple.

Who?

People using Phoenix to build Web Apps who want to be considerably more time-effective.

How?

@DanWhy has already made some excellent/promising progress towards implementing this in https://github.com/dwyl/adoro/issues/108 that work simply needs to be transferred to here and we need to "flesh it out".

Implementation Detail:

• Introspect the Ecto Schema to determine what the ideal HTML input is for that field.
• Render the Content type as a standards/WCAG-compliant HTML form
  • Investigate if we can auto-generate a route for each content type such that defining a venue schema will automatically give us:
    • List: example.com/venues
    • New: example.com/venues/new
    • View: example.com/venues/1
    • Edit: example.com/venues/1/edit
• Forms should be submitted via POST request to the relevant endpoint
• Form data should be validated based on the Schema
• Where Validation Error Occurs, Form should be re-rendered with Errors in-line and input focus.
• If form is valid, save the content and re-direct to the content view.

@Danwhy is this "enough" detail to get started? If anything is unclear or your need more, please leave comments. thanks! ✨