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:

$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?

CommentFileSizeAuthor
form_js_01.patch9.83 KBcwgordon7

Comments

cwgordon7’s picture

cwgordon7 commented

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.

cburschka’s picture

cburschka
they
commented

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.

chx’s picture

chx commented

Why does radio inherit and checkboxes don't?

dman’s picture

dman commented

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.

cwgordon7’s picture

cwgordon7 commented

@#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.

cwgordon7’s picture

cwgordon7 commented

Bump? :)

decibel.places’s picture

decibel.places commented

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.

cburschka’s picture

cburschka
they
commented

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.

lut4rp’s picture

lut4rp commented

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?

decibel.places’s picture

decibel.places commented

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.

I was referring to this thread http://drupal.org/node/58941

lut4rp’s picture

lut4rp commented

Subscribed. I would want to see more opinions on this.

cwgordon7’s picture

cwgordon7 commented

Accessibility issues should not be a problem here; in this particular patch, no extra information is being hidden by default or anything like that.

Anonymous’s picture

Anonymous (not verified) commented
Status: Needs review » Needs work

The last submitted patch failed testing.

mgifford’s picture

mgifford
he/him
Primary language English
commented

The problem here isn't with the JS, but with the CSS. The use of display:none; is the problem and there are solutions. See http://drupal.org/node/58941

casey’s picture

casey commented
Status: Needs work » Fixed

We have alike functionality now: http://drupal.org/node/224333#attached_js

Status: Fixed » Closed (fixed)

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