I have a datepicker with maxdate set as today. Here is how I defined it:
$('selector').datepicker({
yearRange: "c-100:+0",
maxDate: '+0d',
changeMonth : true,
changeYear : true,
showAnim:"fold"
});
The maxDate property works fine when the user selects from the datepicker ui. It shows all the future dates as disabled; however, datepicker allows the user to enter a date via the keyboard as well which is where the problem begins.
DatePicker even validates the value of manually entered text when the user presses enter (submits the form) but does not validate it when it is blurred and then the form is submitted; i.e., when the user comes out of the input box without pressing enter. This allows the date to be greater than the maximum date and can be submitted without showing an error.
I can make the text input read-only, but in that case user can not input the date via keyboard.
Since I am new to jquery, am I missing some property that would validate on blur?
It sounds like you are wanting to validate the Date Picker field to be a date in the past and that validation isn’t happening when the user is leaving the field. I’m not familiar enough with Date Picker to say that there is a validation method that you could specifically call when the user leaves the field with a date in the future, but you could fairly easily write your own validation routine for when the user leaves focus out of the Date Picker field.
Tested:
You could also validate the field on submit.
However, even with all these lovely protections in place, you cannot substitute these for validating on the server side. You should validate and provide proper error messages in the event the user circumvents the Javascript protections and submits the form with a date in the future. Hope that helps you.
Update: Here is a really interesting discussion about blur and focus in case you want to lock down the behavior of leaving the field with a future value. It may or may not be applicable to what you want to do/use.
Another thought is that in your error message, you might want to be as descriptive as possible in the types of date that should be input (YYYY-mm-dd) so users from different perspectives (mm/dd/yy or whatever) know why their input is getting rejected.