Impossible to trigger form submit with a link

cool, thanks! I improved the comments and re-rolled the patch.

For an example use case check out the UI of http://drupal.org/node/660108 - I use it already there.

The link is used to trigger form submission instead of a button - pretty easy with the #trigger_as functionality now. The button triggers a form rebuild, but without this patch the browser won't submit the form values, thus the form looses its values.

In my use case the link triggers an AJAX callback to replace parts of the form - actually to switch between two configuration modes. Having buttons for that would clutter the form too much, thus for the JS enabled version it uses the link.

This patch doesn't change whether the AJAX request uses POST or GET at all (it's using a POST afaik), but what it changes is, that if the link is inside a form, it properly submits the form values.

I do think this one is pretty straight-forward fix. It doesn't change whether links are using GET or POST requests, it just makes POST requests work properly. As of now a link used with #ajax would use POST but it wouldn't submit any form data. This patch fixes that in case the link is used in a form.

@use-case:
I'm using it together with the ajax #trigger_as functionality, so there is a button + a link. But when JS enabled, the button gets hidden and the link is shown instead. So UX is better (you won't have hundreds of buttons), but the form still degrades properly.

As of now I'm using it like this:

      $form['link'] = array(
        '#type' => 'link',
        '#href' => '#',
        '#title' => $value,
        // #id is used by the #ajax code.
        '#id' => $link_id,
        // Needed to actually output the #id.
        '#options' => array('attributes' => array('id' => $link_id)),
        '#process' => array('ajax_process_form'),
        // Hide the link by default and unhide it by javascript.
        '#prefix' => '<div class="rules-show-js">',
        '#suffix' => '</div>',
        '#ajax' => array(
          'callback' => 'rules_ui_form_ajax_reload_form',
          'wrapper' => 'rules-form-wrapper',
          'event' => 'click',
          // Trigger as the Switch button.
          'trigger_as' => array(
            'name' => 'param_' . $name,
            'value' => t('Switch'),
          ),
        ),
      );

@problem:
Do you mean #647228: Links are needlessly unable to fully participate in D7 AJAX framework features ? I don't see what should be conflicting here, so what's the problem?

@selector:
Interesting idea, I'll have a look at that. Thanks.

I don't think using another element + setting a selector helps as the problem is on the js side :( - once the link is clicked still the js won't sent the form data without a patch like #3.

As I noted in my initial post, this patch builds upon this work. Though the javascript needs this little fix to work with links too as input elements have the .form element in JS, but links do not.

ok, regardless #647228: Links are needlessly unable to fully participate in D7 AJAX framework features gets in or not - this js fix is an absolute requirement in order to make link triggered form submits possible at all. Note that this can't break anything, even if an ajax submit from inside the form is supposed to not deal with a form the sent form data won't harm - while it's just impossible to something meaningful together with forms without it.
I'm using already a rather tricky form element to do that, but it is working. If #647228: Links are needlessly unable to fully participate in D7 AJAX framework features cleans it up the PHP side too, the better.

I make use of links to trigger form submission in the rules UI to replace parts of the form - thus currently the module requires this patch to work. So I'd really like to see this fixed.

#3: ajax_js.patch queued for re-testing.

The problem is that this patch will *always* trigger a form submission of the closest form when clicking on a link in a form, regardless of whether the link should actually trigger the form submission.

Hm, I think you are right with that. Unintentionally submitting forms could trigger unintended JS code to run, what is problematic. But isn't it the same if AJAX submits stem from an input element? E.g. when picking a select box item the user doesn't intend to submit the form either. But as of now it works that way, and JS related form submits would be executed?

Ad solutions:
a) Yes that would be possible, but I think theming it that way such that it works properly in every browser is rather hard. As I was aware of the nice trigger_as stuff of the AJAX framework, I thought it's easier to leverage that instead... Perhaps I should just switch to a compactly themed button instead.

b) The AJAX framework just totally misses the opportunity to submit the form from non-input elements. I don't think we need a new selector to enable both though, we could use the existing one, but when #ajax is configured to trigger as a form API button the framework needs to automatically submit the form. Thus the framework should be already able to distinguish it probably on the server side, and just needs to ensure the JS is doing it right (-> add a setting?).

But well, as of now the server side is form related only, so a simple patch like that would make theoretically sense. #647228: Links are needlessly unable to fully participate in D7 AJAX framework features might change that though.

I'm using it together with the ajax #trigger_as functionality, so there is a button + a link. But when JS enabled, the button gets hidden and the link is shown instead. So UX is better (you won't have hundreds of buttons), but the form still degrades properly.

Hiding + showing stuff dependent on js is easy with simple css classes making use of html.js