Validating form input data

[stathis gotsis]

Hello everyone,

I am tying to come up with an elegant way to process some input data that
come from a form. When the user hits the 'Submit' button, i want the form to
appear again with the already entered valid data filled in and prompt the
user to re-enter the non-valid data. If all data is valid, i will forward to
an other .php page which enters the data into a database.

I tried to do this in the following way: the form always hits back on
itself, but when all data is valid i use the PHP:header() to redirect to the
data.php that performs the database insertion. The problem is that the data
is not available to data.php in the $_POST variable. How can i overcome this
problem? Any other subtle way to handle the whole thing? Any help
appreciated.

[David Haynes]

Re: Validating form input data

stathis gotsis wrote:[color=blue]
> Hello everyone,
>
> I am tying to come up with an elegant way to process some input data that
> come from a form. When the user hits the 'Submit' button, i want the form to
> appear again with the already entered valid data filled in and prompt the
> user to re-enter the non-valid data. If all data is valid, i will forward to
> an other .php page which enters the data into a database.
>
> I tried to do this in the following way: the form always hits back on
> itself, but when all data is valid i use the PHP:header() to redirect to the
> data.php that performs the database insertion. The problem is that the data
> is not available to data.php in the $_POST variable. How can i overcome this
> problem? Any other subtle way to handle the whole thing? Any help
> appreciated.
>
>[/color]

I would break the function a little differently.

1. Have a form (view) that is sensitive to $SESSSION. That is, it will
use the values in SESSION to populate any dynamic values to be displayed
in the form.
2. Have another process (controller) that:
a) processes $_POST or $_GET
b) if all is valid, does the insert/update and redirects to another
page (Your data has been saved.)
c) if all is not valid, populates the $SESSION with good values and
then redirects to the view form.

The whole thing is started by calling the controller. Since no data is
valid, it will redirect to the view.
The view then presents a form for filling in.
The user fills in the form and submits which then calls the controller.
The controller processes the form data and either updates/inserts it or
calls the view again.

If you encapsulate your database accesses into a class or set of classes
which are called from the controller, you will have a light-weight
implementation of a classic Model-View-Controller (MVC2) architecture.

-david-

[Manuel Lemos]

Re: Validating form input data

Hello,

on 04/30/2006 09:38 AM stathis gotsis said the following:[color=blue]
> Hello everyone,
>
> I am tying to come up with an elegant way to process some input data that
> come from a form. When the user hits the 'Submit' button, i want the form to
> appear again with the already entered valid data filled in and prompt the
> user to re-enter the non-valid data. If all data is valid, i will forward to
> an other .php page which enters the data into a database.
>
> I tried to do this in the following way: the form always hits back on
> itself, but when all data is valid i use the PHP:header() to redirect to the
> data.php that performs the database insertion. The problem is that the data
> is not available to data.php in the $_POST variable. How can i overcome this
> problem? Any other subtle way to handle the whole thing? Any help
> appreciated.[/color]

Nothing stops you from presenting the form and process it with the same
script.

You may want to take a look at this forms generation and validation
class that shows you how to do that. Additionally it generates your
forms with Javascript to validate the form also on the client site,
avoiding unnecessary server round trips just to tell the user the form
has invalid fields.

http://www.phpclasses.org/formsgeneration


--

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator

http://www.metastorage.net/

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

[stathis gotsis]

Re: Validating form input data

"David Haynes" <david.haynes2@ sympatico.ca> wrote in message
news:Mp25g.739$ jE6.350@fe17.us enetserver.com. ..[color=blue]
> stathis gotsis wrote:[color=green]
> > Hello everyone,
> >
> > I am tying to come up with an elegant way to process some input data[/color][/color]
that[color=blue][color=green]
> > come from a form. When the user hits the 'Submit' button, i want the[/color][/color]
form to[color=blue][color=green]
> > appear again with the already entered valid data filled in and prompt[/color][/color]
the[color=blue][color=green]
> > user to re-enter the non-valid data. If all data is valid, i will[/color][/color]
forward to[color=blue][color=green]
> > an other .php page which enters the data into a database.
> >
> > I tried to do this in the following way: the form always hits back on
> > itself, but when all data is valid i use the PHP:header() to redirect to[/color][/color]
the[color=blue][color=green]
> > data.php that performs the database insertion. The problem is that the[/color][/color]
data[color=blue][color=green]
> > is not available to data.php in the $_POST variable. How can i overcome[/color][/color]
this[color=blue][color=green]
> > problem? Any other subtle way to handle the whole thing? Any help
> > appreciated.
> >
> >[/color]
>
> I would break the function a little differently.
>
> 1. Have a form (view) that is sensitive to $SESSSION. That is, it will
> use the values in SESSION to populate any dynamic values to be displayed
> in the form.
> 2. Have another process (controller) that:
> a) processes $_POST or $_GET
> b) if all is valid, does the insert/update and redirects to another
> page (Your data has been saved.)
> c) if all is not valid, populates the $SESSION with good values and
> then redirects to the view form.
>
> The whole thing is started by calling the controller. Since no data is
> valid, it will redirect to the view.
> The view then presents a form for filling in.
> The user fills in the form and submits which then calls the controller.
> The controller processes the form data and either updates/inserts it or
> calls the view again.
>
> If you encapsulate your database accesses into a class or set of classes
> which are called from the controller, you will have a light-weight
> implementation of a classic Model-View-Controller (MVC2) architecture.[/color]

Thank you for your quick answer, i am heading towards the implementation you
suggested. Just another minor question: can i add an array variable to
SESSION? How can this be done?

[David Haynes]

Re: Validating form input data

stathis gotsis wrote:[color=blue]
> "David Haynes" <david.haynes2@ sympatico.ca> wrote in message
> news:Mp25g.739$ jE6.350@fe17.us enetserver.com. ..[color=green]
>> stathis gotsis wrote:[color=darkred]
>>> Hello everyone,
>>>
>>> I am tying to come up with an elegant way to process some input data[/color][/color]
> that[color=green][color=darkred]
>>> come from a form. When the user hits the 'Submit' button, i want the[/color][/color]
> form to[color=green][color=darkred]
>>> appear again with the already entered valid data filled in and prompt[/color][/color]
> the[color=green][color=darkred]
>>> user to re-enter the non-valid data. If all data is valid, i will[/color][/color]
> forward to[color=green][color=darkred]
>>> an other .php page which enters the data into a database.
>>>
>>> I tried to do this in the following way: the form always hits back on
>>> itself, but when all data is valid i use the PHP:header() to redirect to[/color][/color]
> the[color=green][color=darkred]
>>> data.php that performs the database insertion. The problem is that the[/color][/color]
> data[color=green][color=darkred]
>>> is not available to data.php in the $_POST variable. How can i overcome[/color][/color]
> this[color=green][color=darkred]
>>> problem? Any other subtle way to handle the whole thing? Any help
>>> appreciated.
>>>
>>>[/color]
>> I would break the function a little differently.
>>
>> 1. Have a form (view) that is sensitive to $SESSSION. That is, it will
>> use the values in SESSION to populate any dynamic values to be displayed
>> in the form.
>> 2. Have another process (controller) that:
>> a) processes $_POST or $_GET
>> b) if all is valid, does the insert/update and redirects to another
>> page (Your data has been saved.)
>> c) if all is not valid, populates the $SESSION with good values and
>> then redirects to the view form.
>>
>> The whole thing is started by calling the controller. Since no data is
>> valid, it will redirect to the view.
>> The view then presents a form for filling in.
>> The user fills in the form and submits which then calls the controller.
>> The controller processes the form data and either updates/inserts it or
>> calls the view again.
>>
>> If you encapsulate your database accesses into a class or set of classes
>> which are called from the controller, you will have a light-weight
>> implementation of a classic Model-View-Controller (MVC2) architecture.[/color]
>
> Thank you for your quick answer, i am heading towards the implementation you
> suggested. Just another minor question: can i add an array variable to
> SESSION? How can this be done?
>
>[/color]

$my_array = array('one' => 1, 'two' => 2);
$_SESSION['my_array'] = $my_array;

or

$_SESSION['my_array'] = array('one' => 1, 'two' => 2);

-david-

[Jerry Stuckle]

Re: Validating form input data

stathis gotsis wrote:[color=blue]
> Hello everyone,
>
> I am tying to come up with an elegant way to process some input data that
> come from a form. When the user hits the 'Submit' button, i want the form to
> appear again with the already entered valid data filled in and prompt the
> user to re-enter the non-valid data. If all data is valid, i will forward to
> an other .php page which enters the data into a database.
>
> I tried to do this in the following way: the form always hits back on
> itself, but when all data is valid i use the PHP:header() to redirect to the
> data.php that performs the database insertion. The problem is that the data
> is not available to data.php in the $_POST variable. How can i overcome this
> problem? Any other subtle way to handle the whole thing? Any help
> appreciated.
>
>[/color]

Stathis,

I do things the same way you do - the page validates its own input and then uses
header() to move to the next page. But before the header() call, I store the
data in the $_SESSION variable.

I prefer validating the data in the same page that contains the data. It keeps
the code together and, IMHO, cleaner. Plus, if it isn't needed in the next
page, you don't even have to touch that page.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Jerry Stuckle]

Re: Validating form input data

Manuel Lemos wrote:[color=blue]
> Hello,
>
> on 04/30/2006 09:38 AM stathis gotsis said the following:
>[color=green]
>>Hello everyone,
>>
>>I am tying to come up with an elegant way to process some input data that
>>come from a form. When the user hits the 'Submit' button, i want the form to
>>appear again with the already entered valid data filled in and prompt the
>>user to re-enter the non-valid data. If all data is valid, i will forward to
>>an other .php page which enters the data into a database.
>>
>>I tried to do this in the following way: the form always hits back on
>>itself, but when all data is valid i use the PHP:header() to redirect to the
>>data.php that performs the database insertion. The problem is that the data
>>is not available to data.php in the $_POST variable. How can i overcome this
>>problem? Any other subtle way to handle the whole thing? Any help
>>appreciated .[/color]
>
>
> Nothing stops you from presenting the form and process it with the same
> script.
>
> You may want to take a look at this forms generation and validation
> class that shows you how to do that. Additionally it generates your
> forms with Javascript to validate the form also on the client site,
> avoiding unnecessary server round trips just to tell the user the form
> has invalid fields.
>
> http://www.phpclasses.org/formsgeneration
>
>[/color]

And what happens if someone has javascript turned off?

NEVER rely on client side validation!

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Ken Robinson]

Re: Validating form input data


Jerry Stuckle wrote (in part):[color=blue][color=green]
> > You may want to take a look at this forms generation and validation
> > class that shows you how to do that. Additionally it generates your
> > forms with Javascript to validate the form also on the client site,
> > avoiding unnecessary server round trips just to tell the user the form
> > has invalid fields.
> >
> > http://www.phpclasses.org/formsgeneration
> >
> >[/color]
>
> And what happens if someone has javascript turned off?
>
> NEVER rely on client side validation!
>[/color]

Also, what happen if a hacker screen scraps your form and uses another
program to send information to your script directly to try to break it
or use it in ways you didn't think about.

Please go to the PHP Security Consortuim's web site <phpsec.org> and
read the different articles in both the "Articles" and "Library"
sections.

Ken

[John Dunlop]

Re: Validating form input data

Jerry Stuckle:
[color=blue]
> Manuel Lemos wrote:
>[color=green]
> > You may want to take a look at this forms generation and validation
> > class that shows you how to do that. Additionally it generates your
> > forms with Javascript to validate the form also on the client site,
> > avoiding unnecessary server round trips just to tell the user the form
> > has invalid fields.
> >
> > http://www.phpclasses.org/formsgeneration[/color]
>
> And what happens if someone has javascript turned off?[/color]

I would assume the brunt of Manuel's class is its server-side
checking. The javascript is, as he said, an *addition*, an addition
which, when javascript happens to be available, obviates the need for a
round trip to the server just to say some field data was unacceptable.
Sounds good to me.
[color=blue]
> NEVER rely on client side validation![/color]

Fair enough, bears repeating.

--
Jock

[John Dunlop]

Re: Validating form input data

Jerry Stuckle:
[color=blue]
> Manuel Lemos wrote:
>[color=green]
> > You may want to take a look at this forms generation and validation
> > class that shows you how to do that. Additionally it generates your
> > forms with Javascript to validate the form also on the client site,
> > avoiding unnecessary server round trips just to tell the user the form
> > has invalid fields.
> >
> > http://www.phpclasses.org/formsgeneration[/color]
>
> And what happens if someone has javascript turned off?[/color]

I would assume the brunt of Manuel's class is its server-side
checking. The javascript is, as he said, an *addition*, an addition
which, when javascript happens to be available, obviates the need for a
round trip to the server just to say some field data was unacceptable.
Sounds good to me.
[color=blue]
> NEVER rely on client side validation![/color]

Fair enough, bears repeating.

--
Jock

[stathis gotsis]

Re: Validating form input data

"Jerry Stuckle" <jstucklex@attg lobal.net> wrote in message
news:85OdnbH4AK RfScnZRVn-pQ@comcast.com. ..[color=blue]
> stathis gotsis wrote:[color=green]
> > Hello everyone,
> >
> > I am tying to come up with an elegant way to process some input data[/color][/color]
that[color=blue][color=green]
> > come from a form. When the user hits the 'Submit' button, i want the[/color][/color]
form to[color=blue][color=green]
> > appear again with the already entered valid data filled in and prompt[/color][/color]
the[color=blue][color=green]
> > user to re-enter the non-valid data. If all data is valid, i will[/color][/color]
forward to[color=blue][color=green]
> > an other .php page which enters the data into a database.
> >
> > I tried to do this in the following way: the form always hits back on
> > itself, but when all data is valid i use the PHP:header() to redirect to[/color][/color]
the[color=blue][color=green]
> > data.php that performs the database insertion. The problem is that the[/color][/color]
data[color=blue][color=green]
> > is not available to data.php in the $_POST variable. How can i overcome[/color][/color]
this[color=blue][color=green]
> > problem? Any other subtle way to handle the whole thing? Any help
> > appreciated.
> >
> >[/color]
>
> Stathis,
>
> I do things the same way you do - the page validates its own input and[/color]
then uses[color=blue]
> header() to move to the next page. But before the header() call, I store[/color]
the[color=blue]
> data in the $_SESSION variable.
>
> I prefer validating the data in the same page that contains the data. It[/color]
keeps[color=blue]
> the code together and, IMHO, cleaner. Plus, if it isn't needed in the[/color]
next[color=blue]
> page, you don't even have to touch that page.
>[/color]

Thank you for your answer. I missed the obvious: passing data through the
SESSION object on to the next page. This solution might even be more concise
than the MVC architecture that David suggested earlier on.

[David Haynes]

Re: Validating form input data

stathis gotsis wrote:[color=blue]
> "Jerry Stuckle" <jstucklex@attg lobal.net> wrote in message
> news:85OdnbH4AK RfScnZRVn-pQ@comcast.com. ..[color=green]
>> stathis gotsis wrote:[color=darkred]
>>> Hello everyone,
>>>
>>> I am tying to come up with an elegant way to process some input data[/color][/color]
> that[color=green][color=darkred]
>>> come from a form. When the user hits the 'Submit' button, i want the[/color][/color]
> form to[color=green][color=darkred]
>>> appear again with the already entered valid data filled in and prompt[/color][/color]
> the[color=green][color=darkred]
>>> user to re-enter the non-valid data. If all data is valid, i will[/color][/color]
> forward to[color=green][color=darkred]
>>> an other .php page which enters the data into a database.
>>>
>>> I tried to do this in the following way: the form always hits back on
>>> itself, but when all data is valid i use the PHP:header() to redirect to[/color][/color]
> the[color=green][color=darkred]
>>> data.php that performs the database insertion. The problem is that the[/color][/color]
> data[color=green][color=darkred]
>>> is not available to data.php in the $_POST variable. How can i overcome[/color][/color]
> this[color=green][color=darkred]
>>> problem? Any other subtle way to handle the whole thing? Any help
>>> appreciated.
>>>
>>>[/color]
>> Stathis,
>>
>> I do things the same way you do - the page validates its own input and[/color]
> then uses[color=green]
>> header() to move to the next page. But before the header() call, I store[/color]
> the[color=green]
>> data in the $_SESSION variable.
>>
>> I prefer validating the data in the same page that contains the data. It[/color]
> keeps[color=green]
>> the code together and, IMHO, cleaner. Plus, if it isn't needed in the[/color]
> next[color=green]
>> page, you don't even have to touch that page.
>>[/color]
>
> Thank you for your answer. I missed the obvious: passing data through the
> SESSION object on to the next page. This solution might even be more concise
> than the MVC architecture that David suggested earlier on.
>
>[/color]
It is more concise but suffers from marrying the view to the business
logic. If you want to update the view, say for supporting cell phones or
separating web page creation from the business logic, then it is easier
under MVC than in a monolithic form.

Both work. Which is best for you depends upon your needs.

One thing I like about MVC is that the controllers and view all follow
the same general format which makes understanding a new page easier.

Controllers condition their environment, handle any POST/GET data, set
the SESSION and redirect.

Views bring in any SESSION data, set up for internationaliz ation and
paint the form.

Obviously, you can combine the controller and view into one page. I find
that the resulting pages can get to be quite large (lines of code) and
complex (lots of business logic) which gets in the way on understanding
how the page is being defined (i.e. the HTML)

-david-

[Manuel Lemos]

Re: Validating form input data

Hello,

on 04/30/2006 12:17 PM Jerry Stuckle said the following:[color=blue][color=green][color=darkred]
>>> I am tying to come up with an elegant way to process some input data
>>> that
>>> come from a form. When the user hits the 'Submit' button, i want the
>>> form to
>>> appear again with the already entered valid data filled in and prompt
>>> the
>>> user to re-enter the non-valid data. If all data is valid, i will
>>> forward to
>>> an other .php page which enters the data into a database.
>>>
>>> I tried to do this in the following way: the form always hits back on
>>> itself, but when all data is valid i use the PHP:header() to redirect
>>> to the
>>> data.php that performs the database insertion. The problem is that
>>> the data
>>> is not available to data.php in the $_POST variable. How can i
>>> overcome this
>>> problem? Any other subtle way to handle the whole thing? Any help
>>> appreciated.[/color]
>>
>>
>> Nothing stops you from presenting the form and process it with the same
>> script.
>>
>> You may want to take a look at this forms generation and validation
>> class that shows you how to do that. Additionally it generates your
>> forms with Javascript to validate the form also on the client site,
>> avoiding unnecessary server round trips just to tell the user the form
>> has invalid fields.
>>
>> http://www.phpclasses.org/formsgeneration
>>
>>[/color]
>
> And what happens if someone has javascript turned off?
>
> NEVER rely on client side validation![/color]


This is a very mature class. It implements server side validation since
when it was released for the first time in 1999 . It generates client
side validation Javascript code to reduce server needless round trips
and so improve user-friendliness.


--

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator

http://www.metastorage.net/

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

[stathis gotsis]

Re: Validating form input data

"David Haynes" <david.haynes2@ sympatico.ca> wrote in message
news:o9b5g.4106 $lJ6.1001@fe69. usenetserver.co m...
[color=blue]
> It is more concise but suffers from marrying the view to the business
> logic. If you want to update the view, say for supporting cell phones or
> separating web page creation from the business logic, then it is easier
> under MVC than in a monolithic form.[/color]

Yes, that is true. If that is the case, i assume the controller will
redirect to the appropriate view suited to the client's equipment (or rather
browser), am i right?
[color=blue]
> Both work. Which is best for you depends upon your needs.
>
> One thing I like about MVC is that the controllers and view all follow
> the same general format which makes understanding a new page easier.
>
> Controllers condition their environment, handle any POST/GET data, set
> the SESSION and redirect.[/color]

In your original post you implied that the controller can also contain
insert/update (into database) actions. Should the controller redirect to
another page that handles this stuff? It does not really matter in the
situation i am involved in right now, but i want to stick to correct
guidelines.
[color=blue]
> Views bring in any SESSION data, set up for internationaliz ation and
> paint the form.
>
> Obviously, you can combine the controller and view into one page. I find
> that the resulting pages can get to be quite large (lines of code) and
> complex (lots of business logic) which gets in the way on understanding
> how the page is being defined (i.e. the HTML)[/color]

What i did was combine some of the controller's logic into the the form's
page. If alla data is valid the user gets redirected to another page which
handles database actions. I did this because i found passing around data
through the SESSION variable a bit clumsy. However, i can see the advantages
of the MVC model you suggest. Thank you again for the detailed explanation.

[David Haynes]

Re: Validating form input data

stathis gotsis wrote:[color=blue]
> "David Haynes" <david.haynes2@ sympatico.ca> wrote in message
> news:o9b5g.4106 $lJ6.1001@fe69. usenetserver.co m...
>[color=green]
>> It is more concise but suffers from marrying the view to the business
>> logic. If you want to update the view, say for supporting cell phones or
>> separating web page creation from the business logic, then it is easier
>> under MVC than in a monolithic form.[/color]
>
> Yes, that is true. If that is the case, i assume the controller will
> redirect to the appropriate view suited to the client's equipment (or rather
> browser), am i right?[/color]

Whatever is appropriate. My controllers know about cell phones, PDAs and
browsers and will redirect to the correct form as needed.
[color=blue][color=green]
>> Both work. Which is best for you depends upon your needs.
>>
>> One thing I like about MVC is that the controllers and view all follow
>> the same general format which makes understanding a new page easier.
>>
>> Controllers condition their environment, handle any POST/GET data, set
>> the SESSION and redirect.[/color]
>
> In your original post you implied that the controller can also contain
> insert/update (into database) actions. Should the controller redirect to
> another page that handles this stuff? It does not really matter in the
> situation i am involved in right now, but i want to stick to correct
> guidelines.[/color]

I don't do another redirect. I encapsulate the database access into a
set of classes (all based upon a master database access object). My
class is sort of like Hibernate in that it treats the database as a
reliable object store albeit without the overhead of serialization.

I have other classes to assist the business logic that present more
complex database views.

In my case, let's say I have a table called ACCOUNT. I will have an
object that subclasses the master database object and implements an
Account object. The instance may then be used to access a single row or
to provide a set of rows from the ACCOUNT table. Additionally, the
getter and setter routines are implemented as $foo = $account->login;
and $account->login = 'foo'; which is a lot easier than writing all
those getLogin() and setLogin() methods.
[color=blue]
>[color=green]
>> Views bring in any SESSION data, set up for internationaliz ation and
>> paint the form.
>>
>> Obviously, you can combine the controller and view into one page. I find
>> that the resulting pages can get to be quite large (lines of code) and
>> complex (lots of business logic) which gets in the way on understanding
>> how the page is being defined (i.e. the HTML)[/color]
>
> What i did was combine some of the controller's logic into the the form's
> page. If alla data is valid the user gets redirected to another page which
> handles database actions. I did this because i found passing around data
> through the SESSION variable a bit clumsy. However, i can see the advantages
> of the MVC model you suggest. Thank you again for the detailed explanation.[/color]

It can be a pain to load and unload the SESSION but if you are playing
in multiple interfaces - as I am - it can really save you a lot of time.
Also, think of the data passing from the controllers and views as your
API definition. You have a very well defined set of data that the
controller will accept and a well defined set of data that the view will
accept. This can make data verification/validation a lot easier.

Good luck with your project.

-david-