Re: [PHP] POST action

On 13-07-28 01:51 PM, Jim Giner wrote:
>
> 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?

Chances are, once you've done this yourself and abstracted away the 
implementation details, you have your own framework for performing this 
generally tedious task :)

Cheers,
Rob.
-- 
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.