validate fields before POST

Hi again,

What's the best I can do to validate fields like date before send my datas. thx

On 09 Jan 2005 13:30:50 GMT, Alexandre <nnnnn@msn.com> wrote:

>What's the best I can do to validate fields like date before send my datas. thx

You can't do anything in PHP before the form is sent. Try a Javascript group
if you want client-side pre-submission validation.

You can't rely on client-side code being run, however, so you must repeat the
validation in PHP after the POST is received but before you use it to do
anything.

To validate dates, functions such as strtime or preg_match would be useful.

http://php.net/strftime
http://php.net/preg_match

Dates can be a pain to validate due to issues with ambiguous date formats;
e.g. is 01/02/03 :

(a) 1st February 2003 (dd/mm/yy)
(b) 2nd January 2003 (mm/dd/yy)
(c) 3rd February 2001 (yy/mm/dd)

So you need to make it clear on your page which format is accepted and/or
separate out day/month/year fields into separate input elements.

--
Andy Hassall / <andy@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

Andy Hassall wrote:
>
> Dates can be a pain to validate due to issues with ambiguous date formats;
> e.g. is 01/02/03 :

Just a tip about working with dates; I find it very convenient to put
them up as select-fields with one list for each of day, month and year -
or at the very least separate text-inputs for each - and then validate
it using a javascript date-validation function on the clientside and
checkdate() on the serverside. Making a top option with a title relevant
to the type of value you want (with an empty _value_, of course) makes
it very difficult for people to submit an invalid date (unless they
really want to get it wrong, or if they're incredibly stupid - the
latter in which case they'd probably never figure out how to visit a
website anyway).

Allowing people to type in the date freeform in one input-field is a Bad
Idea(tm) - you'd be surprised how many various creative date-submissions
I've gotten from fields like that ;)

Validating e-mail addresses however - now there's a pain if I ever knew
one ;)


Roy W. Andersen
--
ra at broadpark dot no / http://roy.netgoth.org/

"Hey! What kind of party is this? There's no booze
and only one hooker!" - Bender, Futurama

Hello,

on 01/09/2005 01:38 PM Roy W. Andersen said the following:
> Andy Hassall wrote:
>>
>> Dates can be a pain to validate due to issues with ambiguous date
>> formats;
>> e.g. is 01/02/03 :
>
> Just a tip about working with dates; I find it very convenient to put
> them up as select-fields with one list for each of day, month and year -
> or at the very least separate text-inputs for each - and then validate
> it using a javascript date-validation function on the clientside and
> checkdate() on the serverside. Making a top option with a title relevant
> to the type of value you want (with an empty _value_, of course) makes
> it very difficult for people to submit an invalid date (unless they
> really want to get it wrong, or if they're incredibly stupid - the
> latter in which case they'd probably never figure out how to visit a
> website anyway).
>
> Allowing people to type in the date freeform in one input-field is a Bad
> Idea(tm) - you'd be surprised how many various creative date-submissions
> I've gotten from fields like that ;)

Right, that is what the date plug-in input of this class does. It
generates select inputs and all the necessary client site Javascript to
complement the server side validation of the dates. You can also specify
either a start and ending date range to be taken in account in the
validation.

http://www.phpclasses.org/formsgeneration

Here is a screenshot of several types of forms generated by the class
including one with dates:

http://download.freshmeat.net/screenshots/4170.gif


> Validating e-mail addresses however - now there's a pain if I ever knew
> one ;)

The class above can take care of that with regular expressions but if
you want to perform a deeper SMTP based validation, there is also this
class that you can use in conjunction:

http://www.phpclasses.org/emailvalidation


--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

Thx for all of your response :)

Manuel Lemos <mlemos@acm.org> wrote:
>Hello,
>
>on 01/09/2005 01:38 PM Roy W. Andersen said the following:
>> Andy Hassall wrote:
>>>
>>> Dates can be a pain to validate due to issues with ambiguous date
>>> formats;
>>> e.g. is 01/02/03 :
>>
>> Just a tip about working with dates; I find it very convenient to put
>> them up as select-fields with one list for each of day, month and year -
>> or at the very least separate text-inputs for each - and then validate
>> it using a javascript date-validation function on the clientside and
>> checkdate() on the serverside. Making a top option with a title relevant
>> to the type of value you want (with an empty _value_, of course) makes
>> it very difficult for people to submit an invalid date (unless they
>> really want to get it wrong, or if they're incredibly stupid - the
>> latter in which case they'd probably never figure out how to visit a
>> website anyway).
>>
>> Allowing people to type in the date freeform in one input-field is a Bad
>> Idea(tm) - you'd be surprised how many various creative date-submissions
>> I've gotten from fields like that ;)
>
>Right, that is what the date plug-in input of this class does. It
>generates select inputs and all the necessary client site Javascript to
>complement the server side validation of the dates. You can also specify
>either a start and ending date range to be taken in account in the
>validation.
>
>http://www.phpclasses.org/formsgeneration
>
>Here is a screenshot of several types of forms generated by the class
>including one with dates:
>
>http://download.freshmeat.net/screenshots/4170.gif
>
>
>> Validating e-mail addresses however - now there's a pain if I ever knew
>> one ;)
>
>The class above can take care of that with regular expressions but if
>you want to perform a deeper SMTP based validation, there is also this
>class that you can use in conjunction:
>
>http://www.phpclasses.org/emailvalidation
>
>
>--
>
>Regards,
>Manuel Lemos
>
>PHP Classes - Free ready to use OOP components written in PHP
>http://www.phpclasses.org/
>
>PHP Reviews - Reviews of PHP books and other products
>http://www.phpclasses.org/reviews/
>
>Metastorage - Data object relational mapping layer generator
>http://www.meta-language.net/metastorage.html
>

.oO(Roy W. Andersen)

>Andy Hassall wrote:
>>
>> Dates can be a pain to validate due to issues with ambiguous date formats;
>> e.g. is 01/02/03 :
>
>Just a tip about working with dates; I find it very convenient to put
>them up as select-fields with one list for each of day, month and year -

From a usability standpoint I consider that one of the most annoying
things.

>or at the very least separate text-inputs for each

Slightly better, but still bad.

IMHO the best way is to simply use a single input field and parse that
on the server. Clearly state on the page what date format the user is
expected to use for his input.

>Allowing people to type in the date freeform in one input-field is a Bad
>Idea(tm) - you'd be surprised how many various creative date-submissions
>I've gotten from fields like that ;)

If your script can't handle it simply show an error page and ask the
user for correction. But your script should be able to parse at least
the most common formats.

>Validating e-mail addresses however - now there's a pain if I ever knew
> one ;)

Validating an e-mail address can't be done reliably at all, except for
sending a message and waiting for an answer.

Micha

Michael Fesser wrote:
> IMHO the best way is to simply use a single input field and parse that
> on the server. Clearly state on the page what date format the user is
> expected to use for his input.

Providing pulldown-boxes for each value does exactly that. Nothing is
stopping the user from typing it instead - if you type a value into a
pulldown that corresponds with a selectable value it'll get selected
(atleast in most browsers). Using tabindex to make sure tab takes the
user to the next field makes it even easier.

>>Allowing people to type in the date freeform in one input-field is a Bad
>>Idea(tm) - you'd be surprised how many various creative date-submissions
>>I've gotten from fields like that ;)
>
> If your script can't handle it simply show an error page and ask the
> user for correction. But your script should be able to parse at least
> the most common formats.

Seeing as the world consists of quite a few countries and languages, and
many countries usually have different ways of commonly writing dates
(especially when it comes to months, as it's just as common to type the
name - or part of it - as typing the number), I still prefer it to
restrict the format on the clientside so that both the user and the
server can be sure that what they submit is valid the first time around.
As a user I really dislike having to go back to a form to re-enter
values after submitting it. Most forms take care of the information so
you won't have to re-type it all, but a lot of the time certain fields
that you did fill in are blank on the second go. You can never be sure
what kind of form you're currently faced with, which means you'll have
to check the entire form again before submitting it the second time, or
run the risk of being presented with a new error-page telling you that
one or more values that you _did_ fill in the first time, was missing
the second time, and repeat ad-nauseum. I'll take a restricted
input-format any day over a mess like that, both as a developer and as a
user ;)

> Validating an e-mail address can't be done reliably at all, except for
> sending a message and waiting for an answer.

If the recipient chooses to not answer, then neither that is reliable ;)


Roy W. Andersen
--
ra at broadpark dot no / http://roy.netgoth.org/

"Hey! What kind of party is this? There's no booze
and only one hooker!" - Bender, Futurama

Roy W. Andersen wrote:

> Michael Fesser wrote:

> > IMHO the best way is to simply use a single input field and parse that
> > on the server.

That appears to be Jakob Nielsen's opinion too, so you're in
good company, Michael. (I'm afraid you'll have to excuse me
as I haven't been persuaded either way.)

> > Clearly state on the page what date format the user is expected to use
> > for his input.

I recommend the numerical representation of dates to accord
with ISO8061; e.g., [YYYY-MM-DD]. When writing content,
however, I would use words; e.g., [11 January 2005], which I
find more intuitive than [2005-01-11].

No matter how obvious you make it though, someone will by
and by fail to notice your expected format and enter the
date in a format they're accustomed to.

> Providing pulldown-boxes for each value does exactly that.

It slows down the entering of values and restricts what
values are entered. It's more restrictive, I agree, but Dr
Nielsen advises us to 'put the burden on the computer, not
the human: let users enter data in the format they prefer'.*

I can see the benefit of having three SELECT boxes clearly
labelled 'day', 'month', and 'year', where the day is
represented by one or two digits, the month by the name of
the month, and the year by four digits. For one, your form
handler could be much simpler.

> Nothing is stopping the user from typing it instead - if you type a
> value into a pulldown that corresponds with a selectable value it'll
> get selected (atleast in most browsers). Using tabindex to make sure
> tab takes the user to the next field makes it even easier.

Tabindexes seem redundant to me because the three SELECTs
should have no intervening fields in the display or in the
character stream.


* http://www.useit.com/alertbox/20031222.html
See also http://www.useit.com/alertbox/20001112.html

--
Jock