Need an event for 'OnAfterShow' to allow a more robust ui interaction with the datepicker.

Should the today button do more then just select the day? http://dev.jqueryui.com/ticket/4045

Could showing the datepicker on hover improve the interaction? http://dev.jqueryui.com/ticket/4329

Support week numbers? http://dev.jqueryui.com/ticket/4131

#Feature add:
1. allow a parameters to highlight multi dates with different color (diary , agenda or other tasks need it)
2. Zoom in , Zoom out ( to use it in any container or to full screen mode)

Support custom cell highlighting? http://dev.jqueryui.com/ticket/4528

I'm not sure if this has already been covered in the CSS changes but I've noticed some problems in IE 6 and 7...
1. The hover state only works while hovering over the anchor text for the date not the entire td element.
2. When using the changeMonth and changeYear options, the width is not calculating correctly causing the left and right floats to "overlap".

Ok, a proper DTD fixes the 2nd issue but it should probably work in quirks mode too.

#Feature suggest:
1. Better the width, height of the date picker or putting a zoom in or out parameter.

example of problem issues screen shot:
http://picasaweb.google.com/lh/photo/eAuHtoMdDCHjIMbjZlGOfA?feat=directlink

I'd like to be able to separate the month day and years into three different input fields but use the datepicker to update all three inputs at the same time.

For backwards compatibility I would prefer a separate compatibility script. This would remove unnecessary code from the head version and would encourage users to migrate. Of course, there would have to be ample warnings and documentation to inform people of the differences and ease their upgrade path.

For other DOM elements, what is the purpose of attaching the datepicker to other than an input field, a division or span?

Would it be possible to add to the DatePicker the ability to select Time as well?

Some recent feedback about needing datepicker improvements:

http://groups.google.com/group/jquery-ui/browse_thread/thread/afe5816aaf1bd19d

Apart from complaints about needing more tuts and demos, which we know is lacking, I think the jist of the above discussion is:

* Should we change the formatDate option so it's more inline with PHP's Date function
* Should we make the callback parameters more consistent? i.e. onSelect and onClose has dateText (string) but beforeShowDay has date (date object)

This depends on Marc calendar engine, right?

So I don't waste my limited time could we please be more specific on what the plan is? If we use Marc's calendar engine could I deduce that we won't be needing much of the existing datepicker code, hence better to start from scratch rather than refactoring?

I really like that widget. Question for u: how can I call t popup from a div, a link etc. let's say "Choose Date" or something. Do I always need to call it from input type="date"?

Most of the users with more experiences probably already know this but
others can have problems when implementing datepicker to ASP.NET
controls, for example textbox (especially if they are inside other
control - web form, repeater).



This is a solution somebody posted on asp.net forums:

1.) "Change the TextBox's CssClass property to "dateTextBox". Then,
use exactly this JavaScript (remove the other inline script in that
area so there are no extraneous errors):"

1.) (inside web form, control, etc.)
<script type="text/javascript">
$(document).ready(function() {
$('.dateTextBox').datepicker();
});
</script>

2.) if you do not have web control. You also don't need the css.

<script type="text/javascript">
$(function ()
{$('#date').datepicker();}
);
</script>


also you must have in masterpage the following code:
<link type="text/css" href="../CSS/jquery-
ui-1.7.2.calendar.css"rel="stylesheet" />
<script type="text/javascript" src="../JS/jquery-1.3.2.min.js" ></
script>
<script type="text/javascript" src="../JS/jquery-
ui-1.7.2.custom.min.js"></script>

<script type="text/javascript">
$(function(){

// Datepicker
$('#datepicker').datepicker({
inline: true
});

//hover states on the static widgets
$('#dialog_link, ul#icons li').hover(
function() { $(this).addClass('ui-state-hover'); },
function() { $(this).removeClass('ui-state-hover'); }
);

});
</script>

There can be better options to do this. Also you must notice that this
don't work in IE ("appearing" effect) as same as is working if you
have input type on page without any controls.

Any additional comments are welcome.

Of the options on the current datepicker, appendText is a good candidate to be dropped. It specifies the text to append after the input element. That is really easy enough do to with regular jQuery methods and outside the scope of the datepicker plugin.

The showOn, buttonText, buttonImage, and buttonImageOnly options could be refactored. Instead of exposing all these options, let the user create the input and pass that along for binding a click event; or open the datepicker on focus of the input by default, and let the user specify other events to open the picker, via datepicker("open").

The animation-options are odd at best. You have to set duration to an empty string (or any falsy? not sure) to disable animations. Then there is also showAnim and showOptions...

numberOfMonths, stepMonths and showCurrentAtPos are certainly useful, but the names don't suggest any relation between those, while they are actually closely related.

The altField option can be easily implemented using the select-callback.

onChangeMonthYear, onSelect and onClose need renaming.

The isDisabled method needs to be replaced with option-disabled. enable/disable methods, too.

get/setDate should be merged into one method.

show/hide could be renamed to open/close, to be more consistent with dialog.

The dalog-method is odd...

The beforeShow API is, well, odd. Returning arrays with two elements??

i'd like to see some access to some of datepickers date functions. This came about when i needed to do something with max date. I had to do it manually in the end but basically what i did was have a start date and end date (range) and i set the minDate of end date to the value returned by start date by doing ($('#startDate').datepicker('getDate') ) then i needed to set the maxDate of the end date to two months in the future of minDate. There was no easy way to do this with jquery so had to create a function to do using the date modifiers but we can change the date pretty easily on maxDate by doing maxDate: '+2'; what i'd like to be able to do is something that would support something like:

maxDate: $('#startDate').datepicker('getDate')+ '+1m'; (this isn't actually a proper way it should or can work i'm just trying to show it in laymens terms).

it might be done by being able to access one of datepickers actual functions that works it out and have the ability to set the date to start from but i think it'd be useful all the same. What i actually discovered here however i would consider a bug to be honest, maxDate works out the date based off todays date but doesn't take into account values set by minDate/defaultDate which i think it should as we're kinda already telling you where to take the date from.

Hello, after building a site into several languages.
I found that using $. Datepicker.setDefaults ($. Datepicker.regional ['en']); dynamic does not work very well with the "fr".
The locale does not work with English.

Example in PHP:

if ($ lang == 'en') (
print '$.datepicker.regional [ "en"]';
) elseif ($ lang == 'fr') (
print '$.datepicker.regional [ "fr"]';
)

My files for english params :

/* English initialisation for the jQuery UI date picker plugin. */
/* Written by Gerits Aurelien. (gerits point aurelien at gmail point com)*/
jQuery(function($){
$.datepicker.regional['en'] = {
closeText: 'Done', // Display text for close link
prevText: 'Prev', // Display text for previous month link
nextText: 'Next', // Display text for next month link
currentText: 'Today', // Display text for current month link
monthNames: ['January','February','March','April','May','June',
'July','August','September','October','November','December'], // Names of months for drop-down and formatting
monthNamesShort: ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'], // For formatting
dayNames: ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'], // For formatting
dayNamesShort: ['Sun', 'Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat'], // For formatting
dayNamesMin: ['Su','Mo','Tu','We','Th','Fr','Sa'], // Column headings for days starting at Sunday
dateFormat: 'mm/dd/yy', // See format options on parseDate
firstDay: 0, // The first day of the week, Sun = 0, Mon = 1, ...
isRTL: false // True if right-to-left language, false if left-to-right
};
$.datepicker.setDefaults($.datepicker.regional['en']);
});

I have made a lot of progress in refactoring the datepicker code. Got it using the widget factory and Marc's calendar. Will post the code after the switch to github, (gives me more time to clean up the code)

One question I had while working through that code was, is datepicker('dialog') really necessary? Doesn't that option just create glorified inline datepicker that is absolute positioned on the screen? Seems like with the new position plugin there is no need to support this as an option of the datepicker. It could easily be handled by doing this:

$('#inl2').datepicker({
select: function(){
// do something with the selected date then hide it
$(this).hide();
}
}).position({my:'center', at:'center', of:window});

Is it worth the extra code needed to support it as an option when it is so easy to do it outside the plugin, also considering how little use this option really gets?

I've done a refactor of the datepicker to conform to the current widget standard. It's available for review at https://jquery-ui.googlecode.com/svn/branches/labs/datepicker2.

As well as converting it to a widget, I've added the following:

* a templating ability to allow the end-user more control over the appearance of the datepicker,

* a command structure to allow end-users to add/change command buttons on the datepicker,

* common date routines for general use,

* use of the position plugin for placement,

* an extension module (jquery.ui.datepicker.ext.js) with less common usage requirements.

Please have a look through the demos and comment...