FlashMapSupport works?

[Dustin Withers]

No matter how I try I cannot seem to get the FlashMap support working.
It seems simple enough and I've looked through the source but can't
seem to quite understand what is happening there. I think I may need
to initialize a session? The session variable works fine though.

https://gist.github.com/985761

[Ross A. Baker]

https://gist.github.com/986303 works for me. I commented out the
DatabaseInit and DatabaseSessionSupport and guessed what your
login.ssp might look like. Are your database traits using the
session? Does your template look significantly different from mine?

--
Ross A. Baker
ba...@alumni.indiana.edu
Indianapolis, IN, USA

[Dustin Withers]

Ross,

Thanks so much for your help so far. I think, I've figured out what
the problem is but I don't know how to go about fixing it. I have two
ScalatraFilters in this project. Both bound to different URL's in my
web.xml. If I remove one of the ScalatraFilters from the web.xml the
FlashMap functionality starts working. Should I not be defining
multiple ScalatraFilters? Is there another way to break code up that
might not cause this issue with FlashMap

Thanks,
-dustin

On May 23, 1:13 am, "Ross A. Baker" <ba...@alumni.indiana.edu> wrote:
> https://gist.github.com/986303works for me.  I commented out the

> DatabaseInit and DatabaseSessionSupport and guessed what your
> login.ssp might look like.  Are your database traits using the
> session?  Does your template look significantly different from mine?
>

[Dustin Withers]

This morning it dawned on me that I could turn one of the Filters into
a trait and extend the other filter with it. Now my web.xml is only
using one Filter and things are working correctly. Is this a valid way
to break sections of a site up?

Thanks,
-dustin

On May 24, 12:52 am, Dustin Withers <fadedd...@gmail.com> wrote:
> Ross,
>
> Thanks so much for your help so far. I think, I've figured out what
> the problem is but I don't know how to go about fixing it. I have two
> ScalatraFilters in this project. Both bound to different URL's in my
> web.xml. If I remove one of the ScalatraFilters from the web.xml the
> FlashMap functionality starts working. Should I not be defining
> multiple ScalatraFilters? Is there another way to break code up that
> might not cause this issue with FlashMap
>
> Thanks,
> -dustin
>
> On May 23, 1:13 am, "Ross A. Baker" <ba...@alumni.indiana.edu> wrote:
>
>
>
>
>
>
>

> >https://gist.github.com/986303worksfor me.  I commented out the

[Ross A. Baker]

Ah, you're running into
https://github.com/scalatra/scalatra/issues/41. It should work on the
latest snapshot. I plan on tagging another milestone just after
Scalate releases for 2.9.0, which should be soon.

[Craig Blake]

I have two filters that handle different parts of a webapp (public pages and private pages respectively). When redirecting from one filter to another, the flash entries are not accessible.

From looking at the code I think that this is intentional, but wanted to double check that it's not a bug. If not, if there a way to share a flash context between filters or is it recommended to use a single filter for everything?

Thanks,
Craig

[Ross A. Baker]

That sounds like another flavor of
https://github.com/scalatra/scalatra/issues/41. If you're still on
M3, try the latest snapshot.

Multiple filters are reasonable. Some other options to split your
routes are discussed at
http://groups.google.com/group/scalatra-user/browse_thread/thread/ab3a097f7aea4686.

[Craig Blake]

Sorry, I forgot to mention that I am seeing this behavior with the latest trunk (2.0.0-SNAPSHOT).

Thanks,
Craig

[Craig Blake]

Actually this appears to be more acute than I thought. The flash context does not appear to be storing anything I put into it:

get (Login) {
flash += ("error" -> "this is an error")
info("flash is empty: " + flash.isEmpty)
.
.
.
}

...results in "flash is empty: true" in the log output.

Any ideas?

Thanks,
Craig

On Jun 7, 2011, at 1:52 PM, Ross A. Baker wrote:

[Ross A. Baker]

Flash updates are visible to the next request, not the current request:

scala> val flash = new FlashMap("demo")
flash: org.scalatra.FlashMap = Map()

scala> flash += ("error" -> "this is an error")
res7: flash.type = Map()

scala> flash.get("error")
res8: Option[Any] = None

scala> flash.sweep()

scala> flash.get("error")
res10: Option[Any] = Some(this is an error)

To make it visible for this request, you can use flash.now:

scala> val flash = new FlashMap("demo")
flash: org.scalatra.FlashMap = Map()

scala> flash.now += ("error" -> "this is an error")
res11: scala.collection.mutable.Map[String,Any] = Map(error -> this is an error)

scala> flash.get("error")
res12: Option[Any] = Some(this is an error)

scala> flash.sweep()

scala> flash.get("error")
res14: Option[Any] = None

There are a lot of flash implementations for Ruby, so the right
default behavior is highly debatable. Comments welcome, especially if
someone has an extensive Sinatra + flash scope background.

[Craig Blake]

Ah, ok. Didn't see it noted anywhere in the docs so it threw me off while trying to debug.

I've used the flash scope previously in Grails, where (if I remember correctly) values set are available for both the current request and the next one. This makes sense to me since the component setting the message may not always know if the next page will be rendered vs. redirected. Are there many cases where the alternative (only visible in the next request) is helpful or necessary?

Cheers,
Craig

[Ross A. Baker]

No, I can't think of any advantage to hiding it from the current
request. I remember looking at both Rack::Flash and Rails during
implementation, but both of them appear to work the way you describe.
I think we should change it.

[Ross A. Baker]

I just pushed some breaking changes to FlashMapSupport to make it
behave more like other frameworks, specifically Rack::Flash.

Summary:
1) Flash entries are now available to the current request as well as the next.
2) Entries will not be swept until they are read, unless you override
sweepUnusedFlashEntries.

Details:
https://github.com/scalatra/scalatra/commit/8a66ee58e59709c5068ccf19ded6c5682fb4c106
https://github.com/scalatra/scalatra/commit/743d748328377edc5db1280289f7f459e7859993