> : I have a date form field which I have attempted to
> : validate using CF's validate="date"
> :
> : Which should allow mm/dd/yyyy but it also allows
> : mm/dd/yyy
> :
> : I tried to work around this by setting my validate
> : to regular_expression with a pattern of
> : ^\d\d\/\d\d\/\d\d\d\d$ which works perfect except
> : for the fact that I also want this to allow nulls.
\d isn't a character class in CF 5 -- it's a new thing in regex for CFMX. So
I'm baffled as to how \d works if you're using CF 5...
> Does anyone have a regular expression that will check
> for mm/dd/yyyy and allow nulls?
what exactly is a null in this context? CF doesn't have nulls. At least it
didn't in CF5 and prior.
> docs state that the validate="date" only accepts
> mm/dd/yyyy but the example on the docs validates
> against mm/dd/yy I know this is a valid date.
> Just pointing this out because the docs are wrong,
> and I did not want to see RTFM in any replies I
> may get. Also this has to be done on the client
> side. I'm using CF5 for this. Docs came from DMX.
I don't remember if CF 5 allows regex to validate input fields (I avoid
cfform generally). If so you'll have to fall back to ranges and/or the posix
character class [:digit:] from cf5 which will be CF 5/MX compatible for when
you migrate to MX. Using a more complex regex will also allow you to
recognize a date value more accurately, for instance, the value for month
must be (0[1-9]|1[0-2]) whereas the value for date must be
(0[1-9]|[12][0-9]|3[0-1]) -- granted, this doesn't account for the precise
number of days in the month or leapyear, etc. but it will often tell you if
the month and day have been reversed.
^(0[1-9]|1[0-2])\/(0[1-9]|[12][0-9]|3[0-1])\/([1-2][09][0-9]{2,2})$
longer, but more precise...
Also -- if you need to do a lot of client-side validation, you might check
out the qForms open-source API http://www.pengoworks.com ... It has a
validateDate() function that should work the way you want/need it to, plus a
lot of other really nice features.
> : Maybe someone could explain why the validate="date"
> : allows : mm/dd/yyy I don't think that is a valid date,
> : am I wrong?
Yep, it's a date... 1/1/1 is a date (presumably the date of christ's birth
or resurrection -- not sure, I don't know why we reordered our callendar
after him. In any event, then presumably 1/1/10 and 1/1/100 are also dates
-- validate="date" (i'm not looking at the docs) may or may not require
preceding zeroes. -- or it could be that they intended it to require
preceding zeroes and it is a bug, though I remember a while back reading in
the doc's for CF 3 that only 2 digits were required (with certain
assumptions about the century based on those 2 digits). So if you added a
3rd digit, that would just qualify the century.
s. isaac dealey 954-776-0046
new epoch http://www.turnkey.to
lead architect, tapestry cms http://products.turnkey.to
tapestry api is opensource http://www.turnkey.to/tapi
certified advanced coldfusion 5 developer
http://www.macromedia.com/v1/handlers/index.cfm?ID=21816
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
This list and all House of Fusion resources hosted by CFHosting.com. The place for
dependable ColdFusion Hosting.
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
