On 3/11/11 8:55 AM, Lukas Kahwe Smith wrote:
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
The semantic of the flash feature is that flashes are persisted only for
the very next request. This behavior cannot be changed because all other
frameworks (including symfony1) have this very same behavior.
I will work on a patch or merge the PR.
Fabien
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
