In addition to updating the code examples and editing text for clarity and flow, here some more details on some of the changes:
- [X] Do we still need an HTML5 warning at the end of the 1st section? It's pretty standard these days.
--> agree, removed.
- [X] Not sure the output of `_form_with model: @article`_ is 100% correct, might need to double check that.
--> yes. updated this example and got the HTML output from my "guides playground" rails app.
- [X] When we mention `record.persisted?` in record identification, could be a good plug to link to the Active Model guide on that.
--> Hm...there is no direction mention, other than this https://guides.rubyonrails.org/active_model_basics.html#conversion
- [X] Similar to STI, link to the guide / reference on it.
- [X] Time Zone and Country Select should likely be broken into separate sub-sections (I don't mind still mentioning country select)
- [X] Would the file upload example would be better with a CSV for local processing, rather than showing saving to local disk? (which is probably a very uncommon usage?)
- [X] The _labeled_form_with_ example could likely be simplified with `_**options_` being all that it takes, instead of explicitly showing all possible kwargs.
- [X] It may be better to show "complex forms" (section 10) right after the parameters (section 8), moving "forms to external resources" down... just because complex forms require exactly the fields_for incantation that was detailed further under the parameters section, so it seems a better continuation. (or potentially even reversed? complex forms then params? not sure)
- [X] Under "complex forms", adding fields on the flow could be slightly expanded, it feels very "go figure".
--> Yeah, not sure what to do about this one. Was thinking about removing it as there is not built-in support to showcase.
---------
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Amanda Perino <58528404+AmandaPerino@users.noreply.github.com>
Co-authored-by: Karl Lingiah <karl@superchilled.co.uk>
- Action Controller Overview: Add example of how a cpk record can be
found using a show action.
- Action View Form Helpers: Add example of what a form updating a cpk
record looks like.
- Action View Helpers: Add examples for url_for and link_to cpk record
urls.
Make the example complete so people can follow along insted of having
to understand the implicit context that you need an existing helper
called `text_field_with_label` to make the example work.
Fixes#49027.
This is a follow up to rails#47186, this time for all markdown content.
[markdownlint](https://github.com/markdownlint/markdownlint) is an excellent tool, and I've found it very useful for finding issues in the guides.
Many of the rules are common style issues I'm correcting on PRs, so it will be nice to have that automated.
We should also be able to use the same config with our editors, so that errors show up in real-time 🙏 and will update the contributing docs once this gets merged with how to debug and use mdl appropriately.
The edits in section 1.2.1 of this guide are being proposed as the value argument passed to `check_box` is not in the second position, it is the third argument as shown [here](https://api.rubyonrails.org/v7.0.3/classes/ActionView/Helpers/FormBuilder.html#method-i-check_box) and in turn the language around the argument list for `radio_button` in section 1.2.2 needed to be altered as well.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Prior to this commit, there were two sections in the Form Helpers guide
with the same heading "The `fields_for` Helper".
This commit differentiates those two headings, and makes some minor
improvements to both sections for clarity.
This:
```ruby
resource :geocoder
```
and this:
```ruby
resource :geocoder
resolve('Geocoder') { [:geocoder] }
```
create exactly the same routes. Thus, it's better to show the simpler example rather than imply that both method calls are needed.
`resolve` is used for [polymorphic routes](https://guides.rubyonrails.org/routing.html#using-resolve) but isn't necessary in this example.
`form_with` would generate a remote form by default.
This confused users because they were forced to handle remote requests.
All new 6.1 applications will generate non-remote forms by default.
When upgrading a 6.0 application you can enable remote forms by default by
setting `config.action_view.form_with_generates_remote_forms` to `true`.
This shifts the primary focus from the bare `select_*` helpers to the
equivalent `FormBuilder#*_select` helpers. It also links all covered
helpers to their API documentation.
The previous statement was not strictly true all of the time.
For example, an input named `person[phone_number[]]` does
not get automatically accumulated. Updated this to a statement
that is always true (even if it may not fully describe all possible
cases, such as perhaps nested forms).
Follow-up to #39344.
This adds back coverage of `collection_select`, adds new coverage of
`collection_radio_buttons`, revises existing coverage of
`collection_check_boxes`, and unifies these sections.
The Form Helpers guide should encourage users to use `form_with` and
associated builder methods. The lower-level `*_tag` methods are covered
by the API docs.
These changes also fix some discrepancies between code examples and
their descriptions.
I caught two references that seemed inconsistent:
1. In section 2.2 Binding a Form to an Object, the code snippet variable was called `form`, but in the bullet points below, it was referenced as `f`.
2. In section 6 Uploading Files, the references to the params hash returned by two different forms was incorrect.
Motivation:
- I frequently look for this in the docs then struggle to rememeber
the name of the function I need to find in the api docs. Also I think
other people may benefit from it being easier to find.
Changes:
- Added a section about Collection Checkboxes to the docs.
Co-Authored-By: Eileen M. Uchitelle <eileencodes@users.noreply.github.com>
Convert examples to use `form_with` instead of `form_for` or `form_tag`,
which have been soft-deprecated. Also rename form variable in examples
from `f` to `form`, as exemplified by 8ff7ca5d11.
The description claimed that `.new_record?` was used in `form_for` to derive the action and button text.
But in the code `.persisted?` is used for that purpose.
[ci skip]