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! ✨