You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Don Brown (JIRA)" <ji...@apache.org> on 2008/06/21 11:31:05 UTC

[jira] Commented: (WW-2635) Flash scope

    [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44233#action_44233 ] 

Don Brown commented on WW-2635:
-------------------------------

Actually, please hold off on this and all scope-related ones.  I want us to work on creating a unified solution to scoping issues in 2.2 to help bring together all these little one-off solutions.

> Flash scope
> -----------
>
>                 Key: WW-2635
>                 URL: https://issues.apache.org/struts/browse/WW-2635
>             Project: Struts 2
>          Issue Type: New Feature
>          Components: "New" API
>            Reporter: Guillaume Bilodeau
>            Assignee: Rainer Hermanns
>             Fix For: 2.1.3
>
>         Attachments: FlashInterceptor.java, FlashInterceptorTest.java, FlashResult.java, FlashResultTest.java
>
>
> I have developed a FlashResult / FlashInterceptor pair to implement "flash" scope in a way that follows the usual Struts2 principles and respects its "feel".
> It basically works like the ServletActionRedirectResult except that instead of converting all extra parameters to strings and adding them as HTTP parameters in the redirect URL, it creates a HashMap using these parameter key/value pairs with no conversion and stores it in the user session.  On the next HTTP request the FlashInterceptor, if properly added to the interceptor stack, will retrieve this map and copy the map entries to the target action using the parameter keys.  It should work for all data types.
> To function correctly this approach assumes that bug WW-2170 is fixed.  The implementation also borrows a lot from the ServletActionRedirectResult and some refactoring should 
> be done.
> While there may be issues with flash scope in general with regards to repeated GETs being inconsistent, there are some valid use cases such as when saving messages to be displayed after a redirect.  I think it's good for the developer to have this tool and it could make a nice addition to the Struts2 code base.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.