NYCPHP Meetup

NYPHP.org

[nycphp-talk] Proper Form Processing Techniques

Michael B Allen ioplex at gmail.com
Tue May 20 04:24:38 EDT 2014


On Mon, May 19, 2014 at 1:40 PM, Gary Mort <garyamort at gmail.com> wrote:
>
> On 05/18/2014 01:43 AM, Michael B Allen wrote:
>>
>> Hi All,
>>
>>
>> My current technique seems a little hackish because I'm using the
>> hidden form element "cmd" to modify the action. In practice it might
>> seem purer to modify the action to call /purchase/remove or
>> /purchase/update for use with modern routing on the server.
>
>
> Whether you are adding an item, removing an item, adding a code, or whatnot
> - all those actions are based on "updating" the order.
>
> There is no need to do "different" processing for each one, you can do all
> of that processing in one process.
>
> IE: "removing" an item is equivalent to setting the item quantity to 0 or
> less[just for that joker who decides to put -1000 in the quantity field and
> force a submit].   So for every item that is submitted on the form, you can
> check the quantities, if zero or negative then if the product id is in the
> order list, remove it.
>
> If positive, then either add or update the quantity.
>
> If an item currently in the cart was not submitted, leave it alone.
>
> This allows for submission updates that only change a single item, delete
> items, add multiple items, etc.

Hi All,

I actually started out doing what you describe but I thought the
server side code started to get a little messy so I thought I would
break things up into add, remove, applyCode and so on.

As for other's suggestions about storing state on the client by what
is ultimately manipulating the DOM with JavaScript, I can see how that
could be used to create sophisticated UI elements. But I don't think I
would ever put any state on the client that I couldn't accept losing
at any moment (e.g. as I type this, gmail is periodically saving this
message with async requests). Even storing stuff in a cookie seems
dubious for a shopping cart. I think I will just commit each change to
the DB so that user's can be confident that what they see is actually
in the DB.

In general it sounds like there are no new techniques that are
obviously superior to the conventional form processing methods that
have been used for decades. So I will carry on with the usual
technique even if it does seem a little hackish.

Thanks,

Mike


More information about the talk mailing list