Re: POST action
| From: | Ashley Sheridan | Date: | Sun, 28 Jul 2013 17:38:04 +0000 |
| Subject: | Re: POST action | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-321733@lists.php.net to get a copy of this message | ||
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
> > this.)
> >
> > 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
> > hardened.
> >
> > --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.
Thanks,
Ash
http://www.ashleysheridan.co.uk