| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\ |
|
| |
| |
| |
| | |
delegates to the config object, reducing the number of deprecations and add specific tests.
|
|/
|
|
|
|
|
| |
And add tests for `button_to` and `form_tag` which currently behave as
expected, so we avoid a regression.
Signed-off-by: wycats <wycats@gmail.com>
|
|
|
|
| |
url, number, etc) (Closes #3646) [Stephen Celis]
|
|
|
|
| |
proxying back to the controller. This potentially allows for more standalone usage of AV. It also kicked up a lot of dust in the tests, which were mocking out controllers to get this behavior. By moving it to the view, it made a lot of the tests more standalone (a win)
|
|
|
|
| |
to select tag. Be sure to join the tag yourself and mark them .html_safe
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Yehuda Katz <yehudakatz@YK.local>
|
|
|
|
|
|
| |
consistency [#1792 status:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, all Strings are always not html_safe?. Instead, you can get a SafeBuffer from a String by calling #html_safe, which will SafeBuffer.new(self).
* Additionally, instead of doing concat("</form>".html_safe), you can do
safe_concat("</form>"), which will skip both the flag set, and the flag
check.
* For the first pass, I converted virtually all #html_safe!s to #html_safe,
and the tests pass. A further optimization would be to try to use
#safe_concat as much as possible, reducing the performance impact if
we know up front that a String is safe.
|
| |
|
| |
|
|
|
|
|
|
| |
such as :confirm in a unobtrusive manor
Signed-off-by: Joshua Peek <josh@joshpeek.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3aa1ea1ae4baa4a03d03644e798eeb98a4745785, reversing
changes made to 2c12a71378d2146c822acb389b00b866f6420ff5.
Conflicts:
actionpack/lib/action_view/helpers/javascript_helper.rb
actionpack/lib/action_view/helpers/url_helper.rb
actionpack/test/template/url_helper_test.rb
|
|
|
|
| |
image_submit_tag output data attributes for things like :confirm, :method, :popup, and :disable_with
|
|
|
|
|
|
|
| |
By using config rather than hardcoded constants, we can evolve the
configuration system over time (we'd just need to update the config
method with more robust capabilities and all consumers would get
the capabilities with no code changes)
|
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
|
|
|
|
| |
original patch
|
|
|
|
|
| |
Signed-off-by: Michael Koziarski <michael@koziarski.com>
[#2015 state:committed]
|
|
|
|
|
|
| |
text_area_tag('item[description]') should return: <textarea id="item_description" name="item[description]"></textarea> instead of: <textarea id="item[description]" name="item[description]"></textarea> The old id was causing HTML validation failures.
Signed-off-by: Michael Koziarski <michael@koziarski.com>
|