Launchpad uses proprietary datepicker code

I'll confirm this. Not sure why it's assigned to Tom though. Mark looked at all the JS datepicker code he could find and decided to buy a license for the one we have because it was the best out there and he didn't want to spend development resources creating a FOSS version.

Actually, Joey, that's not quite right.

Of the first batch of tools Mark looked at, the JS datepicker we're currently using was the best.

We subsequently found a FOSS datepicker that is at least as good, and under a reasonable licence.

We should switch to using a better and FOSS library at some point in the future, as we will want to do further development on datepickers.

I assigned it to Tom because we chatted about the issue and he expressed willingness to implement a Free datepicker. If one is already available, that's even better.

We should not develop our own date picker. That would place its ongoing maintenance on the Launchpad project.

Steve, do you remember the name of that FOSS datepicker that you liked? I just Googled, and there are a million of 'em out there now -- thus making it even more valuable to know the name of one that was already found to be decent :-).

I don't recall. However, we'd want one that works with YUI, now that we've chosen to use that with Launchpad.

Put into 2.2.5 and unassign from Tom Berger, as per Francis's request.

For open-sourcing Launchpad, we need to pull the proprietary datepicker out. If we can, we should replace it with an open-source datepicker, but if not, then we'll ship with no datepicker (yuck).

Fixed in r8406.

I've added the yui2 calendar widget as the datepicker, and a slightly modified version for the date-time picker.

The extra page-weight for the yui2 dependencies is not included in launchpad.js, but as an extra 2 js and 1 css requests on the pages using the picker.

This is an intermediate solution until we have a yui3-based picker.

The behaviour of the new picker emulates the old one. It has one missing feature in that it does not yet limit the users choice if from_date and to_date have been specified (easy to update to support this as the calendar widget has support build-in and I've encoded the from/to dates on the template within a hidden span).