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.


Reply via email to