I am wondering if it would be possible to have a single inline datepicker as an alternate option to the pop up one that appears on page load. This would simplify and then no need for select menus to capture the date chosen. Similar to the style of what's on the this page:

http://www.kelvinluck.com/assets/jquery/datePicker/v2/demo/inlineDatePic...

Thank you

Comments

quicksketch’s picture

This is not possible through the Webform interface. You'd need to custom theme your form to remove the date field and display it as a calendar instead.

mrmeech’s picture

Version:6.x-3.0-beta5» 6.x-3.2

I was also looking for this! I think having a feature to display the calendar open by default and without the dropdown menus (unless JS is disabled) would be a FANTASTIC feature!

quicksketch’s picture

Status:Active» Postponed

I'm not currently planning on adding this as an option.

ice5nake’s picture

Version:6.x-3.2» 6.x-3.x-dev
Issue tags:+datepicker

I'd like to add my support for this feature. I think I have a place where this would be useful.

ice5nake’s picture

I started work on this and http://drupal.org/node/301949. The attached patch includes this inline option and maximum and minimum inline date options.

The inline option needs better css changes. Don't know if I will get back to finish this so I thought I'd at least share what I have.

Ideally I think an option to turn the date fields into hidden fields so that there is just an inline calendar would be nice to have.

ice5nake’s picture

New patch. Removed drupal_set_message debug alert. Sorry

quicksketch’s picture

I'd strongly suggest separating out the inline date picker from the min and max date. That feature is over here: #301949: Add option to only allow dates in the past/future.

Oh, you've actually uploaded the patch in *both* places. Please separate them and submit them individually.

As for the "inline" portion of this patch:

- The class names webform-calendar-inline-0/1 is pretty clunky.
- You should use the Webform webform_strtotime() and webform_strtodate() which use PHP 5's Date objects and proper timezone handling instead of the notoriously timezone-challenged strtotime() and date() functions.
- What happens if JavaScript is turned off with this patch?
- There's a lingering console.log(inline); in the code.
- Please use two spaces instead of tabs in your code, I'd suggest updating your text editor preferences to make this the default.

I'll comment on your date range patches in the other issue.

ace11’s picture

Anyone ported this to D7?

fietserwin’s picture

Version:6.x-3.x-dev» 7.x-3.x-dev
StatusFileSize
new3.62 KB

Inline only patch for D7. Javascript not enabled is no datepicker at all, not inline, not on clicking. Also in the inline case it does not replace the date input fields, it only augments them. So I don't see any problem with js disabled.

fietserwin’s picture

StatusFileSize
new3.56 KB

Oops, removed the console.log statement, but forgot to save the file before creating the patch. Here's another one without console.log

quicksketch’s picture

Status:Postponed» Needs review

Thanks @fietserwin! I'm impressed how trivial this implementation is! The only thing that gives me slight pause is that "Enable popup calendar" is a separate option from "Inline calendar". These two options really aren't meant to be used in conjunction with each other, rather they are alternatives. There's no real need for a user to check both boxes for "Enable popup calendar" and "Inline calendar", but if the user does not, the calendar does not work because the JS library is only added if the first checkbox is checked.

Rather than using checkboxes, I think we should switch the Calendar options to a set of radio button:

Date picker options:
(•) Popup calendar
( ) Inline calendar
( ) No calendar

Internally, I don't have much preference about whether these are multiple FormAPI properties or a single one, but the single approach would probably be the easiest implementation. Rather than "datepicker" being a boolean 0 or 1, we could also give it the special key "inline", to inform the element to use the inline picker rather than a separate property #inline.

Overall, this is a fantastic patch and I'm thrilled you've taken the time to make it. If we can eliminate the UI problem by switching to radio buttons, I think this patch is good to go.

fietserwin’s picture

I only chimed in as the inline datepicker is a good test case for the long outstanding issue #507502: (needs documentation) Provide Locale support for jQuery UI. That issue circles around a js load/execute order, and I solved that problem by wrapping the js in an attach behavior. But I had some doubts if it still would work if anyone would want to open a datepicker directly. Although I did not find this a "realistic" situation, ace11 entered the discussion and pointed to this issue. So apparently there is a use for it, and my patch from the other issue works with an inline datepicker when people do inline it in an attach behavior, like this patch already did.

To test it myself I had to adapt the patch from #6 to D7 and remove the min/max date parts. I did not really look into UI concerns or other optimizations. But I guess that you are right: showing that small calendar to pop-up a calendar is not needed anymore. The reason that this patch is so easy is the flexibility of the datepicker itself: inline datepicker.

So, I will probably not further adapt this patch, but hope that others can now pick it up and make it "production quality".

Oh, and if anybody can enter in on #507502: (needs documentation) Provide Locale support for jQuery UI to get it to RTBC, the datepicker that webform uses can finally be localized (inline or popup).

quicksketch’s picture

Version:7.x-3.x-dev» 7.x-4.x-dev
Status:Needs review» Needs work

This patch needs work per #11. At this point new features are only being added to the 4.x branch.

DanChadwick’s picture

Issue summary:View changes
Status:Needs work» Closed (won't fix)

Closing for lack of activity.