Make it easy to add small bits of javascript through FAPI
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | javascript |
| Category: | task |
| Priority: | normal |
| Assigned: | cwgordon7 |
| Status: | patch (code needs review) |
Jump to:
A bit of javascript can often go a long way towards making Drupal more usable. Why, then, do we not see more javascript? Well, at the moment, if you want to add some javascript to your module, even if it's just one line, you have to create your own .js file, add it at the right time, mess around with Drupal.behaviors, and in the end, it's just a lot of effort for something that should be a breeze.
This patch intends to make it much, much easier for module maintainers to add tiny bits of javascript to their forms. The javascript is added in the following format:
<?php
$my_form_element = array(
'#type' => 'checkbox',
'#title' => t('My checkbox'),
'#default_value' => '',
'#js' => array(
'change' => "$('#edit-my-textfield').toggle();",
'event name' => 'code to run',
),
);
?>Along with the standard jQuery events (see http://docs.jquery.com/Effects), there is also the option of using the fake event 'run', which will simply cause that javascript to run when Drupal attaches its behaviors.
Included in this patch are two sample implementations. The first one removes/redisplays the user picture on the user edit page when the "Delete user picture" checkbox is toggled. The second one disables the "Page title" for profile listings when profile listings are not available (e.g. private profile fields).
Thoughts?
| Attachment | Size |
|---|---|
| form_js_01.patch | 9.83 KB |
#1
Oh and another interesting thing... for some reason, theme('radio') was not including the element id, that is also changed in this patch so that the behavior attaching works properly.
#2
What does
'event name' => 'code to run',do? I'll read the patch in more detail, but this line in your example confuses me.Edit: Sorry, I gather that it's just a placeholder, not a literal part of the code. I can be slow on occasion. :P
I am very much in favor of this patch. I will test it soon.
#3
Why does radio inherit and checkboxes don't?
#4
Isn't it that radios do not set the ID because multiple elements with the same ID would be XHTML-invalid?
It's legal (required) for names to duplicate, but never IDs. It also confuses Jquery, occasionally fatally.
Not sure what the work-around you need is. Fudge the ID out with a UID counter or something.
#5
@#3. Um, checkboxes should inherit too with the current patch. Is it not working?
@#4. No, FAPI guards against that, they're labeled foo-1, foo-2, foo-3, foo-4 automatically.
#6
Bump? :)
#7
I have been researching accessibility and Section 508 and WAI compliance lately.
I love JS but you have to be very careful - for example the collapsed fieldsets in Drupal hide much information from users with screenreaders.
As the Drupal project tries to keep within accessibility guidelines, I think this is why you do not see much JS in the core.
#8
I was told by somebody with visual disability that DHTML Menu was perfectly usable for him - shouldn't the same go for collapsed fieldsets? The collapsed labels are visible links, after all, so "clicking" on them (however this is done on a screenreading browser) is possible. I'm just guessing, of course.
#9
okay, so...
- patch is clean, no broken tests as well.
- the demos work fine as well (picture toggle slide up/down :-)
but,
- sorry, if i am dumb to ask :) But, we're just targeting form fields with toggle (like checkboxes) which can run specific JS code? I understood the patch?
#10
I was referring to this thread http://drupal.org/node/58941
#11
Subscribed. I would want to see more opinions on this.