struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <>
Subject Re: svn commit: r552396 - /struts/struts1/trunk/core/src/main/java/org/apache/struts/chain/commands/
Date Fri, 06 Jul 2007 07:27:17 GMT
On 7/6/07, Paul Benedict <> wrote:
> 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.

IMO "sometimes populate on cancel" is probably the worst possible
option - incompatible and incosistent!

I still am against breaking compatibility over this - but I will stop
objecting if theres a way for users to configure for the old behaviour
- AFAIK we can set properties in the chain config - so one possible
option would be to add a "populateOnCancel" option to
"AbstractPopulateActionForm" and in the chain-config.xml something


                populateOnCancel="false" />


> Paul

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

View raw message