Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Email Validation

Re: Email Validation

From: Frank <fvanbortel_at_netscape.net>
Date: Wed, 09 Apr 2003 22:17:07 +0200
Message-ID: <3E947FC3.6000603@netscape.net>


Paul Brewer wrote:
> "DA Morgan" <damorgan_at_exxesolutions.com> wrote in message
> news:3E92EF08.278FC935_at_exxesolutions.com...
>

>>Wayne Hinch wrote:
>>
>>
>>>Daniel,
>>>
>>>If i alter this table in this way how can i program it on the client
>>

> side
>
>>>(forms)? Because if i don't do anything on the client side it will only
>>>crash won't it?
>>>
>>>Wayne
>>>
>>>"DA Morgan" <damorgan_at_exxesolutions.com> wrote in message
>>>news:3E91A211.9695AB12_at_exxesolutions.com...
>>>
>>>>Wayne Hinch wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I am trying to validate an email which a user will enter, how do I
>>>>

> go
>
>>>about
>>>
>>>>>to do this? I would like to trap for an @ and a . in the text field
>>>>

> on a
>
>>>>>form which is being programmed in Forms 6.0.
>>>>>
>>>>>Any help will be much appreciated.
>>>>>
>>>>>Wayne
>>>>
>>>>Use a check constraint on the underlying table.
>>>>
>>>>ALTER TABLE person
>>>>ADD CONSTRAINT cc_person_email_address
>>>>CHECK (per_email_address LIKE '_%@_%._%');
>>>>
>>>>Data constraints belong in the table, not the form.
>>>>
>>>>Daniel Morgan
>>>>
>>>
>>What Niall said.
>>
>>In general ... all validation should be on the server rather than in the

>
> form.
>
>>Doing this has several advantages.
>>
>>1. Easier coding and maintenance.
>>2. No circumvention via connection through other tools.
>>3. Leaner forms meaning faster load time.
>>4. Leaner forms meaning less network traffic.

>
>
> Daniel,
>
> In the days of two-tier, the only conclusion I ever came to was that
> validation should be in both places:
>
> On the server, as a 'goalkeeper', to preserve the integrity of the data come
> what may, and to allow any client app to address the data, provided it uses
> the 'API' (i.e. 'no circumvention through other tools' as you say).
>
> On the client as well, wherever practicable, so as to present a
> user-friendly interface.
>
> Redundant client-side coding, I agree, but my view was that this was the
> least evil option.
>
> Since then of course, newer apps are three-tier. This presents a new set of
> challenges, but IMHO the fundamental considerations are the same.
> Unfortunately however, with everything being third party apps these days, in
> my (admittedly limited) experience, we seem to have less and less
> involvement in design on the server side, with all the work being done
> through the app.
>
> It seems to me in a number of respects, that this is actually a backward
> step.
>
> Comments welcome.
>
> Regards,
> Paul
>
>
>

Agree completely. But it should be goalkeeper (r): <quote>
GOALKEEPER is the most effective close-in-weapon system available today. Its superior search radar leaves no target undetected. Its highly accurate I- and K-band tracking radar gives pinpoint precision. Its high-performance 30 mm gun leaves no room for doubt about the outcome of any engagement.
</quote>
Now all I want is a tampering user ;-)

-- 
Regards, Frank van Bortel
Received on Wed Apr 09 2003 - 15:17:07 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US