button_to_remote aliases submit_to_remote
Reported by Clemens Kofler | July 9th, 2008 @ 07:55 AM | in 2.2
In a discussion on the rails-core mailing list (http://groups.google.com/group/r...) the majority of people thought that button_to_remote would make a good alias for the existing submit_to_remote. There's link_to/link_to_remote so button_to/button_to_remote would be more consistent than button_to/submit_to_remote.
I've attached the patch. I didn't feel it necessary to write a test since we're only aliasing a method and I checked back and form_remote_for isn't tested either.
Comments and changes to this ticket
-
Michael Koziarski July 9th, 2008 @ 10:15 AM
- → Assigned user changed from “” to “Michael Koziarski”
- → Tag changed from “actionpack actionview helper patch prototype” to “actionpack actionview enhancement helper patch prototype tiny”
-
DHH July 9th, 2008 @ 04:04 PM
- → State changed from “new” to “committed”
-
Pratik July 10th, 2008 @ 01:02 AM
- → State changed from “committed” to “resolved”
Resolved in http://github.com/rails/rails/co...
-
Tarmo Tänav October 6th, 2008 @ 02:19 PM
Hey everyone,
Looks like there was a conflict between this change and one added later : http://github.com/rails/rails/co... (ignore the fact that said commit does nothing because the commit introduced by this ticket, albeit earlier, overrides all methods added by it).
My question is, why should button_to_remote use submit_to_remote style API when it could easily use link_to_remote style and thus become (by default) usable without a containing form?
Is there any benefit to keeping submit_to_remote and button_to_remote as aliases instead of separating button_to_remote to be something like link_to_remote and submit_to_remote as a specialization of that button_to_remote which applies the :with => "Form.serialize(this.form)" and :name => name options?
-
Michael Koziarski October 6th, 2008 @ 03:46 PM
- → Milestone changed from “2.x” to “2.2”
- → State changed from “resolved” to “open”
Let's make sure we have a nice api before we cut the 2.2 release.
-
Clemens Kofler October 6th, 2008 @ 11:56 PM
Tarmo,
on the Pro side I see the benefits of the change you're suggesting because it makes plenty of sense. Personally, I wouldn't have implemented submit_to_remote as it is in the first place but I guess we're touching some really old Rails code base here.
On the other hand, the reason why I originally opened this ticket was because of the inconsistency. Back then, I was surprised to find that link_to had its counterpart link_to_remote whereas button_to didn't have one - at least not by name. Making button_to_remote behave totally different than button_to might lead to some amount of confusion. Moreover, without a containing form, the button wouldn't degrade gracefully with JS turned off. I'm not sure if the current solution degrades gracefully but that's certainly a downpoint.
In short: I have a hard time deciding which I find makes more sense - so I guess this is up to you guys!
-
Michael Koziarski October 9th, 2008 @ 05:12 PM
- → Assigned user changed from “Michael Koziarski” to “Pratik”
Moving this to pratik as I may be on holiday during the RC
-
DHH October 9th, 2008 @ 05:25 PM
- → Assigned user changed from “Pratik” to “Tarmo Tänav”
I'm +1 on making button_to_remote work like link_to_remote and keeping submit_to_remote as it always was.
-
-
Pratik October 16th, 2008 @ 11:01 AM
- → State changed from “open” to “resolved”
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
Creating or reviewing a patch
See the contributor guide.
Creating a feature request
Please don't. If you want a new feature in Rails, you'll have to pull up your sleeves and get busy yourself. Or convince someone else to do it. See the contributor guide on how to get going. But posting them here is just going to lead to ticket root.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
