Prev: New to PHP and the list
Next: 1984 (Big Brother)
From: viraj on 11 Sep 2010 22:27
On Sat, Sep 11, 2010 at 10:22 PM, Tamara Temple <tamouse.lists(a)gmail.com> wrote:
> I have a general question and am looking for best practices.
>
> Is it worth the overhead of passing along the previous values in the table
> in hidden fields so that fields can be checked to see if they've been

without storing all the values in respective hidden fields, calculate
a 'checksum' on data and store in one hidden field. after the submit
and before you decide on the update, you can calculate the checksum of
submitted data, compare against the hidden field checksum and take the
decision.

if you maintain a session, storing checksum in session instead of
client side (hidden field in form) will be more safe/secure and will
help in improving the mechanism (persistent classes, serialized data
etc)


~viraj


> updated or not after the submit? Or is it worth reloading the old values
> from the table to check against the newly submitted form? Or is all that
> overhead not worth the time because an update that overwrites existing
> values with the same values is not that onerous?
>
> (Is that question clear enough?)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
From: Robert Cummings on 12 Sep 2010 16:34
On 10-09-11 12:52 PM, Tamara Temple wrote:
> I have a general question and am looking for best practices.
>
> Suppose I present a user with a form for editing an entry in a table,
> i.e., the form has filled in values from the existing table entry.
>
> Now, suppose they click on 'submit' without making any changes in the
> form. (Perhaps, say, rather than clicking 'Cancel' or 'Return to Main'
> or some other option which would get them out of that screen without
> submitting the form).
>
> Is it worth the overhead of passing along the previous values in the
> table in hidden fields so that fields can be checked to see if they've
> been updated or not after the submit? Or is it worth reloading the old
> values from the table to check against the newly submitted form? Or is
> all that overhead not worth the time because an update that overwrites
> existing values with the same values is not that onerous?
>
> (Is that question clear enough?)

I use database table to object mapping classes. The base class sets a
dirty bit if a field actually changes. If an attempt is made to save the
data and no dirty bits are set, then the save method returns true for a
successful save, but no commit to database is made since nothing has
changed. In this way I never think about the problem beyond the original
implementation of the base class.

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.
From: Ashley Sheridan on 12 Sep 2010 17:16
On Sun, 2010-09-12 at 16:12 -0500, Tamara Temple wrote:

> On Sep 12, 2010, at 3:34 PM, Robert Cummings wrote:
>
> > On 10-09-11 12:52 PM, Tamara Temple wrote:
> >> I have a general question and am looking for best practices.
> >>
> >> Suppose I present a user with a form for editing an entry in a table,
> >> i.e., the form has filled in values from the existing table entry.
> >>
> >> Now, suppose they click on 'submit' without making any changes in the
> >> form. (Perhaps, say, rather than clicking 'Cancel' or 'Return to
> >> Main'
> >> or some other option which would get them out of that screen without
> >> submitting the form).
> >>
> >> Is it worth the overhead of passing along the previous values in the
> >> table in hidden fields so that fields can be checked to see if
> >> they've
> >> been updated or not after the submit? Or is it worth reloading the
> >> old
> >> values from the table to check against the newly submitted form? Or
> >> is
> >> all that overhead not worth the time because an update that
> >> overwrites
> >> existing values with the same values is not that onerous?
> >>
> >> (Is that question clear enough?)
> >
> > I use database table to object mapping classes. The base class sets
> > a dirty bit if a field actually changes. If an attempt is made to
> > save the data and no dirty bits are set, then the save method
> > returns true for a successful save, but no commit to database is
> > made since nothing has changed. In this way I never think about the
> > problem beyond the original implementation of the base class.
>
> 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.
>


If you're worried about how much data needs to be sent back and forth,
then compare the data sent to what exists already on the server side,
and don't send the previous values. To be honest, you can't rely on what
the client says anyway, so you really ought to do the checking
server-side before issuing an update.

Having said that, if you're not too worried about traffic, then sending
the previous values would allow you to give visual indicators to the
user with client-side techniques (javascript, etc) which could be nice
for the user.

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


From: Michael Shadle on 12 Sep 2010 17:19
On Sun, Sep 12, 2010 at 2:12 PM, Tamara Temple <tamouse.lists(a)gmail.com> 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?
From: Robert Cummings on 12 Sep 2010 17:28
On 10-09-12 05:19 PM, Michael Shadle wrote:
> On Sun, Sep 12, 2010 at 2:12 PM, Tamara Temple<tamouse.lists(a)gmail.com> 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.

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.
 |  Next  |  Last
Pages: 1 2
Prev: New to PHP and the list
Next: 1984 (Big Brother)