Would that basically replace the $type parameter of the handle() method? Kind regards, Johannes
On Fri, Feb 25, 2011 at 3:25 PM, Kris Wallsmith < [email protected]> wrote: > 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 > -- 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
