NYCPHP Meetup

NYPHP.org

[nycphp-talk] Proper Form Processing Techniques

David Krings ramons at gmx.net
Sun May 18 07:52:59 EDT 2014


On 5/18/2014 1:43 AM, Michael B Allen wrote:
> Hi All,
>
> Occasionally I need to do a little web programming and I must admit
> after almost 2 decades I still find myself searching for a better way
> to handle HTML forms. I blame this mostly on the W3C's invalid
> assumption that HTML is for rendering documents and not building
> applications. But putting blame aside, I would like to ask the list to
> share their best form processing techniques.
>
> There's a particular scenario that bugs me about forms which is that
> it is increasingly rare that you have a bunch of fields with just a
> submit button. There are usually multiple possible operations that
> build up and modify the data before it's submitted. A good example of
> this is a shopping cart where there is one form but commands for
> removing and item, updating quantities, applying a discount code and
> submitting the cart. But the form only has one action.
>
> Currently I've been just using hidden fields and then call a
> javascript function to fill in the hidden fields with the desired data
> for the particular command and submit the form.
>
> Ideas?
>

Hi!

The only ideas I have is to have items listed in divs and then use js to hide 
the div if the action on that item is 'remove'. Other than that, rather than 
deal with hidden fields that really aren't that hidden write everything you 
need to know to the session cookie. HTML5 offers even more options now. Not 
sure if that is a better way, but it is at least a different way and maybe it 
helps.

HTML was never intended as application programming language and I don't see 
that as a problem. You do want to separate business logic from presentation 
even when it often blends together using javascript. Even js is a cheat 
because browser based apps are by design client/server apps. The client 
requests and the server responds. I agree that js makes pages more usable and 
allows for pretty neat stuff, but it breaks the underlying model and often 
enough I encounter problems because the server has no idea what the client is 
doing, sometimes even so much so that the server lets the session time out 
although the user is actively using the app, but all interactions are client 
side.

David


More information about the talk mailing list