| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Bugfix config.action_view.default_form_builder option
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[This article](http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#maintenance-consequences-and-rails-5-0) states that:
> Rails 5.0 is in most likelihood going to target Ruby 2.2.
Before the exact minimum version is fully decided, @arthurnn [suggests](https://github.com/rails/rails/pull/17830#issuecomment-64940383)
that **at least** version 2.1.0 **must** be required by the `gemspec` files.
|
|/
|
|
|
|
|
| |
We will support only Ruby >= 2.1.
But right now we don't accept pull requests with syntax changes to drop
support to Ruby 1.9.
|
|
|
|
| |
Originally caused by #17771
|
|\
| |
| | |
Local vars should exist in partials for falsy `:object:` values too
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
c67005f221f102fe2caca231027d9b11cf630484 made the local var in partials
available only if what passed to `:object` was truthy.
For example this would not make the local variable `foo` available inside the
partial:
render partial: 'foo', object: false
Fixes #17373.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit moves a test from `test/template` to `test/activerecord` since the
test depends on ActiveRecord.
This matches the documentation from [RUNNING_UNIT_TESTS](https://github.com/rails/rails/blob/f28d1ddd507174ac233b773cc4f35c3c05ad32e7/actionview/RUNNING_UNIT_TESTS.rdoc):
> Test cases in the test/activerecord/ directory depend on having activerecord and sqlite3 installed.
> If Active Record is not in actionview/../activerecord directory, or the sqlite3 rubygem is not installed, these tests are skipped.
> Other tests are runnable from a fresh copy of actionview without any configuration.
---
More details about this commit.
All the tests starting with `require 'active_record_unit'` are already
inside `test/activerecord`, except for the one test this commit moves.
If you don't have `active_record` on your machine, the following command
currently fails on master:
```bash
```
|
|\
| |
| | |
Fix select_tag generating tag when set to false.
|
| |
| |
| |
| | |
Fixes https://github.com/rails/rails/issues/17701.
|
|/
|
|
|
|
|
|
| |
I grepped the source code for code snippets wrapped in backticks in the comments
and replaced the backticks with plus signs so they are correctly displayed in
the Rails documentation.
[ci skip]
|
|\
| |
| |
| |
| |
| |
| | |
Document *all* the options accepted by form_for
Conflicts:
actionview/lib/action_view/helpers/form_helper.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The [current documentation of form_for](http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_for) is incomplete:
> The rightmost argument to form_for is an optional hash of options -
> :url - The URL the form is to be submitted to. This may be represented in the same way as values passed to url_for or link_to. So for example you may use a named route directly. When the model is represented by a string or symbol, as in the example above, if the :url option is not specified, by default the form will be sent back to the current url (We will describe below an alternative resource-oriented usage of form_for in which the URL does not need to be specified explicitly).
> :namespace - A namespace for your form to ensure uniqueness of id attributes on form elements. The namespace attribute will be prefixed with underscore on the generated HTML id.
> :html - Optional HTML attributes for the form tag.
This commit completes the documentation by specifying that:
* `:authenticity_token` is also a valid option (as [documented here](https://github.com/rails/rails/blob/b0f44c9ff0be84ebc42760029adeeb9dd954655f/actionview/lib/action_view/helpers/form_helper.rb#L396))
* `:method` is also a valid option (as [tested here](https://github.com/rails/rails/blob/b0f44c9ff0be84ebc42760029adeeb9dd954655f/actionview/test/template/form_helper_test.rb#L1819))
* `:remote` is also a valid option (as [tested here](https://github.com/rails/rails/blob/b0f44c9ff0be84ebc42760029adeeb9dd954655f/actionview/test/template/form_helper_test.rb#L1850))
[ci skip]
|
|/
|
|
|
|
|
|
|
| |
Since 06388b0 `form_tag` accepts the option `enforce_utf8` which, when set to
false, prevents the hidden "UTF8 enforcer" field from appearing in the output.
This commit implements the same behavior for `form_for`.
Stems from https://github.com/rails/rails/pull/17685#issuecomment-63871395
|
|
|
|
| |
Now ActionView accepts <%= foo(){ %> and <%= foo()do %> :golf:
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit f93df52845766216f0fe36a4586f8abad505cac4, reversing
changes made to a455e3f4e9dbfb9630d47878e1239bc424fb7d13.
Conflicts:
actionpack/lib/action_controller/test_case.rb
actionview/lib/action_view/test_case.rb
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* use public_send instead of send to avoid calling private
methods in form helpers
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch uniformizes warning messages. I used the most common style
already present in the code base:
* Capitalize the first word.
* End the message with a full stop.
* "Rails 5" instead of "Rails 5.0".
* Backticks for method names and inline code.
Also, converted a few long strings into the new heredoc convention.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.
Heredocs have better readability, and with `squish` we can still
produce a single line.
This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.
|
|
|
|
|
| |
The character "*" is unnecessary in option candidates.
This incorrect markup was injected in e8c9aeca .
|
| |
|
| |
|
| |
|
|\
| |
| | |
Use include_blank value as option label
|
| |
| |
| |
| | |
Update select_tag to reflect documentation and behave the same as form builder select. If the value of include_blank is not boolean true, use that value as the option label.
|
| |
| |
| |
| |
| |
| |
| |
| | |
- Clarify that arguments are expected in array format.
- Extension of https://github.com/rails/rails/pull/17390.
- https://github.com/rails/rails/pull/17390 was targeted against
4-1-stable branch. This commit updates master.
- [ci skip]
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit fixes the behavior of `file_field_tag` and `password_field_tag`
when invoked with a hash of options.
These two helpers are different from all the other ones in that they modify the
options hash passed as a parameter, whereas all the other helpers duplicate it
before updating it.
The result is that *bad things* can happen if the user re-uses the same hash.
For instance, users who write the following code to display a file field
followed by a text field (both with the same class):
```rhtml
<% options = {class: 'important'} %>
<%= file_field_tag 'Upload', options %>
<%= text_field_tag 'Name', options %>
```
would instead see **two file fields!**
```html
<input class="important" id="Upload" name="Upload" type="file">
<input class="important" id="Name" name="Name" type="file" value="value">
```
This PR replaces `update` with `merge` in the code of the two helpers,
fixing the issue above.
The included test verifies the change, since it passes after this PR, but
fails before with the following error:
```
Expected: <input type="text" name="title" id="title" value="Hello!" class="important" />
Actual: <input type="password" name="title" id="title" value="Hello!" class="important" />
```
|
|\ \
| | |
| | | |
Remove duplicate stringify_keys in text_field_tag and number_field_tag
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
All the methods that invoke `text_field_tag` (such as `hidden_field_tag`)
and all the methods that invoke `number_field_tag` (that is `range_field_tag`)
do not need to call `stringify_keys` on their `options` parameter since the
`text_field_tag` method [is already doing it internally](https://github.com/claudiob/rails/blob/4159134524f4c78d008eef9d9a17f73a3172dcc8/actionview/lib/action_view/helpers/form_tag_helper.rb#L182):
```ruby
def text_field_tag(name, value = nil, options = {})
tag :input, { "type" => "text", "name" => name, "id" => sanitize_to_id(name), "value" => value }.update(options.stringify_keys)
end
```
and `number_field_tag` is [already doing it internally](https://github.com/claudiob/rails/blob/e3207bdbba55f3806441f22b175557579bc0b051/actionview/lib/action_view/helpers/form_tag_helper.rb#L780) as well:
```ruby
def number_field_tag(name, value = nil, options = {})
options = options.stringify_keys
...
end
[Note #1: My code uses `merge` to respect the existing behavior of
duplicating the `options` hash before updating its keys, see https://github.com/rails/rails/pull/17096#issuecomment-57223827]
[Note #2: My code uses symbols instead of strings (e.g.: `:hidden`) to look
forward to future version of Ruby/Raiks (GC symbols); the result of the method,
however, is the same, because the symbols are stringified inside `text_field_tag`]
[Note #3: I had previously created a similar PR #17096 but decided to
split it into multiple PRs given the feedback received in the comments]
|
|/ / |
|
| |
| |
| |
| |
| |
| | |
HTML doesn't care what order the elements are rendered in, so why should we?
Updates tests to use proper `assert_dom_equal` instead of `assert_equal` /cc @jeremy
|
|\ \
| | |
| | | |
Change `gsub` to `tr` where possible
|
| | | |
|
|/ / |
|