ui.Datepicker has no public functions for querying whether a date is selectable
http://forum.jquery.com/topic/ui-datepicker-s-unselectable-rules-now-applicable-to-text-input-as-well
I had to write a custom validation method for Datepicker's input fields that made it possible for manually entered dates to be validated against the same rules it uses to determine selectable dates. The worst part of this was dredging through $.datepicker's internal object structure to figure out how to externally reference the data stored in each datepicker instance, followed by finding the logic buried inside the render code.
In the end it consisted of copying and rewriting about ten lines of Datepicker's own code.
The main reason this was a PITA was because the actual logic (for determining whether a date is selectable or not) is fused to the lowest level render code and only run as each table cell is being generated. Even though this logic is run 31 times while drawing the calendar, it's apparently not worthy of a function (or worse, someone believes calling it will degrade performance).
Had it been accessible as a function, the custom validator method would have been one line of code, and unlikely to use internal methods and variables whose names might change over time.
I'm thinking something like getSelectable for a purely boolean response:
"classes" to return the classes associated with the TD element for a more finely grained description that allows for multiple contexts (in our case, one of the functions we put into beforeShowDay highlights today, tomorrow and the next day with a custom class and a tooltip, but leaves them selectable):
"textNode" would return a reference to the actual node containing the date text:
The first suggestion would make it much easier to repurpose the complex logic passed to the datepicker. The second two would handle developers being able to query more detailed information about a specific date.
I had to write a custom validation method for Datepicker's input fields that made it possible for manually entered dates to be validated against the same rules it uses to determine selectable dates. The worst part of this was dredging through $.datepicker's internal object structure to figure out how to externally reference the data stored in each datepicker instance, followed by finding the logic buried inside the render code.
In the end it consisted of copying and rewriting about ten lines of Datepicker's own code.
The main reason this was a PITA was because the actual logic (for determining whether a date is selectable or not) is fused to the lowest level render code and only run as each table cell is being generated. Even though this logic is run 31 times while drawing the calendar, it's apparently not worthy of a function (or worse, someone believes calling it will degrade performance).
Had it been accessible as a function, the custom validator method would have been one line of code, and unlikely to use internal methods and variables whose names might change over time.
I'm thinking something like getSelectable for a purely boolean response:
- var selectable = $(this).datepicker.properties(date,"selectable");
"classes" to return the classes associated with the TD element for a more finely grained description that allows for multiple contexts (in our case, one of the functions we put into beforeShowDay highlights today, tomorrow and the next day with a custom class and a tooltip, but leaves them selectable):
- var classes = $(this).datepicker.properties(date,"classes");
"textNode" would return a reference to the actual node containing the date text:
- var container = $(this).datepicker.properties(date,"textNode");
The first suggestion would make it much easier to repurpose the complex logic passed to the datepicker. The second two would handle developers being able to query more detailed information about a specific date.
Topic Participants
andrew.roazen
kbwood.au
ajpiano