struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: svn commit: r552396 - /struts/struts1/trunk/core/src/main/java/org/apache/struts/chain/commands/AbstractPopulateActionForm.java
Date Fri, 06 Jul 2007 10:39:38 GMT
I tested your suggestion. It works great. I am 100% for this.

Niall Pemberton wrote:
> On 7/6/07, Paul Benedict <pbenedict@apache.org> 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
> like:
>
> <command
>
> className="org.apache.struts.chain.commands.servlet.PopulateActionForm"
>                populateOnCancel="false" />
>
> Niall
>
>> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message