[jQuery] ui.datepicker complaints

[jQuery] ui.datepicker complaints


(warning - long post)
I need to vent. But I don't mean to belittle any of the efforts that
have gone into the library...
I have two major complaints about the ui.datepicker. These are enough
of a pain in the rear to me that I am more likely to use alternative
options (and lets face it, there's a bunch of em out there)...
1) The function interface has changed 3 times over 3 versions of the
library. For new projects this is not an issue. But for existing
projects, it means that replacing the library with a newer version (to
get all the latest features/bug fixes) will break existing code. The
end result is you either a) don't upgrade, or b) are forced to "fix"
your code to work with the new tool. For a single page, who cares. For
complex applications with multiple pages this is VERY significant.
From the docs:
Since v3.4 - in v3.3 you would use the
$(...).datepicker.getDatepickerDate function and in earlier versions the
$.datepicker.getDateFor function.
In my case, I have a single page that has approx 10 of the datepickers
that appear at different times (modal dialogs). These have all been
tweaked to address complaint 2 below. Which means I'm looking at
between 5 and 10 hours of coding just to use a new version of the library.
solution: Step back, consider the use cases, define the interfaces to
meet those use cases. THEN WRITE THEM IN STONE. Do not change function
interfaces.
I understand WHY these changes happened (application of the plugin
"pattern", namespace issues, etc.). But really, this is just annoying.
2) The default date should be displayed in the corresponding text box
when the control is initialized. Or at the very least have an option to
indicate this. The specified dateFormat (or default format) should be used.
My apps do date sensitive things, which means I'm doing date
calculations. Simply setting the value of a text box to a known string
is not good enough. I need to be absolutely confident that the actual
date object of the datepicker is being used.
Recent versions of the datepicker have the defaultDate parameter. This
value seems to be utterly useless in determining the default date of a
datepicker from code. For example:
$("#datebox").datepicker({
defaultDate: -1,
dateFormat: "d M yy"
});
alert($("#datebox").datepicker("getDate"));
- the alert returns "null"
- or in some cases, if you delay before showing the alert you might get
the current date - not the "defaultDate" specified.
The defaultDate seems to only be used to highlight the "defaultDate"
when the dialog is displayed. Opening and closing the dialog without
selecting a date does not set a date (which stands to reason). Opening
the dialog, and selecting a date DOES set the date, and the alert would
respond properly. But that totally defeats the purpose (IMO) of a
default date.
Because the getDate fails, there is no other option but to manually set
the date value. This means the logic that should already be available
with the "defaultDate: -1" setting now has to be set manually:
var temp = new Date();
$("#mydatebox").datepicker("setDate",
new Date(temp.getFullYear(), temp.getMonth(), temp.getDate() - 1);
);
$("#mydatebox")
.val(
$.datepicker.formatDate(
"d M yy",
$("#mydatebox").datepicker("getDate")
)
);
(having to do this code just to show the current value of the datepicker
seems ridiculous...)
The obvious response is "just set the text of the text box to the
desired date". Nope, I'm doing date calculations, and need the
datepickers to be set properly. I just so happen to be displaying the
value of the datepicker to my users - but that value MUST be synched.
The user may or may not change the date, so I need the date value of the
datepicker. The one it is supposed to know about to begin with.
---------
Perhaps this default date thing will see it's way into the next version.
Hopefully the function interfaces do not change.
But these two points are enough for me to begin looking at the other
options. And checking their history to see how often the interfaces change.
</rant off>
As a developer, I fully understand why things happen the way they do,
and respect the choices the devs have had to make. Hopefully this is
taken as constructive comments - it's not meant as a bash. But, well, I
feel a little better now.. :)
- Disclaimer - If I have missed something in the docs, then I humbly
apologize and submit myself to a thousand virtual lashes. (But the docs
are lacking in details too in some places. Perhaps when I get some free
time, I'll try to add some detail.)
Shawn