Hi,
I noticed this in my form submission and dont know why cfinput with
validation would show date as *{d '2009-02-12'} *whereas regular input would
show same value as* 02/12/2009* . See code below :
cfloop from=1 to=10 index=thisrow
cfinput type=text name=absence_date#thisrow# size=10 value=
Thanks,
Yes, but the big question is why cffrom cfinput would send date in that
format. Its not the first time I have i used cfinput. Date usually comes
across in standard date format.
Anyone???
Ajas Mohammed /
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we
Ajas,
This is my unconfirmed assertion. You have a validator type of type date,
which returns a string expression of a date object notation. My assertion
is that the validator type that you use will give you the data type on the
submission in its expressed format.
I changed your code to
Please tell me you mistyped perfect on purpose.
Please.
-dhs
Dean H. Saxe, CISSP, CEH
d...@fullfrontalnerdity.com
I have always strenuously supported the right of every man to his own
opinion, however different that opinion might be to mine. He who
denies another this right makes a slave
oyu stll no wut he ment... ;)
From: Dean H. Saxe d...@fullfrontalnerdity.com
To: discussion@acfug.org
Sent: Thursday, February 12, 2009 10:41:36 AM
Subject: Re: [ACFUG Discuss] weird cfinput vs input stuff. date is shown as {d
'2009-02-12'} vs 02/12/2009
As a matter of habit, I do not use the cfinput tags for validation however
the few times I've reviewed or modified code from other developers who
validate dates this way, this is the behavior I have seen.
In general, when I'm checking the date on the submit, I format it
anyway.
On Thu, Feb
Ajas,
I recommend reading the Adobe Live Docs concerning validation and form
fields. In the below snippet, you will see some curious behavior:
cfparam name=form.test default= /
cfdump var=#form#
cfform name=foo action=untitled2.cfm
cfinput type=text name=absence_date_1 size=10 value=
Plus its a completely useless client side check which needs to be
repeated server-side as well if you want any assurance that validation
was successful.
-dhs
Dean H. Saxe, CISSP, CEH
d...@fullfrontalnerdity.com
If liberty means anything at all, it means the right to tell people
what they
Thanks for all that, and fair enough. I missed the looping that was
appending more to the field name, but the info may still help someone.
And indeed what you've confirmed is what I would have said if you'd stopped
at your first paragraph: the onserver validation is causing CF to create the
Yes Charlie, but the server side is dependent upon receiving a flag
from the client to tell the server what to validate, if I recall
correctly. So effectively, it is still client-side validation.
-dhs
Dean H. Saxe, CISSP, CEH
d...@fullfrontalnerdity.com
I have always strenuously supported
And this is why I never use it unless the user has their knickers in a wad
to know about the error before they go to the next page. Even then I
usually don't bother (especially if they are on an intranet) because the
server validation is so quick they don't realize that they've just *gasp*
What of the AJAX approach to validation? You can pass the form to a server
side object for validation. Take the CF8 feature of cfajaxproxy.
Obviously, you can turn of JavaScript. As well as a client initiated
validation would not solely suffice.
Teddy R. Payne, ACCFD
Google Talk -
12 matches
Mail list logo
