Haven't delved into AHAH yet, this might force the issue. Using an easy (=less typing) example. A credit card form. When the credit card type is selected from a select, the selection needs to fire a javascript function that will disable fields that don't apply to that card type (such as CVV). Normally, I would have an onchange event for the select, and noticed that in the form api, while there is an attribute section to add miscellaneous attributes, the doc doesn't mention events as examples. And if putting an event there is legitimate, there isn't a mention of how to include the responding js function in the form. If AHAH is the way I'm supposed to handle this, I'd appreciate being pointed to a good similar example, because I'm a bit unclear from the AHAH entries in the form reference docs, for example, how to relate the myhandler/js entry to a physical location of the function, and how the function gets there. Thanks!
As long as you don't change form elements, you can use traditional javascript/jquery. So it would be OK to hide/show or disable/enable the CVV field in your example. If you change them (for example, by adding in a CVV field, or by changing the options in a select) then form validation will fail. That's the case where you're forced into AJAX(D7)/AHAH. If you find you need to do AHAH, there are working examples in the Examples module (http://drupal.org/project/examples), and there is a tutorial at http://randyfay.com/ahah, which also has references to other information. -Randy On Sun, Nov 22, 2009 at 1:37 PM, Jeff Greenberg <jeff@ayendesigns.com>wrote:
Haven't delved into AHAH yet, this might force the issue.
Using an easy (=less typing) example. A credit card form. When the credit card type is selected from a select, the selection needs to fire a javascript function that will disable fields that don't apply to that card type (such as CVV).
Normally, I would have an onchange event for the select, and noticed that in the form api, while there is an attribute section to add miscellaneous attributes, the doc doesn't mention events as examples. And if putting an event there is legitimate, there isn't a mention of how to include the responding js function in the form.
If AHAH is the way I'm supposed to handle this, I'd appreciate being pointed to a good similar example, because I'm a bit unclear from the AHAH entries in the form reference docs, for example, how to relate the myhandler/js entry to a physical location of the function, and how the function gets there.
Thanks!
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
Obviously doing something wrong with Ctools (latest version enabled in D6) Here is the form field that should disappear when the option selected in the edit-cc-type field is Other. The Ctools parameters are the last two. $form['cc_cvv'] = array( '#type' => 'textfield', '#title' => t('CVV'), '#default_value' => $_SESSION['clear_cc'] ? '' : $default_cvv, '#attributes' => array('autocomplete' => 'off'), '#size' => variable_get('uc_credit_amex', TRUE) ? 4 : 3, '#maxlength' => variable_get('uc_credit_amex', TRUE) ? 4 : 3, '#process' => array('CTools_process_dependency'), '#dependency' => array('edit-cc-type'=> array('Visa','Mastercard','Discover','American Express')), ); Changing the selected option has no affect on this field. Jeff
AHAH is generally more for submitting something and changing the form, this doesn't really sound like your example. ie. submitting a file like in the d.o issue queue. Generally the "Drupal way" is the jQuery way in the simple case you described. It doesn't add javascript directly to anything html elements and uses the jQuery event handlers in a javascipt file added to the page. This ends in much more manageable code, less html, etc. http://docs.jquery.com/Events/change On Sun, Nov 22, 2009 at 12:37 PM, Jeff Greenberg <jeff@ayendesigns.com> wrote:
Haven't delved into AHAH yet, this might force the issue.
Using an easy (=less typing) example. A credit card form. When the credit card type is selected from a select, the selection needs to fire a javascript function that will disable fields that don't apply to that card type (such as CVV).
Normally, I would have an onchange event for the select, and noticed that in the form api, while there is an attribute section to add miscellaneous attributes, the doc doesn't mention events as examples. And if putting an event there is legitimate, there isn't a mention of how to include the responding js function in the form.
If AHAH is the way I'm supposed to handle this, I'd appreciate being pointed to a good similar example, because I'm a bit unclear from the AHAH entries in the form reference docs, for example, how to relate the myhandler/js entry to a physical location of the function, and how the function gets there.
Thanks!
Jeff Greenberg wrote:
Haven't delved into AHAH yet, this might force the issue.
Using an easy (=less typing) example. A credit card form. When the credit card type is selected from a select, the selection needs to fire a javascript function that will disable fields that don't apply to that card type (such as CVV).
Normally, I would have an onchange event for the select, and noticed that in the form api, while there is an attribute section to add miscellaneous attributes, the doc doesn't mention events as examples. And if putting an event there is legitimate, there isn't a mention of how to include the responding js function in the form.
If AHAH is the way I'm supposed to handle this, I'd appreciate being pointed to a good similar example, because I'm a bit unclear from the AHAH entries in the form reference docs, for example, how to relate the myhandler/js entry to a physical location of the function, and how the function gets there.
You wouldn't use AHAH. CTools as a tool called 'dependent' that will help you do this kind of behavior without having to write any javascript.
Great to hear about CTools 'dependent', Earl! Can you point us to information about it, or give us an example of how we'd use it, or point us to related code? Thanks for all you do! -Randy On Sun, Nov 22, 2009 at 2:07 PM, Earl Miles <merlin@logrus.com> wrote:
Jeff Greenberg wrote:
Haven't delved into AHAH yet, this might force the issue.
Using an easy (=less typing) example. A credit card form. When the credit card type is selected from a select, the selection needs to fire a javascript function that will disable fields that don't apply to that card type (such as CVV).
Normally, I would have an onchange event for the select, and noticed that in the form api, while there is an attribute section to add miscellaneous attributes, the doc doesn't mention events as examples. And if putting an event there is legitimate, there isn't a mention of how to include the responding js function in the form.
If AHAH is the way I'm supposed to handle this, I'd appreciate being pointed to a good similar example, because I'm a bit unclear from the AHAH entries in the form reference docs, for example, how to relate the myhandler/js entry to a physical location of the function, and how the function gets there.
You wouldn't use AHAH. CTools as a tool called 'dependent' that will help you do this kind of behavior without having to write any javascript.
-- Randy Fay Drupal Development, troubleshooting, and debugging randy@randyfay.com +1 970.462.7450
Earl Miles wrote:
You wouldn't use AHAH. CTools as a tool called 'dependent' that will help you do this kind of behavior without having to write any javascript.
Thanks everyone. Earl, coincidentally, I started working on another site last night, and had installed CTools and was looking forward to trying them out. More so now!
A quick way to do this is to use the attributes as you mentioned. Any HTML attribute can be added into the attributes array as follows: $form['cc'] = array ( ... '#attributes' => array( 'onChange' => "some_js_funtion();" ), ... You can include Jquery directly there instead of the function if you simply need to hide a div, or you can use: drupal_add_js(path_to_file); Of course, from a JavaScript purists mindset, you should attach all the event handlings later, but that is a completely different topic. If you have a callback to get more information from a menu callback, then AHAH or CTOOLs is definitely the way to go, but for simpler affects this way might be sufficient. Greg -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Jeff Greenberg Sent: Sunday, November 22, 2009 10:38 AM To: development@drupal.org Subject: [development] Drupal way of doing onchange Haven't delved into AHAH yet, this might force the issue. Using an easy (=less typing) example. A credit card form. When the credit card type is selected from a select, the selection needs to fire a javascript function that will disable fields that don't apply to that card type (such as CVV). Normally, I would have an onchange event for the select, and noticed that in the form api, while there is an attribute section to add miscellaneous attributes, the doc doesn't mention events as examples. And if putting an event there is legitimate, there isn't a mention of how to include the responding js function in the form. If AHAH is the way I'm supposed to handle this, I'd appreciate being pointed to a good similar example, because I'm a bit unclear from the AHAH entries in the form reference docs, for example, how to relate the myhandler/js entry to a physical location of the function, and how the function gets there. Thanks!
FYI if you do the 'onChange' and have your site set to XHTML strict it won't work. Change it to 'onchange' and you'll be fine. I see a lot of people get caught by that one. Jamie Holly http://www.intoxination.net http://www.hollyit.net Greg Holsclaw wrote:
A quick way to do this is to use the attributes as you mentioned. Any HTML attribute can be added into the attributes array as follows:
$form['cc'] = array ( ... '#attributes' => array( 'onChange' => "some_js_funtion();" ), ...
You can include Jquery directly there instead of the function if you simply need to hide a div, or you can use:
drupal_add_js(path_to_file);
Of course, from a JavaScript purists mindset, you should attach all the event handlings later, but that is a completely different topic.
If you have a callback to get more information from a menu callback, then AHAH or CTOOLs is definitely the way to go, but for simpler affects this way might be sufficient.
Greg
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Jeff Greenberg Sent: Sunday, November 22, 2009 10:38 AM To: development@drupal.org Subject: [development] Drupal way of doing onchange
Haven't delved into AHAH yet, this might force the issue.
Using an easy (=less typing) example. A credit card form. When the credit card type is selected from a select, the selection needs to fire a javascript function that will disable fields that don't apply to that card type (such as CVV).
Normally, I would have an onchange event for the select, and noticed that in the form api, while there is an attribute section to add miscellaneous attributes, the doc doesn't mention events as examples. And if putting an event there is legitimate, there isn't a mention of how to include the responding js function in the form.
If AHAH is the way I'm supposed to handle this, I'd appreciate being pointed to a good similar example, because I'm a bit unclear from the AHAH entries in the form reference docs, for example, how to relate the myhandler/js entry to a physical location of the function, and how the function gets there.
Thanks!
On Nov 22, 2009, at 2:25 PM, Greg Holsclaw wrote:
Of course, from a JavaScript purists mindset, you should attach all the event handlings later, but that is a completely different topic.
I'll bite. One might argue that inline JS violates Drupal coding standards: http://drupal.org/node/172169#jscodeplacement That could be read with a more narrow meaning (i.e. event function bindings are okay, nothing else), but is there any actual benefit to doing inline JS? It's not as if it's more difficult to select an element and apply an event handler in jQuery. $('#edit-cc').change(some_js_funtion); Doing things the "purist" (right) way seems to be both easier and better for modularity, so why not do it? -- Scott Reynen MakeDataMakeSense.com
Unless it is added inline with a defer then you do risk loading problems: <script type="text/javascript"> $("#edit-cc").change(edit-cc-function); </script> <script src="/path/to/edit-cc-function.js"></script> Without the defer, edit-cc-funciton will be undefined. Even though this scenario is most likely for private use, something else that should be considered in contrib modules as well as core (and possibly added to the JS coding standards) is the use of event namespaces. That way you can easily disable any bound events later on in the code without having to rewrite the original JS. Something like: $("#edit-cc").bind("click.myccmodule",edit-cc-function); Now if I want to unbind that function all I got to do is: $("#edit-cc").unbind("click.myccmodule"); Want to unbind every event that module binds to? $("#edit-cc").unbind(".myccmodule"); It really adds a nice new layer of extensibility. http://docs.jquery.com/Namespaced_Events Jamie Holly http://www.intoxination.net http://www.hollyit.net Scott Reynen wrote:
On Nov 22, 2009, at 2:25 PM, Greg Holsclaw wrote:
Of course, from a JavaScript purists mindset, you should attach all the event handlings later, but that is a completely different topic.
I'll bite. One might argue that inline JS violates Drupal coding standards:
http://drupal.org/node/172169#jscodeplacement
That could be read with a more narrow meaning (i.e. event function bindings are okay, nothing else), but is there any actual benefit to doing inline JS? It's not as if it's more difficult to select an element and apply an event handler in jQuery.
$('#edit-cc').change(some_js_funtion);
Doing things the "purist" (right) way seems to be both easier and better for modularity, so why not do it?
-- Scott Reynen MakeDataMakeSense.com
Greg Holsclaw wrote:
A quick way to do this is to use the attributes as you mentioned. Any HTML attribute can be added into the attributes array as follows:
Thanks. That's what I've done for now, until I figure out how to make CTools work. Frustratingly, the field has an ID, but neither the label, the cell they're in or the row that the cell is in have ID's. So without doing more work than is warranted, the field disappears but not its label. So when the field disappears, I replace it with a string 'Not applicable.'
$("#{field_id}").prev('label') will give you the label Jamie Holly http://www.intoxination.net http://www.hollyit.net Jeff Greenberg wrote:
Greg Holsclaw wrote:
A quick way to do this is to use the attributes as you mentioned. Any HTML attribute can be added into the attributes array as follows:
Thanks. That's what I've done for now, until I figure out how to make CTools work. Frustratingly, the field has an ID, but neither the label, the cell they're in or the row that the cell is in have ID's. So without doing more work than is warranted, the field disappears but not its label. So when the field disappears, I replace it with a string 'Not applicable.'
Jamie Holly wrote:
$("#{field_id}").prev('label') will give you the label Might have worked if the label were encased in <label> tags, but it's really ugly...like this
<tr> <td class="generalclass">labeltest</td> <div>field</div> </td> </tr> don't know why it was done that way. I tried prev("td"), prev("td.generalclass") and prev("tr") ... nada
That isn't even valid - having the <div> not inside a <td> or <th>. That could lead to problems, but you might want to try: $("#{field_id}").parent().prev('.generalclass'); Like I said it might not even work considering the markup you are showing is invalid in HTML and XHTML. If for some reason you missed the <td></td> surrounding the div then try this: $("#{field_id}").parents('td').prev('.generalclass'); Jamie Holly http://www.intoxination.net http://www.hollyit.net Jeff Greenberg wrote:
Jamie Holly wrote:
$("#{field_id}").prev('label') will give you the label Might have worked if the label were encased in <label> tags, but it's really ugly...like this
<tr> <td class="generalclass">labeltest</td> <div>field</div> </td> </tr>
don't know why it was done that way. I tried prev("td"), prev("td.generalclass") and prev("tr") ... nada
Jamie Holly wrote:
That isn't even valid - having the <div> not inside a <td> or <th>. That could lead to problems, but you might want to try:
$("#{field_id}").parent().prev('.generalclass');
Yeah, it's pretty ugly...but that worked! Thanks, Jamie.
participants (7)
-
Earl Miles -
Greg Holsclaw -
James Gilliland -
Jamie Holly -
Jeff Greenberg -
Randy Fay -
Scott Reynen