By replacing starting/end dates with the DateAPI, users wouldn't have to futz with so many individual course date fields. Plus, using the jQuery UI module, the DateAPI allows a datepicker to select the correct date from a pop-out calendar.

Comments

wjaspers’s picture

wjaspers commented

The other good reason to change these fields to DateAPI is that automated workflows, scheduling and other modules can control access to, the publication of, or other features of each 'course', 'assignment', 'response' or other node.

EDIT:
Shows what I know; Date API is practically already built-in.
What it turns out I was thinking of is the "date_popup" field formatter and some other miscellaneous functionality.

In modifying the code, I've gotten the popup to work, but field data isn't being pulled in (although it saves correctly when a date is picked).

imobachgs’s picture

imobachgs commented

Hi wjaspers,

I could be nice. I'll take this feature into account when I restart the work on this module.

Thank you!

wjaspers’s picture

wjaspers commented

I discovered its a relatively simple fix; although, I can't seem to get the fields to populate after saving them (the DB is holding the correct data).

change '#type' from 'date' or 'date_select' to 'date_popup' ...

I am unaware if date_popup will fallback to 'date_select' or 'date' when the date_popup function/js is not available.

My views integration helps alleviate some of the stresses involved with accessing start/end dates. I think all that's really left is to make the interface easier to use (i.e. switching the fields to date_popup or similar). (http://drupal.org/node/727474#comment-3569562)

wjaspers’s picture

wjaspers commented
Status: Active » Closed (fixed)

Date tokens will be available when the next release is done. (http://drupal.org/node/972610)