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
