AHAH does not send the clicked button
dmitrig01 - November 18, 2007 - 18:53
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | javascript |
| Category: | bug report |
| Priority: | critical |
| Assigned: | dmitrig01 |
| Status: | closed |
Description
When AHAH is attached to a button, but 'selector' is set, sometimes you need the button.
Normally, it'd be in $form_state['clicked_button'], but that's not possible to find without an op.
This patch fixes that by adding an "op" option if it's added to the element.
Used by http://drupal.org/node/193191, you can get some pretty cool stuff going.
It also upgrades the version of jquery.form.js to 2.0.1
| Attachment | Size |
|---|---|
| form_ahah_op.patch | 14.71 KB |
#1
I haven't had time to test this exhaustively, but it's worth noting that it does NOT in fact set the op directly (which would be bad). It respects the specific button's #name property, which FAPI uses to match the clicked button even if $item['#name'] = 'op' has been changed manually, or if the button in question is an image button.
#2
This is definitely a welcome improvement. It does two things: 1) it sends the button name and value, that's very important considering $_POST['op'] has been killed. 2) It also sets up a best practice for attaching your #ahah behaviors. Because the ahah request is supposed to mimic the behavior when a button is clicked without ahah, it makes the handling code on the server-side easier (or possible at all).
So a big thumbs up to this improvement. Two minor semantic changes though.
I shorted the if statement in ahah.js to this:
this.button = element_settings.button || { };And the code to add a button to the settings to this:
'button' => $element['#type'] == 'submit' ? array($element['#name'] => $element['#value']) : FALSE,Basically just shortening up some things where a quicker approach was available.
I tested the patch with upload.module to make sure the new version of jquery.form.js didn't break anything and it looked solid. Further, I unapplied the drag and drop blocks patch to test the AHAH version of the blocks page with it and it worked well also. I think we can trust that at the very least, this patch does no harm.
I applied http://drupal.org/node/193191 and http://drupal.org/node/191360 (parent menu choosers or drill-down) to test out the functionality in action and it works great. This is RTBC in my opinion.
#3
I am OK with this -- and I need it, even.
#4
Thanks, committed.
#5
Automatically closed -- issue fixed for two weeks with no activity.