Niall Pemberton wrote:
IMO people who want to move forward should use Struts2 - Struts 1
shouldn't break compatibilty lightly - I see no great benefit to
changing how this has worked for 6 years and just pain for anyone who
has happened to rely on it. Also with the Command Chain introduced in
Struts 1.3 its possible to easily provide both new functionality and
compatibility with different Command implementations. So I'm still
against this change as it is now.
Niall
I am not interested in lightning bolt changes for 1.x. People will move
to 2.0 as necessary, but I imagine 1.0 will live on for a very long time
and upgrades will still be wanted without a revolution. Granted to your
point, the change is not fixing anything considered a blocker/emergency,
but I do believe this patches a hole in the way Struts could be misused.
The real problem behind collecting data during cancellation is the false
assurance that the form was completed correctly. However, this argument
is only as strong as the perceived danger of accidentally shooting
oneself in the foot :-) Because manipulating form data in a cancellation
is probably highly irregular, I think its justified to block off this
route without affecting well-structured apps.
While I would like to see the change stand as is, you've made me think
of another alternative: Limit the change to when the form is present,
*validation is true,* but canceled. Because my entire emphasis is on
preventing the manipulation on a validated form, I find this alternative
to be worthier. Your thoughts appreciated.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
