-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add data-params handling to handleMethod #307
base: master
Are you sure you want to change the base?
Conversation
👍 I've got similar behavior in an extension I've written (except mine handles params of type object as well by creating rails-style bracket names, eg one suggestion: you probably want to replace any |
this needs to be pulled ASAP!!!! |
This can't be pulled in as-is. There's no such thing as a Also, I don't get line 200. The |
using if @phillipp doesn't get around to updating his pull request in a couple days then I'll submit one that addresses these issues. |
Yes, use of attr() was a mistake while copying my path over to another repo. This is fixed by the last commit. As passing an object into the data-params makes the most sense for me, the method is looping over the object. |
Hey @phillipp, could you squash your two commits down into one and update this PR? We also need to get a test added to make sure this is working as intended. If you could do that, I can pull this in right away. otherwise, I'll have to write one when I get some time. |
…andler with e.g. method: "post" to add post fields from the a-tags data-params attribute to the form.
Hi @JangoSteve, thanks for picking this up again. I suqashed the two commits, but I just have a few hours left before some travel and I can't deal with the testing right now. Sorry. |
Thanks. I'll have to write a test when I get some time then. The one thing I'm concerned about, is that this only allows for <a href="/somewhere" data-remote=true data-method="post" data-params="my_value=hello">Click</a> This would append 14 hidden fields to be appended to the form like this: <input name="0" value="m" type="hidden" />
<input name="1" value="y" type="hidden" />
... And so on. Given that I'm wondering if we should check to see if it's a string first, and if so, append it to the form's action. |
To implement this, I had to write a custom javascript handler to handle switching locales. Previously, this was handled for us via Rails's unobtrusive javascript, but I could not find any way to add in additional url parameters to the PATCH request the unobtrusive javascript was generating for us. There's actually an open PR from 2013 to implement support for this here: rails/jquery-ujs#307. I also rewrote the set_locale_spec to enable javascript and be more like what I believe a feature spec should be. I actually don't understand how the spec was even passing before, I would expect it to fail because it was sending a GET request, and we don't have a handler for GET request to update the locale. Maybe rspec/capybara/poltergiest has baked in support for unobtrusive javascript so that the right thing will happen even if you don't have javascript enabled?? That sounds crazy, but it's the only thing I can think of. Regardless of how this was working before, I do believe that the new specs are better. This fixes thewca#2962.
To implement this, I had to write a custom javascript handler to handle switching locales. Previously, this was handled for us via Rails's unobtrusive javascript, but I could not find any way to add in additional url parameters to the PATCH request the unobtrusive javascript was generating for us. There's actually an open PR from 2013 to implement support for this here: rails/jquery-ujs#307. I also rewrote the set_locale_spec to enable javascript and be more like what I believe a feature spec should be. I actually don't understand how the spec was even passing before, I would expect it to fail because it was sending a GET request, and we don't have a handler for GET request to update the locale. Maybe rspec/capybara/poltergiest has baked in support for unobtrusive javascript so that the right thing will happen even if you don't have javascript enabled?? That sounds crazy, but it's the only thing I can think of. Regardless of how this was working before, I do believe that the new specs are better. This fixes thewca#2962.
To implement this, I had to write a custom javascript handler to handle switching locales. Previously, this was handled for us via Rails's unobtrusive javascript, but I could not find any way to add in additional url parameters to the PATCH request the unobtrusive javascript was generating for us. There's actually an open PR from 2013 to implement support for this here: rails/jquery-ujs#307. I also rewrote the set_locale_spec to enable javascript and be more like what I believe a feature spec should be. I actually don't understand how the spec was even passing before, I would expect it to fail because it was sending a GET request, and we don't have a handler for GET request to update the locale. Maybe rspec/capybara/poltergiest has baked in support for unobtrusive javascript so that the right thing will happen even if you don't have javascript enabled?? That sounds crazy, but it's the only thing I can think of. Regardless of how this was working before, I do believe that the new specs are better. This fixes thewca#2962.
To implement this, I had to write a custom javascript handler to handle switching locales. Previously, this was handled for us via Rails's unobtrusive javascript, but I could not find any way to add in additional url parameters to the PATCH request the unobtrusive javascript was generating for us. There's actually an open PR from 2013 to implement support for this here: rails/jquery-ujs#307. I also rewrote the set_locale_spec to enable javascript and be more like what I believe a feature spec should be. I actually don't understand how the spec was even passing before, I would expect it to fail because it was sending a GET request, and we don't have a handler for GET request to update the locale. Maybe rspec/capybara/poltergiest has baked in support for unobtrusive javascript so that the right thing will happen even if you don't have javascript enabled?? That sounds crazy, but it's the only thing I can think of. Regardless of how this was working before, I do believe that the new specs are better. This fixes thewca#2962.
To implement this, I had to write a custom javascript handler to handle switching locales. Previously, this was handled for us via Rails's unobtrusive javascript, but I could not find any way to add in additional url parameters to the PATCH request the unobtrusive javascript was generating for us. There's actually an open PR from 2013 to implement support for this here: rails/jquery-ujs#307. I also rewrote the set_locale_spec to enable javascript and be more like what I believe a feature spec should be. I actually don't understand how the spec was even passing before, I would expect it to fail because it was sending a GET request, and we don't have a handler for GET request to update the locale. Maybe rspec/capybara/poltergiest has baked in support for unobtrusive javascript so that the right thing will happen even if you don't have javascript enabled?? That sounds crazy, but it's the only thing I can think of. Regardless of how this was working before, I do believe that the new specs are better. This fixes #2962.
This commit adds the functionality to fetch the data-params attribute from the link and add fields to the form that express the values from the data-param attributes.
This is useful for POST-requests via links that should post parameters instead of sending them in the URL.