I'm not sure I understand your patch. What is the nature of changing "old" to "read"?
The solution that appeals to me is a special request attribute that prevents flash messages from being deleted for the duration of that request. This way we can specify that a request should not delete flash message simply by adding a default value to the route. I'm not sure what the name of that attribute would be… _internal? This would probably mean moving the __destruct() method from Session to Request and encapsulating the conditional delete of flash values there. Having the request be in charge of this makes more semantic sense anyway and makes the session class less magical. How does that solution sound to everyone? Thanks, k On Friday, February 25, 2011 at 6:07 AM, John Wards wrote: > Okay I've refactored Session to do on read. > > Not to everyones taste, but saying not to do something because that is > what people are used to in sf1 is probably not the best argument not > to do something. > > Here is my commit: > > https://github.com/johnwards/symfony/commit/1f2eac7197fa07630e9d95627fc0d72dc58fea75 > > I have not done a pull request and won't unless I'm told too.. > > > On Fri, Feb 25, 2011 at 1:57 PM, Jeremy Mikola <[email protected]> wrote: > > I think this is definitely a web profiler shortcoming, but I would not > > advocate having flash messages persist in the session until they're read. > > That's a fundamental difference from how they work currently, and what every > > Symfony1 developer is familiar with. > > > > At OpenSky, we implemented a getAttributeOnce() method on the session, which > > essentially checks if the attribute exists, and if it does it gets it, > > removes it, and returns the value it "got". I seem to remember that > > existing in Symfony1, unless I'm mistaken. Regardless of whether the WDT > > destroys flash messages, we've found a method like this useful. > > > > On Fri, Feb 25, 2011 at 7:51 AM, Jordi Boggiano <[email protected]> wrote: > > > > > > On 25.02.2011 13:41, John Wards wrote: > > > > I see two solutions here... > > > > > > > > 1) Web profiler reads out all flash messages and and re adds them. > > > > (Feels hacky) > > > > 2) Flash messages are only removed on read. > > > > > > > > First option seems really simple, second option not so simple. > > > > > > > > Opinions? I'm going to hack something together for the first option as > > > > I need to seem my flash messages and the toolbar data at the moment. > > > > But my preference is for the second option. > > > > > > See also: > > > > > > > > > https://github.com/fabpot/symfony/commit/28bf834c0c7845a3a9fc9605e0e35c99e1475a6b#commitcomment-283201 > > > > > > For the problem you mention, second solution seems best. For my other > > > problem in my commit comment, I guess we should just suppress the > > > toolbar entirely if what the AJAX call returns isn't a proper toolbar. > > > > > > The other quickfix is to just revert for now, and see later. > > > > > > Cheers > > > > > > -- > > > Jordi Boggiano > > > @seldaek :: http://seld.be/ > > > > > > -- > > > If you want to report a vulnerability issue on symfony, please send it to > > > security at symfony-project.com > > > > > > You received this message because you are subscribed to the Google > > > Groups "symfony developers" group. > > > To post to this group, send email to [email protected] > > > To unsubscribe from this group, send email to > > > [email protected] > > > For more options, visit this group at > > > http://groups.google.com/group/symfony-devs?hl=en > > > > > > > > -- > > jeremy mikola > > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > > security at symfony-project.com > > > > You received this message because you are subscribed to the Google > > Groups "symfony developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/symfony-devs?hl=en > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
