| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
ActionView::Helpers::FormTagHelper were deprecated.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
|
| |
|
|
|
|
|
| |
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content
Closes #7215
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This applies to the following helpers:
`button_to`
`button_tag`
`image_submit_tag`
`link_to`
`submit_tag`
|
|
|
|
|
|
|
|
|
|
|
|
| |
The input types added are:
- input[type="month"]
- input[type="week"]
- input[type="datetime"]
- input[type="datetime-local"]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
option from `submit_tag`, `button_tag` and `button_to` helpers.""
Finally remove `:disable_with` but use `:data => { :disable_with => ... }`
in examples to show off a better API (which looks nicer in Ruby 1.9)
This reverts commit a5c38a9c087e33d36397afc496be7c8e01b37ef0.
|
|
|
|
|
|
|
|
|
|
| |
`submit_tag`, `button_tag` and `button_to` helpers."
`disable_with:` is much easier to type than `"data-disable-with" =>`,
and the fact it uses "data-disable-with" => is an implementation concern,
it should not affect the public API.
This reverts commit 683fc4db00f496e5225928afb4d4e932e0fcdc48.
|
|
|
|
| |
`submit_tag`, `button_tag` and `button_to` helpers.
|
|
|
|
|
|
| |
See issue #393, issue #4000, issue #5190, and issue #5191. Adds a newline after the textarea opening tag based on @codykrieger's original patch so that we don't cause regressions in Haml-using apps. The regression caused textarea tags to add newlines to the field unintentionally (each update/save added an extra newline.)
Also fix 6 more tests that didn't yet have the newline expectation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PATCH is the correct HTML verb to map to the #update action. The
semantics for PATCH allows for partial updates, whereas PUT requires a
complete replacement.
Changes:
* adds config.default_method_for_update you can set to :patch
* optionally use PATCH instead of PUT in resource routes and forms
* adds the #patch verb to routes to detect PATCH requests
* adds #patch? to Request
* changes documentation and comments to indicate support for PATCH
This change maintains complete backwards compatibility by keeping :put
as the default for config.default_method_for_update.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
fix destructive stringify_keys for label_tag
|
| | |
|
|/ |
|
|
|
|
| |
add four new tests to verify that the other three methods that called stringify_keys! are fixed. verified that the tests break in master without the code patch. Closes #2355
|
| |
|
| |
|
|
|
|
|
|
| |
After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.
It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
|
|
|
|
| |
suggestion!
|
|
|
|
| |
There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per the HTML 4.01 spec:
Buttons created with the BUTTON element function just like buttons
created with the INPUT element, but they offer richer rendering
possibilities: the BUTTON element may have content. For example, a
BUTTON element that contains an image functions like and may resemble
an INPUT element whose type is set to "image", but the BUTTON element
type allows content.
Since rich content is the main purpose of the <button> element, it makes
sense for the button_tag helper to accept a block.
http://www.w3.org/TR/html401/interact/forms.html#edef-BUTTON
http://dev.w3.org/html5/spec/the-button-element.html#the-button-element
Signed-off-by: Santiago Pastorino and Emilio Tagua <santiago+emilioe@wyeworks.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
"submit" is the default value of the <button> element's type attribute
according to the HTML 4.01 and the HTML5 draft specs, so if button_tag
is going to have a default, type="submit" is a more sensible choice than
type="button".
http://www.w3.org/TR/html401/interact/forms.html#adef-type-BUTTON
http://dev.w3.org/html5/spec/the-button-element.html#attr-button-type
Signed-off-by: Santiago Pastorino and Emilio Tagua <santiago+emilioe@wyeworks.com>
|
| |
|
|
|
|
|
|
|
|
| |
This tag is similar in nature to submit_tag, but allows more control.
It also doesn't submit if submit type isn't used, allowing JavaScript to
control the flow where required.
For more information: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-button-element
|
|
|
|
|
|
| |
state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
| |
This reverts commit e4283007d607454acf97301821ba1e1c417bdead.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Specify accept-charset on all forms. All recent browsers,
as well as IE5+, will use the encoding specified for form
parameters
* Unfortunately, IE5+ will not look at accept-charset unless
at least one character in the form's values is not in the
page's charset. Since the user can override the default
charset (which Rails sets to UTF-8), we provide a hidden
input containing a unicode character, forcing IE to look
at the accept-charset.
* Now that the vast majority of web input is UTF-8, we set
the inbound parameters to UTF-8. This will eliminate many
cases of incompatible encodings between ASCII-8BIT and
UTF-8.
* You can safely ignore params[:_snowman_]
TODO:
* Validate inbound text to confirm it is UTF-8
* Combine the whole_form implementations in form_helper_test
and form_tag_helper_test
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|