Posted by robertdouglass on May 6, 2006 at 1:27pm
Hi Nedjo,
did you get a chance to review my activeforms module?
I couldn't attach it here so you can download it from here.
The point of the module is to be able to use your forms api definition to attach event listeners to any DOM object, and to use the fapi form to repopulate client side elements via AJAX. This eliminates having to define separate callback functions for AJAX.
I'll see if I can improve the activeforms_test.module some (the text example is dumb and broken).
I don't know how or if this intersects with the other initiatives.
Cheers,
Robert
Comments
in FAPI 2.0
I am working towards being able to attach listeners to any element. (not just forms).
So you would be able to tell a certain block it needs to refresh every 30 seconds. for instance.
--
The future is so Bryght, I have to wear shades.
Wicked
Well, don't know if it is useful, but I think I solved a number of the problems you'll encounter. See the link.
PHP 5 errors
it was just pointed out to me that there are PHP 5 pass-by-reference errors. Guess I'll finally have to take a look at PHP 5.
Nice work
We're often attaching behaviours to form (and other) elements. Examples include autocomplete, the jscalendar module, and activeselect. In each case we have common challenges: how to attach the behaviour to the element, how to pass associated data, etc.
So far we've used a range of approaches. Autocomplete injects itself right into the textarea theme function. Effective, but not something other (non-core) behaviours can replicate. Activeselect defines its own custom element type--again, one way to solve the problem, but other behaviours looking for '#select' elements won't find this one. jscalendar iterates through all form elements to look for a class (much like your approach, Robert). Okay, but a lot of searching, and in any case we certainly don't need a separate iterating function for each behaviour.
So, yes, developing a common framework for attaching behaviours is important, and your work here sketches out some useful directions.
See this related issue, http://drupal.org/node/57865, Move js behaviours out of form element theme functions.
Attaching the behaviors was nice
especially since the fapi now lets you do it from anywhere, so using activeforms, any module can attach client behavior to the form using the activeform element type.
Another part of the module that is important, though, is the fact that it doesn't require extra callbacks. In the end it puts a big burden on the developer to maintain the security that we built into fapi if all AJAX requests hit dedicated callback functions that put together the response however they please. Plus it is redundant. Activeforms recycles the original form, eliminating the extra callbacks, increasing security, and reducing redundacy.
Custom element types
The activeforms module looks very promising - from what I can tell, it provides the foundation for AJAX-enabled modules to have an effect on form elements without troubling each other at all.
Activeselect defines its own custom element type (the 'activeselect' type) because it's the easiest way to output the class name and the hidden values that are needed for subsequent AJAX callbacks. The theme_activeselect() function is also a convenient place to include the JS library and the CSS file. I'm not sure if activeforms can do all of this in a standard way, without re-theming actual form elements - but if it can, that's awesome! Hopefully this will get into core eventually, as an 'improved JS API'. Nice work, Robert!
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
Thanks!
It was your activeselect that inspired it =)
Include in Javascript Tools?
Activeforms fits well with the Javascript Tools aim of providing a common set of methods for JS and AJAX development. Existing modules (jscalendar, etc.) that attach behaviours to forms could be reworked to do so through the activeforms methods. We could look at options like:
(I haven't yet found the time to look closely at the code to know what makes most sense.)
Are you interested Robert in adapting activeforms for inclusion in Javascript Tools?
You bet!
This is exactly what I intended it to be used for... to support a wide range of tasks in a way that is easy for programmers to grok and doesn't add a lot of cruft to the codebase.
The problem I have at the moment is time. That's why I want to get other developers involved who can also help take it to the next level. June looks better, though, time-wise, so I'll definitely be able to help out with this effort.
Maybe a good first step would be to get more people involved. I should set up a demo site and put the code somewhere where more people can find it.
Stuck
I am a bit stuck with using this module in my own module (also I'm pretty new to drupal - so don't be too hard on me). I have created something of this kind:
...$form['slice'] = array(
'#type' => 'select',
'#title' => t('Slice'),
'#default_value' => '-1',
'#description' => t('ActionApps Slice'),
'#options' => $slices,
'#prefix' => '<span id="slice-wrapper">',
'#suffix' => '</span>',
);
$form['view'] = array(
'#type' => 'select',
'#title' => t('View'),
'#default_value' => '-1',
'#description' => t('ActionApps View'),
'#prefix' => '<span id="view-wrapper">',
'#suffix' => '</span>',
...
$form['activeforms_definitions'] = array(
'#type' => 'activeforms',
'#listeners' => array(
'edit-slice' => array(
'onchange' => array(
'#targets' => array(
array(
'id' => 'view-wrapper',
'property' => 'innerHTML',
'render-path' => array('slice'),
),
),
'#passbacks' => array(
'edit-slice' => 'value',
...
I notice that activeforms_test relies on the theme_activeforms_test_selects_page hook. I'm not quite clear what the difference is between that and directly using #prefix.
Any idea what's going wrong. My thing just makes the second form element invisible.. (It's part of a admin/configure)
Thanks in advance,
mimo