The form plugin contains several useful methods that developers or site admins may wish to attach to forms.
Two of these are clearForm and resetForm (mainly the former, since the latter is generally natively supported by browsers) without JS).
clearForm clears all values entered into a form. It is invoked by the plugin's ajax methods but may also be useful directly, to allow users to clear values from a form when e.g. they change their minds.
The attached patch adds support for these two methods via the Forms API.
We begin by registering a new element type, 'push_button'. This is needed because the 'button' form element type is hard-coded (see theme_button() to be of type "submit", whereas here we'll want "button" and "reset" input elements.
For the clear button, we use CSS to hide the element is Javascript is not present. We use a #process callback to add the JS and CSS as needed and to add classes that will trigger the behavior. Finally, in a JS file, we process elements and attach the behaviour.
To test, add the following function to the jquery_form.module file:
function jquery_form_form_alter($form_id, &$form) {
if (!isset($form['clear_button'])) {
$form['clear_button'] = array(
'#type' => 'push_button',
'#value' => t('Clear'),
'#button_type' => 'clear',
);
$form['reset_button'] = array(
'#type' => 'push_button',
'#value' => t('Reset'),
'#button_type' => 'reset',
);
}
}
This will add a reset and a clear button to every form.
We could use the same general approach to enable adding of AJAX behaviours to forms via Forms API or via admin UI. I'll open a separate issue with suggestions about that.
| Comment | File | Size | Author |
|---|---|---|---|
| jquery-form-fapi.patch | 4.34 KB | nedjo |
Comments
Comment #1
wim leersInteresting idea!
Adding those to every form is not a good thing though, I think. For example for the (simple) search and user login forms, it's completely useless. We could create a list of forms for Drupal core where it should not be applied, but for contrib that's very difficult.
If/when a form registry would become available, we could offer an UI to let the user decide on which forms it should be enabled.
Suggestions?
Comment #2
wim leersAs you mentioned in your other post, a form registry "emulation" module is already available, the form_store module.
Comment #3
nedjoI'm not thinking of attaching this to all forms. The
jquery_form_form_alter()I gave above was just to help with testing. All I'm trying to do in the patch is to add support so that module authors can choose to use these buttons in their forms. E.g.:Later, maybe, we could consider some sort of UI for this, possibly using form_store, but for now the first step seems to be to add the basic Forms API support.
Comment #4
wim leersI'm sorry for the misunderstanding. Of course you're right. I'll review your code ASAP, but it will definitely get committed. Interested in getting commit access?
Comment #5
nedjoSure, that might be useful, particularly if I get around to merging ajaxsubmit into jquery_form_ui.
Comment #6
wim leersI gave you CVS access ;)
Comment #7
wim leersA port to Drupal 6 won't be necessary, because this jQuery plugin is now in Drupal core! Which also means that merging that adding these features to this module makes little sense.
Comment #8
nedjoThe original point of the module - including the jQuery forms plugin - is indeed met now in core. But core doesn't have (and may not get) methods for working with the plugin. So it might be worth considering a D6 version of this module that provides such methods.
Comment #9
wim leersWhy should that be in the "jquery_form" module then? I find that quite misleading. Something like "enhanced_forms" makes more sense to me.
Comment #10
wim leersAs per my last comment.