Flash messages

Matt Savage

unread,

Dec 17, 2012, 3:52:04 PM12/17/12

to utter...@googlegroups.com

I've got a naive implementation of flash messages working in satisfyingly few lines of code.

Here's the unit test.

At the moment the flash cookie gets cleared in the response if all of these conditions are met:

The response is 2xx
InternalRequestMarker says the request wasn't internal
The media type is text/html or application/xhtml+xml

I'm not so sure about the last condition, but ClearFlashPredicate is at least pluggable so you can override it or decorate it yourself.

Does anyone see any problem with these rules? Rails makes you explicitly state that you want to hold on to the flash over a redirect. I wanted to avoid that complexity. You can always implement your own version if you need different logic- it's only 4 classes.

Is there a better way to do it? I was considering triggering deletion of values in Flash by explicitly consuming them, but didn't want to over-complicate it.

Flash is a Model internally, so you can customise to your heart's content. An obvious extension is to have an "includes" value and using that to include more complex messages in your decorator so I didn't have to make sure messages and errors are added as lists.

I'm not happy with Flash class at the moment. Suggestions for clean up are gratefully received. In other, familiar news: I wish StringTemplate let you iterate over single values.

At the moment, I'm doing this in my default decorator:

$include.("/messages").body;format="raw"$

messages.st looks like this:

<html>

<head>

<title>Flash Messages</title>

</head>

<body>

<div>

$messages:{message |

<div class="alert alert-success">$message$</div>

}$

$errors:{error |

<div class="alert alert-error">$error$</div>

}$

</div>

</body>

</html>

Matt Savage

unread,

Dec 17, 2012, 4:34:30 PM12/17/12

to utter...@googlegroups.com

Also, Albert- I'm aware I owe you a push to trunk for the abstraction of Action for your clojure bindings.

I'll get to that over the next few days. I wanted to let the code settle before I pushed, which it has now.

Albert Latacz

unread,

Dec 17, 2012, 5:25:32 PM12/17/12

to utter...@googlegroups.com

Cool, looking forward to the push. Flash cookies were next on the "porting my app to UI" list so double joy :D. Bit naively thinking.. As I only used single request flash without redirect, is redirect frequent use case?

Albert

Matt Savage

unread,

Dec 17, 2012, 5:31:21 PM12/17/12

to utter...@googlegroups.com

Because I generally do post-redirect-get, there's generally at least one redirect before I display the message.

Make sense?

Albert Latacz

unread,

Dec 17, 2012, 5:40:54 PM12/17/12

to utter...@googlegroups.com

Yes <red face> Now looking more at it I was using explicit get to clear session-bound flash. Thanks.

Matt Savage

unread,

Dec 17, 2012, 6:25:04 PM12/17/12

to utter...@googlegroups.com

:)

Raymond Barlow

unread,

Dec 19, 2012, 4:50:41 PM12/19/12

to utter...@googlegroups.com

Hey Matt,

Your Flash messages look, er, flash!

We've currently done messages differently in BaronGreenback & the app at work. I'm keen to have a go at integrating Flash Messages into BaronGreenback (replacing any existing message strategy that we have there).

I vote to have the Flash Messages merged back into UtterlyIdle. Then I can try it. Or, I could switch UI to using your abstractions version for now while I play. What do you think?

/Raymond

On 17 December 2012 20:52, Matt Savage <matthew...@gmail.com> wrote:

Daniel Worthington-Bodart

unread,

Dec 19, 2012, 5:51:30 PM12/19/12

to utter...@googlegroups.com

I've been thinking that we should not have a predicate for when to remove the flash message but make it a 'pop' operation. So it stats roll you pop it on the client or server

Stuart Miller

unread,

Dec 19, 2012, 6:11:05 PM12/19/12

to utter...@googlegroups.com

I suppose the advantage of having it automatically remove itself is you never get an 'old' flashed message coming back from the dead. I could forsee a situation where the pop doesn't happen and you get a strange notification on an unrelated page.

Daniel Worthington-Bodart

unread,

Dec 19, 2012, 7:07:01 PM12/19/12

to utterlyidle

Well it's a trade off for sure, do you want a missed update or a late update? But I suppose that flash messages tend to not matter if they are never received

Xuemin Guan

unread,

Jun 18, 2014, 6:27:48 AM6/18/14

to utter...@googlegroups.com

hi mate, I'm trying to understand how to use the flash cookie, I have code like this:

Flash validationErrors = new Flash().add("validationErrors", "You are too awesome for us."));

then I want to do a redirect. How do I add this flash cookie to the redirect response?

regards,

Xuemin

Xuemin Guan

unread,

Jun 18, 2014, 6:31:04 AM6/18/14

to utter...@googlegroups.com

I'm looking at your unit test, there is a line:

request.cookie(FLASH_COOKIE, flash);

This is how you set a cookie as a flash cookie, isn't?

Xuemin

On Monday, 17 December 2012 20:52:04 UTC, Matt Savage wrote:

Xuemin Guan

unread,

Jun 18, 2014, 6:33:06 AM6/18/14

to utter...@googlegroups.com

sorry for the spams... I think I got it by looking at the unit test closely.

thanks and apologies.

Xuemin

On Monday, 17 December 2012 20:52:04 UTC, Matt Savage wrote:

Matt Savage

unread,

Jun 18, 2014, 7:57:15 AM6/18/14

to utterlyidle

Happy to help :)

Stu's had some interesting problems with the naive flash cookie stuff and I think they've rolled their own.

Stu- care to explain?

--
You received this message because you are subscribed to the Google Groups "utterlyidle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to utterlyidle...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Stuart Miller

unread,

Jun 18, 2014, 5:46:30 PM6/18/14

to utter...@googlegroups.com

We were abusing the flash message scope to send messages to the client. These messages had to be acknowledged by the client to be cleared, so we never used the expiration policy (can't remember what it's called now), and instead nuked the cookie via JS when we'd dealt with it.

In the end, I concluded the only thing we had in similarity with a flash scope was the fact it was sending data via a cookie, so we stopped the pretence and rolled our own to do exactly what we needed to :)

Xuemin Guan

unread,

Jun 19, 2014, 2:50:49 AM6/19/14

to utter...@googlegroups.com, utter...@googlegroups.com

Hi Stu and Matt, thanks a lot for sharing your experience! It's much appreciated.

We are using the Flash cookie for displaying form validation errors. It works well for us. But in a long run, I like Dan's idea of treating forms as documents and store them in a persistence storage when validation fails, instead of using cookie. I used this pattern in the past, it worked well.

Thanks for sharing

Xuemin

—
Sent from Mailbox

Mike Hogan

unread,

Jun 19, 2014, 3:47:41 AM6/19/14

to utter...@googlegroups.com

On 19 Jun 2014, at 07:50, Xuemin Guan <gxu...@gmail.com> wrote:

> But in a long run, I like Dan's idea of treating forms as documents and store them in a persistence storage when validation fails, instead of using cookie. I used this pattern in the past, it worked well.

Xuemin, can you elaborate...

Daniel Worthington-Bodart

unread,

Jun 19, 2014, 3:49:18 AM6/19/14

to utterlyidle

I've been thinking about this more and maybe the best solutions is to have 2 types of architecture.

Content oriented resources or Urls that:

probably GET only or idempotent POSTs that are just POSTs to satisfy privacy or data size,
no form validation (There is no such thing as an invalid search just no results)
POST would redirect to a search result document (I'd probably just hash the input so you would get caching etc)
think get me this content GET "/document/1234" or find me this content POST "/search?query=1234" ,
this could obviously be static or dynamic but errors are handled by status codes and/and messages in the content.
What's seriously cool is that you could actually push search results to say S3 and make paging generate the next page. It would be so FAST at the cost of loads of tiny documents on S3
These would support SEO and do rendering on the server (or pre render and push to S3)

API oriented resources (GET, POST, PUT, DELETE). Probable processing JSON etc. These would probably be driven by your favourite Javascript framework like D3 / React in the browser or if doing server to server just your favourite language.

Utterlyidle would be great for both of these things. However for doing form oriented resources I think Utterlyidle doesn't really give to much from a batteries included point of view. It's okay but you have to write quite a lot yourself (and not in a good way)

Reply all

Reply to author

Forward