> -----Original Message----- > From: Martin Cooper [mailto:martin.cooper@;tumbleweed.com] > Subject: RE: Unclear semantics on form use for "wizards" > > The "outrageous effort"? Just automate it, and it becomes trivial.
How? Curious how you manage the problem... It's compile-time automation versus runtime automation, I prefer the latter because memory is cheaper than the cost of developers and QA to track down issues with missing form fields once the app is deployed. If I have to put people on a future missing field problem for an hour, then the hour it takes for them to go to lunch and the hour it takes the whole team to get together and discuss how to make sure it doesn't happen again, I'd have rather just put out the $0.30 per megabyte for some more mems up front and avoid the problem altogether. Strict separation of presentation and logic means that the presentation should not be a container of variables that are required by the logic. I don't want page developers to be responsible for or potentially have impact on the operation of the logic. re: security - are you going to take an MD5 hash of the hidden fields to ensure that they aren't tampered with, store that in the session? If you send the integer primary key of sequentially numbered database record down to the client, do you really want to add all that logic to validate that the id you are returned is valid? > As Craig mentioned earlier in this thread, using session > state also means > you have to write code to somehow protect yourself from multiple > simultaneous requests (e.g. from frames, or multiple browser > windows). I'd > say that's more effort (and much more difficult to do) than > using hidden > fields. Isn't this covered by consistent and correct use of transaction tokens? Transaction tokens are necessary anyway for instances such as closing out a shopping cart (you don't want to place an order twice), logging in (hitting the back button after entering the wrong password shouldn't try to submit my wrong password again, taking me one step closer to having my account locked out), etc. It just seems like there is no reason not to use them. There's a hundred ways to do this stuff, so I hope this doesn't come off as me challenging your style. But I am interested if I am missing something here. best, -b -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
