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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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? On Friday, September 7, 2012 at 2:14 PM, George Ogata wrote:> 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 > > -- > 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, Sep 7, 2012 at 2:22 PM, Prem Sichanugrist <sikandsak@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.) -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, Sep 7, 2012 at 4:02 PM, Robert Pankowecki < robert.pankowecki@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 :searchSomething 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. :) -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> 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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, Sep 7, 2012 at 5:15 PM, Robert Pankowecki < robert.pankowecki@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. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, Sep 7, 2012 at 2:32 PM, George Ogata <george.ogata@gmail.com> wrote:> On Fri, Sep 7, 2012 at 5:15 PM, Robert Pankowecki < > robert.pankowecki@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. >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 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.