Re: How to handle a submitted form with no changes -- best practices sought

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2010-09-12 at 17:04 -0500, Tamara Temple wrote:

> On Sep 12, 2010, at 4:28 PM, Robert Cummings wrote:
> 
> > On 10-09-12 05:19 PM, Michael Shadle wrote:
> >> On Sun, Sep 12, 2010 at 2:12 PM, Tamara Temple<tamouse.lists@xxxxxxxxx 
> >> >  wrote:
> >>> Ok, but how do you detect if a field changes? The specific  
> >>> implementation
> >>> between application and data storage is probably moot until you  
> >>> figure that
> >>> part out.
> >>
> >> +1
> >>
> >> without talking to the server, or accessing it in the DOM somewhere,
> >> the client has no access to the data. is it done via ajax/javascript?
> >> some action onchange/onkeypress/etc. and check it against a variable
> >> that was set on pageload?
> >
> > Sorry, I thought this was about committing to the database versus  
> > sending back to the web server. I must have misread the original  
> > requirement. If trying to trap before submitting the form to the  
> > webserver then JavaScript is necessary. You can't do this on upload  
> > fields though.
> 
> Actually, even the client-side aspect isn't good enough -- they could  
> simply retype the same value in the field. Also, I'd like to not rely  
> on JavaScript alone to indicate that there's been a change, since, as  
> Ashley points out, someone could simply send up a form without  
> bothering with JavaScript. I'm talking about checking whether the  
> field has changed on the server-side of things, specifically.
> 
> So far, it seems the contenders are:
> 
> 1) just update the record if there's not a big load on the server
> 2) use a checksum before populating the form for display and after  
> receiving the post from the client, storing the initial checksum in a  
> session variable
> 3) compare the submitted values against the values in the data base,  
> since you can't trust what is coming from the client, although this  
> does put an additional load on the server which might not be good if  
> there's already a big load on the server
> 
> 
> 
> 


I didnt quite mean it like that. What I was saying that a client-side
technology could be used for showing things to the user purely for
nice-ness, and the server deals with determine what has changed. As I
see it, the form should be sent with the existing values once only, and
then when submitted, the server can grab the stored data from wherever
it was stored (db, file, etc) and then determine what changed.

It may be of interest to everyone that phpMyAdmin sends the form data
twice, once in the edit fields and once in a hidden field, and uses the
hidden field to determine if a change has been made, without checking
the actual data stored on the server.

Thanks,
Ash
http://www.ashleysheridan.co.uk



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux