On Oct 24, 9:41 pm, Branko Vukelic <bg.bra...@gmail.com> wrote: > Oh, so ok, I get what you're trying to do now. Don't pass charge > amount around. Charge amount should be one-way. You NEVER, under ANY > circumstances, using ANY technology, expect that amount to come from > client side.
Yes, I guess that should have been obvious to me from the start! > The ajax thing you used is readily > readable using any javascript debugger. Yeah, I agree. Through our discussion, it slowly dawned on me during the course of this thread. > If there is a definite correlation between the rates and the final > amount you either > > a. get the amount of service and return the total cost, or Yeah, this is the one. > The best way to do this it probably use a table for unconfirmed > offerings. And move them into confirmed table once confirmation is > done. Ok, that's something I'll think about. However, having also thought about it more myself, I reckon I am going to go with the idea of storing all rows' data in the server-side session before showing the selection page that displays all rows, and passing (from the client) only the user-selected row index to the subsequent controller function, via a form submit. Then, in that controller, I'll look up the other data for the selected row again on the server side using the server-side session, and show the confirmation page with the calculated data again. The quantity of data is going to be small enough that size is no issue (say 30 selectable rows), and this scheme is very simple, hence low likelihood of bugs, and other unforeseen situations. Thanks very much for your help. It is amazing how much an intelligent sounding board helps to clarify thought.
