On 13-07-28 01:51 PM, Jim Giner wrote:

On 7/28/2013 1:38 PM, Ashley Sheridan wrote:
On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote:
On 7/28/2013 1:26 PM, Larry Garfield wrote:
On 07/28/2013 12:14 PM, iccsi wrote:
<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post
action to the form itself just like above coding.I would like to know
in the real projects, can we have action to the same PHP file, since
that we only need have one filebut not 2 files foe POST request,Your
help and information is great appreciated,regards,Iccsi,

"Real" projects to all kinds of things.  Which is best depends on who
you ask. :-)

I would argue that there's 3 "good" approaches, both of which are viable:

1) Define your form abstractly via an API, and have the API detect the
presence of POST request and then process the form after it's built.
That means you do submit back to the same URL.  (Drupal 7 and earlier do

2) Put 2 separate request handlers / controllers at the same path, one
for GET and one for POST.  So you submit back to the same URL but an
entirely different piece of code responds to it.  (This requires a good
routing system that can differentiate between GET and POST.)

3) Every form is defined as its own object somewhere with a unique ID.
All forms post to the same URL but include the form ID.  Code at that
URL looks up the form object by ID and maps the submitted data to it to
know what to do with it.

Note that in all 3 cases you're defining a form via an API of some
kind.  You are not writing form tags yourself.  Don't do that. Ever.  I
promise you that you will have a security hole or six if you do.  Use a
good form handling API for building forms.  That's what good "Real"
projects do.  There are a lot out there.  Most fullstack frameworks or
CMSes have one built in (I know Drupal and Code Ignighter do, although
they're quite different), and there are reasonably stand-alone
components available in both Symfony2 Components and Zend Framework.
Please don't write your own.  There are too many good ones (and even
more bad ones, of course) already out there that have been security

--Larry Garfield
Never write your own form?  I'm guilty - oh, so guilty.  What exactly is
a 'security hardened' form?

IN answer to OP - yes you can use a single script to handle your from
return.  I do that too!  I start by recognizing my first time thru and
send out a form/page.  I process the submit back from that page, doing
something based on the label of the submit button that I detect.  I may
then do some more processing and produce a newer version of the same
form/page and repeat.  Or I may end it all at that point.  Depends on
what the overall appl is doing.

And now I'll watch and see how much I'm doing wrong.

I don't think there's anything inherently wrong with writing your own
form processing code, as long as you understand what's going on. Many
frameworks do make this a lot easier though, but sometimes I find it
encourages you to ignore some of the details (like security) because
you "know" the framework handles that stuff.

I would say code forms on your own first, as a learning experience,
then use frameworks once you know what you're doing.


I dont' know that i'll ever use a framework.  Strictly an
ex-professional here doing my own website stuff.  As you say 'code your
own forms first as a learning experience'.  Well, once I've coded them
(aside: I think you mean 'process', not code) and learned how to do it
right, why should I give up that task and pick up a framework?

Chances are, once you've done this yourself and abstracted away the implementation details, you have your own framework for performing this generally tedious task :)

E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to