Is flash.now necessary?

[George Ogata]

Typically I find the rule of thumb is:

 * If you're rendering, set flash.now.

 * If you're redirecting, set flash.

Is there ever a case where this is not what is wanted?

And if not, could this be automatic? i.e. sweep the flash if and only if not redirecting.

(Happy to do the grunt work - just wanted feedback before putting in the time. :-)

Thanks!

George

[Prem Sichanugrist]

It used to be the fact that if you set flash[:notice] and try to render the page, the flash message will not be displayed. That's why they have to implement `flash.now`. Is that still the case?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

[George Ogata]

On Fri, Sep 7, 2012 at 2:22 PM, Prem Sichanugrist <sika...@gmail.com> wrote:

It used to be the fact that if you set flash[:notice] and try to render the page, the flash message will not be displayed. That's why they have to implement `flash.now`. Is that still the case?

Currently if you set flash[:notice] and render, it's available both in this request during the render, and in the next request.

With what I'm proposing, flash[:notice] would only be available in this request. If you redirect, rather than render, it would be available next request. (And flash.now goes away.)

[Robert Pankowecki]

I sometimes use flash to keep things between multiple request ex.
searched word and use FlashHash#keep in before filter to keep it when
user is still using the same controller. How can I keep something for
the next request when rendering in your proposed solution? Would I
have to set flash and keep it in the same request ?

flash[:keyword] = "searched term"
flash.keep :keyword
render :search

[George Ogata]

On Fri, Sep 7, 2012 at 4:02 PM, Robert Pankowecki <robert.p...@gmail.com> wrote:

I sometimes use flash to keep things between multiple request ex.
searched word and use FlashHash#keep in before filter to keep it when
user is still using the same controller.

Can you provide more info on what you're doing with this searched word? Highlighting?

My initial reaction is it's a dubious practice, because it relies on the user visiting the same controller action in the next request. If they open a page in another tab, for instance, it'd get messed up.

I'd usually favor embedding that parameter in the form for the next request (e.g., for a search form, prepopulate the query box with the searched word). If you want it to persist for longer, then perhaps cookie/session storage makes more sense.

How can I keep something for
the next request when rendering in your proposed solution? Would I
have to set flash and keep it in the same request ?

flash[:keyword] = "searched term"
flash.keep :keyword
render :search 

Something like that. Or even:

    flash.keep[:keyword] = 'searched term'

i.e., keep the common case clean, at the expense of making the unusual case a bit more work.

Thanks for your input. :)

[Robert Pankowecki]

> Can you provide more info on what you're doing with this searched word?
> Highlighting?

I was just using it for coherent navigation. You could go like search
=> show => edit => update => index and see the list filtered with the
searched keyword.

> My initial reaction is it's a dubious practice, because it relies on the
> user visiting the same controller action in the next request.

Well, that was exactly my point. I expected the user to visit same controller.

> If they open a
> page in another tab, for instance, it'd get messed up.

Unfortunately true.

> I'd usually favor embedding that parameter in the form for the next request
> (e.g., for a search form, prepopulate the query box with the searched word).
> If you want it to persist for longer, then perhaps cookie/session storage
> makes more sense.

cookie/session store has exactly the same problem as flash (in another
tab). In fact flash is stored in session. It is a serialized hash. The
only solution for doing it right is to keep that searched word in url.
But that requires you to write some abstraction over link_to or
remember to add additional parameter to every possible link_to that is
leading to same controller. Cumbersome.

>> How can I keep something for
>> the next request when rendering in your proposed solution? Would I
>> have to set flash and keep it in the same request ?
>>
>> flash[:keyword] = "searched term"
>> flash.keep :keyword
>> render :search
>
>
> Something like that. Or even:
>
> flash.keep[:keyword] = 'searched term'

Works fine for me.

> i.e., keep the common case clean, at the expense of making the unusual case
> a bit more work.

I agree. Just didn't want the unusual case to be impossible after some
refactoring.

> Thanks for your input. :)

You are welcome.

Robert Pankowecki

[George Ogata]

On Fri, Sep 7, 2012 at 5:15 PM, Robert Pankowecki <robert.p...@gmail.com> wrote:

> Can you provide more info on what you're doing with this searched word?
> Highlighting?

I was just using it for coherent navigation. You could go like search
=> show => edit => update => index and see the list filtered with the
searched keyword.

Understood. I wonder if a cookie scoped to that path would be another alternative - shouldn't be affected by other tabs, at least.

> i.e., keep the common case clean, at the expense of making the unusual case

> a bit more work.

I agree. Just didn't want the unusual case to be impossible after some
refactoring.

Cool - totally valid point.

[gha...@gmail.com]

If someone is considering re-working flash message behavior, I'd like to throw in my +1. I previously encountered issues with them (Some examples of bugs: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4082-flash-loses-messages-on-redirect ) and landed on a solution much like George Ogata describes, which is simple to implement and much less error-prone. flash[:foo] is saved only for the duration of a request if rendering occurs, but contents are stored if a redirect occurs. 

-Greg