Hi Adam, thanx for your input. >> It's in the spec that there has to be only one date-data-entry control?
yes, defiantly. The three select method is seen as cumbersome and ugly, esp since these people are power users with strong data entry skills. While you could mention lots of sites that use the three selects I could also counter that with other sites. Ultimately, the customers and the boss want it that way and I can see their point. For them it's quick for data entry and for me it's a simple idea to make work. Just because the language (ie CF) has a problem getting the LS format correct shouldn't be a reason to change a design. In fact this whole exercise is to remove date formatting from CF as much as possible since we have can't trust it to get it right between dd/mm/yyyy and mm/dd/yyyy. >> If a client of mine was peddling the idea of having a date input that *has* to take yyyymmdd as user input, I'd be arguing long and hard. you mis-understand. the user is ignorant any other formats other than their native one (although if we all used the ISO format in day-to-day use it would be more "International" and ... (I won't go there about American imperialism, although it's tempting!) > we use javascript > to convert that to (in this case yyyy-mm-dd*) as well as client side > validation. >> Oh, so you *are* taking the date apart and putting it back together again. no, as I said before, at that point, the app knows it's an aussie user and therefore any dates will be manually entered as either "dd/mm/yyyy" or "ddmmyyyy". the JS validation checks for valid dates and, if "ddmmyyyy", adjusts the display to "dd/mm/yyyy" (ie adds delims). What I'm working on is the JS also (at the same time ie: onBlur()) stores that date as "yyyy-mm-dd" in a hidden field. This is the one that gets processed. while I do concede the JS string manip might be tearing the date apart to do this (can't remember), the diff between what you suggest and what we do is 3 form fields to process Vs one and 3 controls for the user to access Vs one. and finally , this is not just for one little date field on one page. This particular app has nearly 500 page "views" (really final HTML presentation) that we've spec'ed so far and at least 30% of them have at least one date control. We're just wanting to introduce a common standard throughout so when dates collide (eg inserts into a db), the results are predictable. cheers barry.b --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
