Re: [PHP] POST action

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?