Skip to main content

Search and Top Navigation

#6228 open bug ()

Opened October 26, 2010 01:10PM UTC

Last modified January 10, 2015 01:57PM UTC

Datepicker: Use widget factory

Reported by: scottgonzalez Owned by:
Priority: blocker Milestone: 1.13.0
Component: ui.datepicker Version: 1.8.5
Keywords: rewrite Cc:
Blocked by: Blocking:
Description

There are a lot of inconsistencies between datepicker and other UI widgets because the datepicker doesn't use the widget factory. This ticket will act as a catch-all for these inconsistencies and bugs.

Attachments (0)
Change History (16)

Changed February 21, 2012 12:48PM UTC by scottgonzalez comment:1

#8125 is a duplicate of this ticket.

Changed March 01, 2012 12:41PM UTC by scottgonzalez comment:2

#6935 is a duplicate of this ticket.

Changed March 02, 2012 08:50AM UTC by raphinesse comment:3

_comment0: So it is a '''known issue for at least 16 months''' that datepicker does not use the widget factory and thus does not fire the create event. Why then is this still '''not documented'''? \ \ At [http://jqueryui.com/demos/datepicker/#event-create] it still says you can use the create event while you obviously can not. What makes this even worse is the fact that the beforeShow event does not fire either when using the datepicker inline which leaves you with nothing to hook into before the datepicker is shown. It would be nice to have this last "edge case" documented too.1330678685693259

So it is a known issue for at least 16 months that datepicker does not use the widget factory and thus does not fire the create event. Why then is this still not documented?

At http://jqueryui.com/demos/datepicker/#event-create it still says you can use the create event while you obviously can not. What makes this even worse is the fact that the beforeShow event does not fire either when using the datepicker inline which leaves you with nothing to hook into before the datepicker is shown. It would be nice to have this last "edge case" documented too.

I just noticed there even is a refactored version of datepicker available at https://github.com/kbwood/jquery-ui. It's been there for 2 years. So what's the matter?

Changed March 02, 2012 09:23AM UTC by rdworth comment:4

_comment0: The lack in documentation was unfortunately due to an issue with our current documentation system, which lists all options and methods and events provided by the widget factory, including (in this case) the create event. Both the datepicker and the documentation system are being entirely rewritten, which will solve the issue from both sides. In the meantime, I've created a custom template just for datepicker that leaves out the create event (as it is not implemented, and likely won't be until rewritten to use the widget factory) and also added a note in its place saying it's a known issue that the create event is not triggered. This change is live at http://docs.jquery.com/UI/Datepicker#events and will be live on http://jqueryui.com/demos/datepicker#events when the next stable release goes up. \ \ > What makes this even worse is the fact that the beforeShow event does not fire either when using the datepicker inline \ \ beforeShow doesn't make any sense for an inline datepicker because it's always visible. Hence, there is no point before which it is shown. So this is by design. \ \ Anyway, here's a workaround for the missing create event: \ {{{ \ // Workaround for missing datepickercreate event \ var $uidatepicker = $.fn.datepicker; \ $.fn.datepicker = function(options) { \ $(this).trigger("datepickercreate"); \ options.create && options.create(); \ return $uidatepicker.call(this, options); \ }; \ }}}1330680456695036
_comment1: The lack in documentation was unfortunately due to an issue with our current documentation system, which lists all options and methods and events provided by the widget factory, including (in this case) the create event. Both the datepicker and the documentation system are being entirely rewritten, which will solve the issue from both sides. In the meantime, I've created a custom template just for datepicker that leaves out the create event (as it is not implemented, and likely won't be until rewritten to use the widget factory) and also added a note in its place saying it's a known issue that the create event is not triggered. This change is live at http://docs.jquery.com/UI/Datepicker#events and will be live on http://jqueryui.com/demos/datepicker#events when the next stable release goes up. \ \ > What makes this even worse is the fact that the beforeShow event does not fire either when using the datepicker inline \ \ beforeShow doesn't make any sense for an inline datepicker because it's always visible. Hence, there is no point before which it is shown. So this is by design. \ \ Anyway, here's a workaround for the missing create event: \ {{{ \ // Workaround for missing datepickercreate event \ var $uidatepicker = $.fn.datepicker; \ $.fn.datepicker = function(options) { \ $(this).trigger("datepickercreate"); \ options && options.create && options.create(); \ return $uidatepicker.apply(this, arguments); \ }; \ }}}1330680528333393
_comment2: The lack in documentation was unfortunately due to an issue with our current documentation system, which lists all options and methods and events provided by the widget factory, including (in this case) the create event. Both the datepicker and the documentation system are being entirely rewritten, which will solve the issue from both sides. In the meantime, I've created a custom template just for datepicker that leaves out the create event (as it is not implemented, and likely won't be until rewritten to use the widget factory) and also added a note in its place saying it's a known issue that the create event is not triggered. This change is live at http://docs.jquery.com/UI/Datepicker#events and will be live on http://jqueryui.com/demos/datepicker#events when the next stable release goes up. \ \ > What makes this even worse is the fact that the beforeShow event does not fire either when using the datepicker inline \ \ beforeShow doesn't make any sense for an inline datepicker because it's always visible. Hence, there is no point before which it is shown. So this is by design. \ \ Anyway, here's a workaround for the missing create event: \ {{{ \ // Workaround for missing datepickercreate event \ var $fndatepicker = $.fn.datepicker; \ $.fn.datepicker = function(options) { \ $(this).trigger("datepickercreate"); \ options && options.create && options.create(); \ return $fndatepicker.apply(this, arguments); \ }; \ }}}1330680674478046
_comment3: The lack in documentation was unfortunately due to an issue with our current documentation system, which lists all options and methods and events provided by the widget factory, including (in this case) the create event. Both the datepicker and the documentation system are being entirely rewritten, which will solve the issue from both sides. In the meantime, I've created a custom template just for datepicker that leaves out the create event (as it is not implemented, and likely won't be until rewritten to use the widget factory) and also added a note in its place saying it's a known issue that the create event is not triggered. This change is live at http://docs.jquery.com/UI/Datepicker#events and will be live on http://jqueryui.com/demos/datepicker#events when the next stable release goes up. \ \ > What makes this even worse is the fact that the beforeShow event does not fire either when using the datepicker inline \ \ beforeShow doesn't make any sense for an inline datepicker because it's always visible. Hence, there is no point before which it is shown. So this is by design. \ \ Anyway, here's a workaround for the missing create event: \ {{{ \ // Workaround for missing datepickercreate event \ (function( $ ) { \ var $fndatepicker = $.fn.datepicker; \ $.fn.datepicker = function( options ) { \ $( this ).trigger( "datepickercreate" ); \ options && options.create && options.create(); \ return $fndatepicker.apply( this, arguments ); \ }; \ })( jQuery ); \ }}}1330681389618003

The lack in documentation was unfortunately due to an issue with our current documentation system, which lists all common options and methods and events provided by the widget factory, including (in this case) the create event. Both the datepicker and the documentation system are being entirely rewritten, which will solve the issue from both sides. In the meantime, I've created a custom template just for datepicker that leaves out the create event (as it is not implemented, and likely won't be until rewritten to use the widget factory) and also added a note in its place saying it's a known issue that the create event is not triggered. This change is live at http://docs.jquery.com/UI/Datepicker#events and will be live on http://jqueryui.com/demos/datepicker#events when the next stable release goes up.

What makes this even worse is the fact that the beforeShow event does not fire either when using the datepicker inline

beforeShow doesn't make any sense for an inline datepicker because it's always visible. Hence, there is no point before which it is shown. So this is by design.

Anyway, here's a workaround for the missing create event:

// Workaround for missing datepickercreate event
(function( $ ) {
  var $fndatepicker = $.fn.datepicker;
  $.fn.datepicker = function( options ) {
    $( this ).trigger( "datepickercreate" );
    options && options.create && options.create();
    return $fndatepicker.apply( this, arguments );
  };
})( jQuery );

Changed March 02, 2012 11:17AM UTC by raphinesse comment:5

Nice to hear that the documentation issue is being addressed. And thank you for the create event workaround. It might come in handy for someone sometime. Unfortunately it turned out that, with or without the create event, I can't prevent the datepicker from setting the current date active when no other is selected.


beforeShow doesn't make any sense for an inline datepicker because it's always visible. Hence, there is no point before which it is shown.

One ''could'' argue that the point before which an inline datepicker is shown is roughly the same as the point where the create event should fire.

Changed July 10, 2012 04:48PM UTC by scottgonzalez comment:6

#8434 is a duplicate of this ticket.

Changed October 03, 2012 03:15PM UTC by scottgonzalez comment:7

milestone: 1.next1.11.0

Changed October 03, 2012 03:17PM UTC by scottgonzalez comment:8

#6737 is a duplicate of this ticket.

Changed October 16, 2012 09:02PM UTC by petersendidit comment:9

status: newopen

Changed August 15, 2013 08:23AM UTC by lukepage comment:10

Is anyone working on this, or is it waiting to be picked up? If I wanted to help out with this, is there any documentation/design digrams or things I should know?

Changed August 15, 2013 09:50AM UTC by tj.vantoll comment:11

Replying to [comment:10 lukepage]:

Is anyone working on this, or is it waiting to be picked up? If I wanted to help out with this, is there any documentation/design digrams or things I should know?

Hi lukepage,

Switching to use the widget factory is part of a greater datepicker rewrite that has been in progress for some time now. There's some documentation on this wiki page, although it's a bit out of date.

Probably the easiest thing to do is checkout out the datepicker branch to see where it's at.

There's plenty to do and we would love to have help on the rewrite. Feel free to ping us in #jqueryui-dev on irc (I'm tj_vantoll), join our Wednesday meeting, or just comment again here and we can help you get started.

Changed September 11, 2013 07:35PM UTC by jzaefferer comment:12

milestone: 1.11.01.12.0

Moving this to the 1.12 milestone. Datepicker won't get done with the 1.11 timeframe (as lax as that may be).

Changed July 14, 2014 05:41PM UTC by scottgonzalez comment:13

keywords: → rewrite

Changed November 07, 2014 05:30PM UTC by scottgonzalez comment:14

milestone: 1.12.01.13.0

Changed January 10, 2015 10:10AM UTC by lukepage comment:15

Is anyone working on this already? I'm interested in picking it up and it seems a waste fixing any other date picker bugs till this is done.

Changed January 10, 2015 01:57PM UTC by scottgonzalez comment:16

The answer has not changed since the last time you asked that question, except that we're obviously much further along in the process.