struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <>
Subject Re: svn commit: r552396 - /struts/struts1/trunk/core/src/main/java/org/apache/struts/chain/commands/
Date Fri, 06 Jul 2007 05:36:52 GMT
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message