You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Guillaume Bilodeau (JIRA)" <ji...@apache.org> on 2008/05/07 05:12:07 UTC

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

Flash scope
-----------

                 Key: WW-2635
                 URL: https://issues.apache.org/struts/browse/WW-2635
             Project: Struts 2
          Issue Type: New Feature
          Components: "New" API
    Affects Versions: 2.0.11
            Reporter: Guillaume Bilodeau


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.


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

Posted by "Rainer Hermanns (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rainer Hermanns updated WW-2635:
--------------------------------

                Flags: [Patch]
    Affects Version/s:     (was: 2.0.11)
        Fix Version/s:     (was: 2.2.x)
                       2.1.3
             Assignee: Rainer Hermanns

> 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.


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

Posted by "Don Brown (JIRA)" <ji...@apache.org>.
    [ 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.


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

Posted by "Guillaume Bilodeau (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Bilodeau updated WW-2635:
-----------------------------------

    Attachment: FlashResultTest.java

> Flash scope
> -----------
>
>                 Key: WW-2635
>                 URL: https://issues.apache.org/struts/browse/WW-2635
>             Project: Struts 2
>          Issue Type: New Feature
>          Components: "New" API
>    Affects Versions: 2.0.11
>            Reporter: Guillaume Bilodeau
>         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.


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

Posted by "Rainer Hermanns (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rainer Hermanns updated WW-2635:
--------------------------------

    Fix Version/s:     (was: 2.1.3)
                   2.2.x
         Assignee: Don Brown  (was: Rainer Hermanns)

ok, so I'll assign this to you to remember :)

> 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: Don Brown
>             Fix For: 2.2.x
>
>         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.


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

Posted by "Don Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Don Brown updated WW-2635:
--------------------------

    Fix Version/s: 2.2.x

> Flash scope
> -----------
>
>                 Key: WW-2635
>                 URL: https://issues.apache.org/struts/browse/WW-2635
>             Project: Struts 2
>          Issue Type: New Feature
>          Components: "New" API
>    Affects Versions: 2.0.11
>            Reporter: Guillaume Bilodeau
>             Fix For: 2.2.x
>
>         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.


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

Posted by "Guillaume Bilodeau (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Bilodeau updated WW-2635:
-----------------------------------

    Attachment: FlashResult.java

> Flash scope
> -----------
>
>                 Key: WW-2635
>                 URL: https://issues.apache.org/struts/browse/WW-2635
>             Project: Struts 2
>          Issue Type: New Feature
>          Components: "New" API
>    Affects Versions: 2.0.11
>            Reporter: Guillaume Bilodeau
>         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.


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

Posted by "Guillaume Bilodeau (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Bilodeau updated WW-2635:
-----------------------------------

    Attachment: FlashInterceptor.java

> Flash scope
> -----------
>
>                 Key: WW-2635
>                 URL: https://issues.apache.org/struts/browse/WW-2635
>             Project: Struts 2
>          Issue Type: New Feature
>          Components: "New" API
>    Affects Versions: 2.0.11
>            Reporter: Guillaume Bilodeau
>         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.


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

Posted by "Guillaume Bilodeau (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/struts/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillaume Bilodeau updated WW-2635:
-----------------------------------

    Attachment: FlashInterceptorTest.java

> Flash scope
> -----------
>
>                 Key: WW-2635
>                 URL: https://issues.apache.org/struts/browse/WW-2635
>             Project: Struts 2
>          Issue Type: New Feature
>          Components: "New" API
>    Affects Versions: 2.0.11
>            Reporter: Guillaume Bilodeau
>         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.