You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Ted Husted (JIRA)" <ji...@apache.org> on 2006/07/26 16:20:21 UTC
[jira] Created: (WW-1393) Returning Result directly
Returning Result directly
-------------------------
Key: WW-1393
URL: http://issues.apache.org/struts/browse/WW-1393
Project: Struts 2
Issue Type: New Feature
Reporter: Ted Husted
Fix For: Future
From: Don Brown <mr...@twdata.org>
Reply-To: Struts Developers List <de...@struts.apache.org>
To: Struts Developers List <de...@struts.apache.org>
Date: Jul 25, 2006 4:46 PM
Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
Tim Fennell wrote:
> I was going to chime in on this, so I may as well now. Stripes, through
> it's default way of routing events, will allow a submitted form or URL
> to invoke any method that is public no-arg and returns a Resolution -
> this seems much safer because Resolution is a Stripes specific class as
> opposed to String, which obviously isn't. In this case @HandlesEvent is
> only used to mark methods that have different return types, or need to
> be aliased.
I personally would like to see XWork enhanced to support action methods
returning Result instances directly, however we would have to thoroughly think
through the consequences.
Reasons for:
- Better security
- Easier, more explicit
- Results will probably be defined as annotations soon, so why not just return
the Result directly?
- Allows non-annotation apps to drastically minimize config
- Supports more complex results
Reasons against:
- The Action interface really loses most of its meaning
- ActionSupport could no longer extend Action
- XWork internals would need modification since many places expect a result code
- Supporting the return of Result, String, and Object might be confusing for
new developers
- Current Results would need some improvements to make them easier to use
(better constructors, default location names/patterns, etc)
Again, all things considered, I'd really like to see us add the ability to
return Results directly as I think it just makes things easier. The ability to
separate JSP paths from Java code, IMO, is way overrated and years of its
practice hasn't shown the additional complexity is really worth it. For those
that prefer the old style, they would still have that option.
Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Ted Husted updated WW-1393:
---------------------------
Attachment: rrd1.txt
Thread rom Struts dev@ (plain text)
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Fix For: Future
>
> Attachments: rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WW-1393) Returning Result directly
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39728 ]
Don Brown commented on WW-1393:
-------------------------------
Just return a Result object, instead of a String. The framework will automatically detect it and know what to do.
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: https://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Assigned To: Don Brown
> Fix For: 2.0.2
>
> Attachments: adrr.txt, rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Ted Husted updated WW-1393:
---------------------------
Comment: was deleted
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Fix For: Future
>
> Attachments: adrr.txt, rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Ted Husted updated WW-1393:
---------------------------
Attachment: rrd2.txt
Thread rom Struts dev@ (plain text)
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Fix For: Future
>
> Attachments: rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Ted Husted updated WW-1393:
---------------------------
Attachment: rrd3.txt
Thread rom Struts dev@ (plain text)
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Fix For: Future
>
> Attachments: rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Ted Husted updated WW-1393:
---------------------------
Comment: was deleted
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Fix For: Future
>
> Attachments: adrr.txt, rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Ted Husted updated WW-1393:
---------------------------
See attachments for mailing list threads.
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Fix For: Future
>
> Attachments: adrr.txt, rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (WW-1393) Returning Result directly
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Don Brown resolved WW-1393.
---------------------------
Fix Version/s: 2.0.2
(was: Future)
Resolution: Fixed
Assignee: Don Brown
This has been added to XWork 2
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Assigned To: Don Brown
> Fix For: 2.0.2
>
> Attachments: adrr.txt, rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39727 ]
Ted Husted commented on WW-1393:
--------------------------------
How does it work.? don't see a DirectResult class in the XWork API.
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: https://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Assigned To: Don Brown
> Fix For: 2.0.2
>
> Attachments: adrr.txt, rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WW-1393) Returning Result directly
Posted by "Ted Husted (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/WW-1393?page=all ]
Ted Husted updated WW-1393:
---------------------------
Attachment: adrr.txt
Thread from WW2 dev forum (plaint text)
> Returning Result directly
> -------------------------
>
> Key: WW-1393
> URL: http://issues.apache.org/struts/browse/WW-1393
> Project: Struts 2
> Issue Type: New Feature
> Reporter: Ted Husted
> Fix For: Future
>
> Attachments: adrr.txt, rrd1.txt, rrd2.txt, rrd3.txt
>
>
> From: Don Brown <mr...@twdata.org>
> Reply-To: Struts Developers List <de...@struts.apache.org>
> To: Struts Developers List <de...@struts.apache.org>
> Date: Jul 25, 2006 4:46 PM
> Subject: Returning Result directly (was Re: DefaultActionMapper compatablity switch)
> Tim Fennell wrote:
> > I was going to chime in on this, so I may as well now. Stripes, through
> > it's default way of routing events, will allow a submitted form or URL
> > to invoke any method that is public no-arg and returns a Resolution -
> > this seems much safer because Resolution is a Stripes specific class as
> > opposed to String, which obviously isn't. In this case @HandlesEvent is
> > only used to mark methods that have different return types, or need to
> > be aliased.
> I personally would like to see XWork enhanced to support action methods
> returning Result instances directly, however we would have to thoroughly think
> through the consequences.
> Reasons for:
> - Better security
> - Easier, more explicit
> - Results will probably be defined as annotations soon, so why not just return
> the Result directly?
> - Allows non-annotation apps to drastically minimize config
> - Supports more complex results
> Reasons against:
> - The Action interface really loses most of its meaning
> - ActionSupport could no longer extend Action
> - XWork internals would need modification since many places expect a result code
> - Supporting the return of Result, String, and Object might be confusing for
> new developers
> - Current Results would need some improvements to make them easier to use
> (better constructors, default location names/patterns, etc)
> Again, all things considered, I'd really like to see us add the ability to
> return Results directly as I think it just makes things easier. The ability to
> separate JSP paths from Java code, IMO, is way overrated and years of its
> practice hasn't shown the additional complexity is really worth it. For those
> that prefer the old style, they would still have that option.
> Don
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira