Dates are not just text. They reached the status of a standalone data type a while ago. Dates are also a common presence in many input forms, for calendaring, scheduling, contacts, customer care applications. In Windows applications, we have had a date-picker common control since Windows 95. It's a drop-down control with two views—single-line date or expanded, navigable calendar. For desktop applications, picking up a date in a user-friendly manner is a closed problem. Period. What about the Web, instead?
For too many years, and in too many applications, you enter dates as plain text. The formatting is kind of optional and left to the good will of developers. In most cases, users receive some feedback (e.g., tooltips) on how dates are expected to be and then the code-behind class hopefully takes care of parsing the entered text into a date object. As you can imagine, if a misunderstanding occurs on the format, the final date can be something different. For example, "4-5-2007" indicates the 4th of May in the common European format, but the 5th of April in the US standard format. You know the story.
In ASP.NET, you have a Calendar control that acts as a date picker control. It produces a table-based markup that displays all days in the specified month, plus a few days in the previous and next month. It can render weekend days with an alternate style and can optionally allow navigation to find and select the right date. Properly configured, the control can also output non-selectable markup and can be used to indicate a particular input date in the context of a calendar.
The Calendar control supports a few different views (day, month, year), but none that let you enter a date by typing and then expand to view the selected day in the calendar. Is this a problem? It is not a "functional" problem in the sense that you can still pick up and select any date correctly. It has more of an "experience" problem in the sense that letting users choose between typing and selecting makes the whole form more user friendly. To switch between these two views—a collapsed, textbox-like view and a classic, calendar view—you need some script code. And the ASP.NET classic Calendar control doesn't support this feature.
The classic ASP.NET Calendar control, though, suffers from another important software disease—markup obesity. It can output about 9 KB of markup because it's full of tables, cells, rows, anchors, styles, not to mention raw text. Even with the viewstate turned off, the bytes moved for each postback that involves a calendar is significant. In addition, the classic ASP.NET Calendar fires a postback for each click. The user selects a date? The Calendar posts back. The user navigates a month forward? The Calendar posts back. In a month-based view, the user needs to select a date of two years before? The Calendar requires up to 24 postbacks.
As you can see, there a number of issues with the ASP.NET Calendar control, whose more appropriate name would probably have been DatePicker. Especially in the context of AJAX applications, I heartily recommend that you get a commercial control (or one of the excellent shareware/open-source controls available out there) or, at the very minimum, use the Calendar extender from the AJAX Control Toolkit. The Calendar extender is a piece of code that extends the capabilities of a regular text box and pops up a table-based calendar (very similar to the output of the ASP.NET Calendar control), but entirely client-side.
Picking up a date in ASP.NET and AJAX forms is a common task. Picking up the right tool is a must for smart developers.
