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