3 ms·
The client sends the before/after values, and you only update the ones that have changed. If people are changing different fields there's no conflict. Yes, th
by brlewis 19y ago
The client sends the before/after values, and you only update the ones that have changed. If people are changing different fields there's no conflict.
Yes, the client could fake it, but such faking would not open up new capabilities that the client didn't already have.
- edw519 19y agoWhat do you mean by "faking" it? Example please. Are you not too concerned about this because the real validation happens on the server anyway?
- brlewis 19y agoSuppose two people are updating info about a T shirt: size=M color=green Suppose Al is in charge of color and Betty is in charge of size. They both get the form at the same time. Al sends oldsize=M newsize=M oldcolor=green newcolor=blue Betty sends oldsize=M newsize=S oldcolor=green newcolor=green The server ignores Al's oldsize/newsize and Betty's oldcolor/newcolor because the values are unchanged. You end up with size=S and color=blue no matter who sends the update first. By "faking it" I refer to the fact that the old values are user-supplied data. Validation of the new data is a separate issue. Someone could "fake" an old value. This merely means they would change a value that they were already authorized to change. Messing with the "old" values on the client side has no hack value. That's why I'm not at all concerned about it.
- some 19y agoUsing Javascript, the client could as well only send the fields that have changed.
- wlievens 19y agoExactly what I was thinking.
- brlewis 19y agoThat's true. However, depending on the needs of the application, you might want to take things a step farther and engage the client in a dialogue about values changed by others. For that purpose it helps to tell the server what the values were when the client loaded the form.