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.

[stathis gotsis]

"Jerry Stuckle" <js*******@attg lobal.net> wrote in message
news:85******** ************@co mcast.com...

stathis gotsis wrote:

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.
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.

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]

stathis gotsis wrote:

"Jerry Stuckle" <js*******@attg lobal.net> wrote in message
news:85******** ************@co mcast.com...

stathis gotsis wrote:

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.

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.

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.

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]

Hello,

on 04/30/2006 12:17 PM Jerry Stuckle said the following:

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.

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

And what happens if someone has javascript turned off?

NEVER rely on client side validation!

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]

"David Haynes" <da***********@ sympatico.ca> wrote in message
news:o9******** *********@fe69. usenetserver.co m...

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.
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?
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.
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.
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)

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]

stathis gotsis wrote:

"David Haynes" <da***********@ sympatico.ca> wrote in message
news:o9******** *********@fe69. usenetserver.co m...

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.
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?

Whatever is appropriate. My controllers know about cell phones, PDAs and
browsers and will redirect to the correct form as needed.

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.

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.

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.

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)

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.

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-

[spam_only_please]

Warning OT>>>

is it only me- or is that phpclassess.org a little on the bizarres
side?

I had to download google-analytical.com/ tribalfusion.co m, a visual
basic mpg ad of a guy mixing coffee grounds and water in his mouth to
get to the links for the examples. Only to then find I have to pick a
mirror, register/ login..''

Note to self: Don't bother trying to view anything at phpclasses.org
ever again.

</rant>

[spam_only_please]

Warning OT>>>

is it only me- or is that phpclassess.org a little on the bizarres
side?

I had to download google-analytical.com/ tribalfusion.co m, a visual
basic mpg ad of a guy mixing coffee grounds and water in his mouth to
get to the links for the examples. Only to then find I have to pick a
mirror, register/ login... but alas I forgot what the hell I was doing
and moved along the net else where. wtf.

Note to self: Don't bother trying to view anything at phpclasses.org
ever again.

</rant>

[Manuel Lemos]

Hello,

on 05/01/2006 06:11 AM sp************* *@comcast.net said the following:

Warning OT>>>

is it only me- or is that phpclassess.org a little on the bizarres
side?

I had to download google-analytical.com/ tribalfusion.co m, a visual
basic mpg ad of a guy mixing coffee grounds and water in his mouth to
I don't know what you do for a living but the PHPClasses site depends on
advertising revenue to keep open.

get to the links for the examples. Only to then find I have to pick a
mirror, register/ login..''
This is often a misundestood matter. You may want to read this to
understand why.

http://www.phpclasses.org/faq/#subscribe-to-download

BTW, when you are subscribed and logged, you are not redirected to a mirror.

Note to self: Don't bother trying to view anything at phpclasses.org
ever again.

</rant>

Since you work with PHP I suspect that Google will point you to this
site very often. After all, from the about 10,000 users that subscribe
to the site every month, great part of them are lead by Google.
--

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/