Add form_date() to Form generation

So much to respond to here. I'll try to address all of the remarks.

#1.
I do not believe this is a duplicate of http://drupal.org/node/9371, unless we want to rule out any of the back-end data validation ideas that were mentioned in that task. My intention was to build one or more new HTML form functions, and not to make sweeping changes across how the core handles data input and validation. Right now it appears most validation is custom built into each module. So I think HTML form generation and form data validation are two different tasks, although very closely related. I can imagine a new architecture for form handling which would marry or join the two pieces, HTML and validation, but that would pretty much mean rewriting almost all of common.inc plus every module. I'm not qualified to do that in Drupal! :-) (I do however, do just exactly that in my proprietary application where this idea came from -- see #3 below.)

If you all still disagree, I'll be happy to close http://drupal.org/node/9371 and point a response here.

#2.
I'll be more than happy to update the profile module and anywhere else that would be appropriate. Removing code is always a happy task.

#3.
Unless we use dropdowns (see further discussion below) or Javascript, it will always be possible to enter an invalid date until Preview/Save causes the backend to validate it. However, using a single text field, instead of 3, means that dates can be entered in so many formats, one will never be able to validate them. With 3 fields, it's easy to validate each. As for appearance being ugly: (1) I can tweak the HTML a little bit, and with optional CSS styling, they can be made to look much better. This is, in fact, how I use this code in my applications. I use Drupal's common.inc, modified to run outside of Drupal and with my added date form function to drive a bunch of proprietary forms. They are extensively styled with CSS. One example can be seen here: http://www.visi.com/~chris/date.html (2) What is ugly to one person is not to another, so I am opposed to arbitrarily not implementing a feature just because some people think it is ugly.

I'm not sure I get all the rest of Gordon's points. Maybe he will clarify?

Let me just reiterate that there are too many valid date formats to allow the user to just type a date into a single text box. Just for starters: 2004-09-30, 2004-9-30, 2004.09.30, 2004.9.30, 9/30/04, 9/30/2004, 9-30-2004, and the always entertaining: 11/10/2004, 11-10-2004, 11.10.2004, 2004-10-11, etc.

#4.
And I hate dropdowns. Ok, I really don't but it is a valid but not winnable argument to prefer one or the other. For people who touch type and like to keep their hands on the keyboard, dropdowns are a pain in the neck. They also take more screen real estate, and are slower. I've got a lot of experience and background in designing user interfaces and human factors. It is unfortunately not a simple case of one being better than the other. I actually would prefer having both available if it can be done in some clean, efficient way.

The idea of parsing and figuring out what date is really meant from a single text box certainly sounds attractive on the surface, but there is just no way to know what a user means when he types 10/11/2004. Is that November 10 or October 11? Using a localized template and preg_replace means all users have to enter their dates in the same format, does it not?

I'm all in favor of KISS, believe me. After writing UI software for 27 years, KISS is my guiding principle in everything I do. Making users conform to one idea of how to enter dates is hostile to the users who like to do it in another format.

#5.
I agree dropdowns with month shortname are easier to read. I often write dates that way by hand, on paper and in computer text becaues of its clarity. If there is no way the powers that be will accept text boxes only, or text boxes and dropdowns, user or admin or programmer's choice, then I'll recode my patch to use dropdowns. But as I said before -- I personally hate them when filling in a form with multiple items because I'm typing on the keyboard and want to keep my hands there. I can make dropdowns work form the keyboard but they do not behave consistently. One has to stop and watch what is happening to make sure the value they wanted is the one selected, especially with numerics.

As for the (I'm guessing, because of the missing words, probably HTML that got filtered out by Drupal) using HTML input elements directly instead of the form_ calls: I found that in order to get the closest fit and best styling of the input fields, that it was necessary to do this. The extra wrapping divs around the form_ calls introduce extra white space between the elements. Beats me as to why -- I suspect it is a rendering bug in Firebird and MSIE on Windows (only places I have tested it).

** Lastly, if I can get a form_date patch accepted, I'm interested in and willing to create a form_time function and/or a combined date and time function if you all think they are worth doing.

It's true that 3 textboxes allow one to type the day value into the month and vice versa. In normal usage, there would be some kind of prompt or text indicating the correct order. In my application, I preset the value to "mm" and "dd" for the month and day respectively and the user then types over them. One could also put that information in the $description or as background images in the CSS, etc. However, I agree thiis is the best reason for using dropdowns.

As for Firefox allowing allowing you to select dropdown values by typing: no, Firefox fails in exactly the way I was referring to. Yes, you can type to get the value you want eventually, but it does not do so in a consistent way. Example: go to a day dropdown (1-31). Preset it to 1, change focus away and then change focus back (e.g. using tab) so that you come into the field as a normal user might, then imagine that you wanted to type "31" but accidentally typed "13". Now type 13 and then 31 without any other kepresses in an effort to fix what you typed. It will continue to display 13 even though you typed 31. Maybe that is a minor enough problem that most Drupal users are willing to live with it. In a data entry application this kind of nonsensical behavior is not acceptable.

As for the spacing issue -- as I said, there appears to be a bug. CSS will NOT fix it.

I don't like the 'drupal_'.$name.'_'.$type thing much either, but was trying to avoid namespace conflicts. Passing an array is a fine solution for the form variable names, but it then raises the question of what the name of the entire date item (all 3 dropdowns) is for CSS and HTML "label" purposes is.

It appears I'm in the minority on the text boxes vs. dropdowns issue, so I will revise the patch to use dropdowns and also look at adding an array of names.

I will also attempt to make a demo available to show various options and problems associated with them.

Question: when using dropdowns, what range should the year selection cover? For the profile module, the range is 1900 to 2050.

What if a module developer were creating a module for soemthing that contained dates further in the past, e.g. biographical information?

Should the year range be passed as an argument to form_date()?

Although in the Gregorian calendar, all years have 12 months with a fixed number of days, would we want to likewise allow the caller to pass in the allowed ranges for month and day?

Question: when using dropdowns, what range should the year selection cover? For the profile module, the range is 1900 to 2050.

What if a module developer were creating a module for soemthing that contained dates further in the past, e.g. biographical information?

Should the year range be passed as an argument to form_date()?

Although in the Gregorian calendar, all years have 12 months with a fixed number of days, would we want to likewise allow the caller to pass in the allowed ranges for month and day?

Here is another proposed patch. This one includes:

1. Dropdown lists instead of text boxes.

2. Calls to form_select() instead of raw HTML.

3. Optionally allows caller to specify the year range, defaults to -125/+50 years from today.

4. Container class "container-inline".

Open issues:

1. The $required parameter is only useful for styling/marking the element as required. Validating that it was filled in is of no use because dropdown lists always have a valid date, although not necessarily the right one.

2. There is no way to refer to the entire element of all 3 dropdowns together in CSS because there is no global name for them. Thus, there is no way to call _form_get_error() or _form_get_class() on the created date element.

Suggestions and advice on the above 2 issues would be appreciated.

Still need guidance on how to solve this open issue:

2. There is no way to refer to the entire element of all 3 dropdowns together in CSS because there is no global name for them. Thus, there is no way to call _form_get_error() or _form_get_class() on the created date element.

I'll take chx's remarks and rework the patch soon.

Thanks.

This feature is obviated by the 4.7 Forms API. A new issue for adding this kind of widget is open there, I believe. Don't have the number handy.