Opened 14 years ago

Closed 6 years ago

#4765 closed enhancement (patchwelcome)

DateTextBox: support isDisabledDate

Reported by: guest Owned by:
Priority: high Milestone: 1.13
Component: Dijit - Form Version: 0.9
Keywords: dateTextBox _Calendar isDisabledDate displayMonth Cc:
Blocked By: Blocking:

Description (last modified by bill)

I'm trying to use dijit.DateTextBox to allow users to select dates, but I need to disable weekends. If I use dijit._Calendar, I can set myCal.isDisabledDate =, but that doesn't work for a DateTextBox.

In talking with peller about this in #dojo, it was mentioned that it might be possible to add another option on the constraints to handle this.


Change History (20)

comment:1 Changed 14 years ago by Adam Peller

Milestone: 1.1
Owner: set to Adam Peller

we'd need to process this when the user enters text in the textbox and also pass it along to the calendar. let's consider in 1.1

comment:2 Changed 14 years ago by tk

Keywords: dateTextBox _Calendar isDisabledDate displayMonth added
Summary: Enable isDisabledDate for DateTextBoxEnable relevant attributes for _Calendar in DateTextBox

Modified this a bit.. its a little bigger tha isDisabledDate, so we dont get multiple tickets opened up... I'll widen the scope of this one. We also need to support displayMonth so you can supply a default month to show w/o supplying a default value.

comment:3 Changed 14 years ago by Adam Peller

what's the use case for this? This is a slippery slope that could lead us right back to dojo.widget.DropDownDatePicker? :-)

comment:4 Changed 14 years ago by tk

User experience... current DateTextBox? defaults to current year/month right? DOB field for someone in 1978 has to click back 30 times almost to get to just the right year... but if the site required say a DOB that puts someone at a certain age minimum you can default the displayMonth to that year atleast minimizing user clicks, increasing user experience...

Of course there is also the fact that since _Calender is a base widget, not a full blown public widget, users expect the BARE functionality of that when they see it... which means we should atleast forward those properties to it when used in a compound widget.

comment:5 Changed 14 years ago by Adam Peller

either way, I think it's a bad experience for entering birthdays. This widget is not well tuned to that sort of thing. So you're saying some college kid is going to have a great user experience, and a senior citizen is still going to have to click >40 times? I'm not convinced :-P

Simply forwarding properties works sometimes, but not always. For example, isDisabledDate won't work right if it's just forwarded to _Calendar. The text input validation also needs to know about it.

comment:6 Changed 14 years ago by tk

Its an example. The biggest thing is if we are using it, the users are going to expect its minimal functionality to exist... otherwise, why is it even there?

comment:7 Changed 14 years ago by Adam Peller

Milestone: 1.12.0

comment:8 Changed 14 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:9 Changed 14 years ago by Adam Peller

Description: modified (diff)
Summary: Enable relevant attributes for _Calendar in DateTextBoxEnable isDisabledDate for DateTextBox

putting this back in its original scope. tk, please feel free to discuss other attributes or the general case in separate tickets. It's not the same thing, IMO.

comment:10 Changed 13 years ago by bill

Milestone: 1.31.4
Summary: Enable isDisabledDate for DateTextBoxDateTextBox: support isDisabledDate

comment:11 Changed 12 years ago by bill

Milestone: 1.4future

comment:12 Changed 12 years ago by jer

I'm having same problem. Had to write this cruft to keep constraints handling and add my dates handling:

		isDisabledDate: function(/*Date*/date, /*String?*/ locale)
			//my handler

			return true;
		_open: function() {
			dojo.mixin(this._picker, {
				parent: this,
				isDisabledDate: function(/*Date*/ date) {
					var textBox = this;
					var compare =;
					var constraints = textBox.constraints;
					var test =
						constraints && (constraints.min && (compare(constraints.min, date, textBox._selector) > 0) ||
						(constraints.max && compare(constraints.max, date, textBox._selector) < 0)); 
					return test || this.parent.isDisabledDate(date);

I think that's enough to pull original isDisabledDate definition from _open() to separate method - e.g. handleConstraints() - and add isDisabledDate() as extension point and finally pass to popup function like this (parent is mixin'ed context)

function (date) {
	return this.parent.handleConstraints() || this.parent.isDisabledDate()

comment:13 Changed 11 years ago by Adam Peller

Owner: Adam Peller deleted

assigning all Dijit bugs to Bill

comment:14 Changed 11 years ago by bornmw

if someone fixes this please don't forget to apply fix to all the classes from dojox.form.DateTextBox?

comment:15 in reply to:  12 Changed 11 years ago by bornmw

Replying to jer:

I'm having same problem. Had to write this cruft

Thanks! Had to modify a little for 1.6

dojo.declare("MyDateTextBox", dijit.form.DateTextBox, {
	openDropDown: function() {
		this.dropDown.isDisabledDate = function(o) {
			return true;

Is it so hard for devs to pull isDisabledDate out as jer suggested 16 months ago?

How long will it take to review and integrate a patch if we send one?

comment:16 Changed 11 years ago by bill

Component: DijitDijit - Form
Description: modified (diff)
Owner: set to Douglas Hays

comment:17 Changed 9 years ago by mightytikigod

Maybe I'm not understanding this issue, but doesn't overriding the rangeCheck method of a dijit/form/DateTextBox accomplish the desired result? The embedded calendar object just calls !rangeCheck() and returns it as the result of isDisabledDate().

So the solution to the stated problem would just be:

dojo.declare("MyDateTextBox", dijit.form.DateTextBox, {
	rangeCheck: function(date,constraints) {
		var day=date.getDay();
		return ((day!==0) && (day != 6));

comment:18 Changed 8 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:19 Changed 8 years ago by Douglas Hays

Status: assignedopen

comment:20 Changed 6 years ago by dylan

Milestone: future1.12
Resolution: patchwelcome
Status: openclosed

If someone wants to add something besides rangeCheck, please create a pull request. Closing as patchwelcome.

Note: See TracTickets for help on using tickets.