Flash Scope for Spring MVC (Without Spring Web Flow) [SPR-6464]

[spring-projects-issues]

Donny A. Wijaya opened SPR-6464 and commented

Geert Pante submitted the codes for this issue at: MOD-458.

---

Affects: 3.0 RC2

Reference URL: http://forum.springsource.org/showthread.php?t=73939&highlight=flash+scope

Attachments:

• FlashScope.java (675 bytes)
• FlashScopeFilter.java (1.16 kB)

Issue Links:

• There is no way to display success message(s). [SPR-2657] #7346 There is no way to display success message(s). ("is duplicated by")
• Provide better options to specify attributes on a redirect [SPR-1068] #5775 Provide better options to specify attributes on a redirect ("supersedes")

31 votes, 29 watchers

[spring-projects-issues]

Keith Donald commented

A couple of things to keep in mind when implementing flash scope:

1. flash scope needs to be accessible outside of dispatcher servlet for things like spring security, since artifacts like AuthenticationFailureHandlers could need to store flash messages. Alternatively, spring security needs to be put under mvc's control.

2. flash scope is traditionally stored in the session which exposes it to potential concurrency issues when multiple windows/tabs are used. See http://jira.codehaus.org/browse/GRAILS-1139 and http://markmail.org/message/wehwtbnwjtzwx4tm#query:+page:1+mid:loqkrwfk7mbwc6so+state:results for more information on this. Placing flash scope inside Window or Conversation scope could resolve this issue.

[spring-projects-issues]

Keith Donald commented

Working filter-based prototype attached.

<!-- Allows attributes to be accessed on the next request -->
<filter>
    <filter-name>flashScope</filter-name>
    <filter-class>org.springframework.samples.petcare.util.FlashScopeFilter</filter-class>
</filter>
	
<filter-mapping>
    <filter-name>flashScope</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

[spring-projects-issues]

Micha Kiener commented

I'm going to add this for Spring 3.1 along the Conversation Management.
But I'd rather call it FlashMap instead of FlashScope as it is not a Scope implementation being exposed to the container.

By default, the map will be stored in window scope, if activated otherwise in session scope.

[spring-projects-issues]

Mike Youngstrom commented

A couple of questions:

• Will this flash implementation storing mvc messages and retrieving them using the spring:messages tags?
• Will it support storing ModelAttributes for passing a ModelAttribute across a redirect? Similar to @SessionAttribute but just for the redirect?

Thanks,
Mike

[spring-projects-issues]

Marcel Overdijk commented

Will this be part of Spring 3.1?

Als greenhouse project would benefit from this as it uses a 'custom' implementation.
I think a lot of people are interested in flash scope.

[spring-projects-issues]

Stephen Patrick commented

will this be part of 3.1? it will be very beneficial.

[spring-projects-issues]

Marcel Overdijk commented

@Stephen: I hope so. This issue is 8th on the list of top voted issues, so probably will get attention and implementation one day :-)

[spring-projects-issues]

Clemens Fuchslocher commented

The spring-mvc-showcase from Keith Donald contains an implementation of a custom flash scope in the package org.springframework.mvc.extensions.flash.

$ git clone 'https://github.com/SpringSource/spring-mvc-showcase.git'
$ cd spring-mvc-showcase
$ mvn tomcat:run
$ firefox http://localhost:8080/spring-mvc-showcase/

It is used in the FormController example to save a success message if JavaScript is disabled.

The FlashMapFilter adds all elements of the FlashMap to the request scope of the next request. The elements of the FlashMap are saved in the session.

There is one drawback with this implementation: One FlashScope per session could be a problem if the user works with multiple browser windows or tabs at the same time. For example, Stripes uses an additional parameter to distinguish between multiple flash scopes:

How FlashScope works

The FlashScope works by temporarily storing instances of itself in Session, and removing them on subsequent requests. As a result, when a FlashScope is used, an additional parameter is appended to redirect URLs to tell Stripes which FlashScope to use. Because of this parameter two or more browser windows (or tabs) in the same session will never get confused and access each others' FlashScopes.
...

[spring-projects-issues]

Rossen Stoyanchev commented

Flash attribute support is now available. The javadoc for FlashMap and FlashMapManager provides an overview of the underlying support for flash attributes in Spring MVC while RedirectAttributes describes how to add flash attributes in annotated controllers. If you have the latest source checked out, I recommend reviewing the updated reference documentation starting with "What's New In 3.1".

To answer some of the specific questions raised above:

Will this flash implementation storing mvc messages and retrieving them using the spring:messages tags?

Flash attributes are automatically merged into the model and are therefore available for rendering.

Will it support storing ModelAttributes for passing a ModelAttribute across a redirect? Similar to @SessionAttribute but just for the redirect?

@SessionAttribute is probably a better candidate for passing an @ModelAttribute across controller methods; however, you can also also use the RedirectAttributes argument add any attribute as a flash attribute and have it survive across a specific redirect.

One FlashScope per session could be a problem if the user works with multiple browser windows or tabs at the same time.

We've taken a slightly different approach. Rather than adding a framework-specific generated key, RedirectView "stamps" FlashMap instances with the path and query params of the target redirect URL, which are then checked after the redirect. This is somewhat similar but is based on information already present in the redirect URL. This approach will address most issues like polling from another tab or resource requests but won't eliminate the possibility of collisions entirely. Specifically there is no support for multiple windows. That said if flash attributes are used in redirect scenarios only such collisions are much less likely. Furthermore, given that we already filter based on the query params of redirect URLs, it would be a small step to add a generated query param to the redirect URL if required.