Wouldn't it be nice if we could attach an url to a select form field and have it make an ajax call passing the selected option to the callback function. Imagine injecting another select field or a whole bunch of them back into the document, each with their own url ready to get their on change events fired up resulting in more ajax requests.

Imagine no more just apply the attached patch to HEAD and respond with your comments.

New functionality:
ctools_ajax_select_change_element - retrieve a select form element ready to have an url attached.
ctools_ajax_select_change - attach url and inject the element into the document via an ajax request.
ctools_ajax_select_change_add_js - prepare a normal drupal form callback for select on change ajax.

New commands:
ctools_ajax_command_data - implementation for $.data jquery data cache attachments. see
ctools_ajax_command_messages - enable drupal messages for ajax callbacks.

More detailed explanation and examples are in the patch...

@Earl and everyone else whom are helping: Tx for an awesome project. You guys rock!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

nickl’s picture

And then there was: AHAH!
And on the 9th day...

nickl’s picture

Created seperate issues for command patches.

New commands:
ctools_ajax_command_data - implementation for $.data jquery data cache attachments.
ctools_ajax_command_messages - enable drupal messages for ajax callbacks.

Yet these changes still reside here as they are dependent. If above issues get committed I will reroll this patch again.

This still works easier than the ahah imho maybe we can plan this better for all input types and use as alternative to drupal ahah.

What are your thoughts and suggestions?

Rerolled patch against HEAD.

merlinofchaos’s picture

I would really love to completely replace Drupal's ahah. There are some questions of philosophy. quicksketch, the author of Drupal's ahah, didn't want to have to do any server work like this, but his method is really hard for people to work with. I don't quite know what the real answer is, except that this is, IMO, great stuff.

Ok, first, I love this functionality. I'm definitely happy about this.

I don't particularly like ctools_ajax_select_change_element. I can see a couple of different ways to do this.

1) Provide a '#type' => 'ctools_ajax_select' which does the magic and you set fields normally.
2) Provide a '#process' command like we do for dependent
3) Provide a function that operates on a reference that's already created. i.e,

  $form['foo'] = array(
    '#type' => 'select',
    '#options' => array('a', 'b', 'c'),
  );
 
  ctools_ajax_select_change($form['foo'], ...)

In general, having the select widget be added by a function doesn't work real well in terms of code readability and niceness and makes it harder to add extra stuff or change little used flags. Things like #prefix, #suffix, #multiple, etc.

Otherwise, this is fantastic!

andrewlevine’s picture

FileSize
5.23 KB

Here is a more generalized approach to select on change (much of it taken from nickl's original patch). In this patch, just like the clickAJAXButton and clickAJAXLink, changeAJAXSelect will take arbitrary actions on a select change. Rather than only allowing one ajaxable select per page, this approach allows multiple and also doesn't define any easy way to do drill-down selects without coding it yourself.

merlinofchaos’s picture

+ *   ctools_ajax_select_change_element($form, 'example', 'example/ajax/urlpath');

That second argument, 'example', should probably be $form['example'] -- because if my element is at, let's say $form['taxonomy'][1]['terms'] I'm going to have some issues, aren't I? Of course that's going to make it difficult to auto-extract the id without knowing the parents. annoying!

That might lead to creating a '#type' => 'ctools_ajax_select' in order to be able to use #process. Which actually would be much nicer UX, so maybe that's a good idea too.

It would be nice to allow an option to just submit the form, too. Note that the page manager selection form just wants to submit on change. If we do that I could then probably work the textfield bit I have into ctools and eliminate the custom javascript entirely.

andrewlevine’s picture

FileSize
4.95 KB

OK. Here is another run at doing this: First instead of using an onchange specific function to associate a URL, we use the helper ctools_ajax_associate_url_to_element(). This can actually also be used for click-button ajax also.

To make an AJAX call onChange you have to:
1. associate a URL to an element with the helper function
2. add the class ctools-use-ajax-onchange to your element.

If you want to submit onChange you have to:
0. (Optionally) associate a URL to be called with ajax onchange before submit.
1. Add the class ctools-use-ajax-onchange to your element.
2. Add the class ctools-ajax-submit-onchange to your element.

This is also no longer specific to select forms. It works on types textfield radio and checkbox. Also, because this uses a POST ajax call, it requires #522836: Form IDs are incorrect when rebuilding form in a POST request, but you already committed that!

merlinofchaos’s picture

Status: Needs review » Fixed

Looks like this is committable.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

gavri’s picture

I'm trying to implement this function but i don't fully understand how to use is.
can you give a working example of this function in action or explain what should i write in the helper menu function

thanks