Preface: I'm using PHP5.2.

In date_popup_process_date() of date_popup.module, the comments for date_popup_js_settings_class read "Create a unique CSS class name and output a single inline JS block, for each unique combination of startup function to call and settings array to pass it."

On my project, I'm using drupal_get_form to programmatically load my cck form (using jstools, working great!) into a non-node page (i.e. not a node/123 page). That meant I had to manually call drupal_add_js and drupal_add_css to load the necessary popup date code. Activating it--i.e. popping the calendar onto the screen--means:

$('.jquery-calendar-0').calendar(...settings...)
$('.jquery-calendar-1').calendar(...settings...)
$('.jquery-calendar-2').calendar(...settings...)

I want to use the same settings for each calendar-0, calendar-1, calendar-2, etc. but I don't know *how many times* to call drupal_add_js('code','inline') since I have many cck types, each of which could use 0, 1, 2, or more date (popup date) fields. My thought is to loop through the $form array to find [#type] => date_combo and then run drupal_add_js on it, but that seems clunky...

Any suggestions?

Comments

light-blue’s picture

light-blue commented

My previous thought didn't work. I suspect this is culprit...

To clarify, I'm loading these cck forms with AJAX (via ajaxsubmit in jstools). While date_popup_js_settings_class() runs fine, the browser has already (previously) loaded my (non cck-based) page. As a result, I suspect that when date_popup_js_settings_class() calls drupal_add_js('whatever','inline'), the browser ignores(?) the inline output, perhaps since ($document.ready()) already ran... Am I close?

light-blue’s picture

light-blue commented

I found a solution, please let me know if this makes sense...

Based on my question here (http://groups.google.com/group/jquery-en/browse_thread/thread/dc7f1e9c72...), I changed date_popup.module on line 253 to read

//'#attributes' => array('class' => $class),
'#attributes' => array('class' => 'date_popup '.$class),

Which provides an additional class for jquery targeting. I don't see a downside to this change. Thoughts?

karens’s picture

karens commented
Status: Active » Needs review

I don't know enough about the code used in the popup to know if this will break anything else and I'm trying to get the code to a stable state because I'm moving all my attention to D6 and D7, so I don't like to introduce anything that might break.

If others can confirm that this really won't break anything, I'll commit it, otherwise I'm not going to.

karens’s picture

karens commented
Status: Needs review » Fixed

OK, I think I was overly cautious about this. There should be no harm in adding a new class, so fixed.

Status: Fixed » Closed (fixed)

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

docwilmot’s picture

docwilmot commented

same issue, but this was removed in D6 version.

docwilmot’s picture

docwilmot commented
Version: 5.x-2.4 » 6.x-2.4
Status: Closed (fixed) » Active
karens’s picture

karens commented
Status: Active » Closed (fixed)

Don't reopen a two year old issue and just say 'same issue'. Both the date code and the jquery code have changed since this was originally posted. Whatever problem someone is having with the current code is a new problem. And if it's a jquery problem, the question goes on the jquery ui issue queue, not here.

docwilmot’s picture

docwilmot commented

to clarify, someone raised an issue with the 'date_popup 5.x-2.4 module', and suggested a fix, which you agreed was a good idea. you committed that fix to the 'date_popup 5.x-2.4 module'. it seems that fix is no longer present in 'date_popup 6.x-2.4 module'; i assumed it was inadvertently left out, and i attempted to let you know that. excuse me.
FWIW, yes, i did find your response annoying.
keep up the good work.

karens’s picture

karens commented

If you were maintaining several huge projects and had thousands of issues to work with, and were doing all this for nothing in your 'free' time, I suspect from time to time you would say things that other people found 'annoying' as you tried to whittle out the issues that are really important from those that aren't. You would probably also enjoy being chewed out if you happened to unintentionally use the wrong tone in a response while you are charging through hundreds of issues to try to address them all.

You were not very clear in what you said. You reopened an old issue, switched the version and hardly explained what you meant.

The D6 code is totally different than the D5 code. Issues that pertain to D5 rarely apply to D6. If you think there is something that really got lost and it still applies to the D6 code, I need more information about exactly what you think needs to be done and probably a patch or example of what in the D6 version is needed.

docwilmot’s picture

docwilmot commented

the most annoying thing is that youre right, and i'm wrong, after all. apologies for the tone.
when i first raised the issue, it was after searching for a simple way to do the following:
1 upon changing a date in one datepicker (picker 1)
2 use js to loop through all datepicker-enabled fields on the same page and apply the same date as 'picker 1.
but there isnt a common class to all picker-enabled fields so that jquery can find them easily. classes 'hasdatepicker' and 'datepicker-init' are added only after the input field is clicked at least once.
adding:
'#attributes' => array('class' => 'date-popup '. $class),
below line 276 in date-popup latest version (date_popup 6.x-2.4) enables this simply.
it is a minor, and apparently very uncommon, request so no worries if its seen as unnecessary. i will keep the current hack.
keep up the good work.