On 25.02.2011, at 22:18, Lukas Kahwe Smith wrote:

> 
> On 25.02.2011, at 15:25, Kris Wallsmith 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?
> 
> adding a different pov:
> you can argue in both directions.
> one can also say that adding a new redirection step could easily lead to 
> flash messages getting lost.
> furthermore its easily to call clearFlashes().
> 
> common ground:
> i think its clear that if all goes well one can create working applications 
> with either mode: delete on the next request (which would of course require 
> some additional handling for internal routes and intentional redirects to 
> easily carry over the flash for another request) as well as the delete on 
> read.
> 
> so really we are talking more about what is the more maintainable approach 
> and also which approach is better in case someone does a mistake.
> 
> my final opinion:
> is there a good use case for flash messages being removed without being read 
> once? and aren't those use cases better served with clearFlash()? also if my 
> app screws up its probably still better when in doubt to show a flash 
> messages too many than to drop one unintentionally, therefore i prefer the 
> mode of removing on read.


FYI there is a pull request to fix the dev mode flash issue using the current 
approach:
https://github.com/symfony/symfony/pull/176

Also wondering if there is anything in the flash API where we should think 
about forwards compatibility with:
http://www.w3.org/2010/web-notifications/

regards,
Lukas Kahwe Smith
[email protected]



-- 
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

Reply via email to