Thanks for your prompt attention. Unfortunately I am unable to
reproduce the original error. I may have been doing something wrong
as I'm new to Dancer.
To address the changes you made to the Plugin, I think we're moving in
the right direction. However, here is how I think of flash messages
and how they should work. If I'm not thinking of this correctly,
please tell me.
A user submits a form. We want to process the form and send a message
back to the user that the form was processed successfully. We
typically don't want to have the success message on the same page as
the form processing because it's too easy to accidentally press reload
and resubmit the data. So the normal pattern we use is:
show a form
user posts to /process
/process processes the form, sets a flash message, and then forwards
the user to /something-else
since the flash message is saved in a session, it's available on
/something-else even though it's a separate request
/something-else shows the flash message, and then importantly, deletes
the flash message from the session so it doesn't get shown again
I like to have "global" handling of flash messages. (I've typically
done this myself using CGI::Application). This means that the flash
messages should only ever be shown once but that they should only be
deleted when we're sure they were shown. So for my Dancer app I'm
working on I made a before_template hook to delete the flash message.
This isn't ideal because it's not guaranteed that every time I show a
template it's the "layout" which has the flash message handling.
I'm not familiar with writing Dancer plugins but it seems like the
most useful case would be to, instead of just providing the data to
the template, maybe provide a function to the template. When called,
the function would fetch the message from the session and then delete
it from the session and then return it. That way, I wouldn't have to
have any extra logic to try to figure out whether it's shown. The
perl logic looks something like this, I'm not sure how to make that
work with template::toolkit or whatever:
if(my $warning = flash('warning')) {
show_warning($warning);
}
In order to please template::toolkit or others, it may be that we need
two functions, something like flash_exists('warning') and then the
flash('warning') itself. With those, the logic for showing flash
messages and deleting them from the session will reside solely in the
plugin and the template. In the application logic, all we have to do
is set the flash message and then the rest is taken care of
automatically.
On Sun, Jan 23, 2011 at 10:28 AM, Damien Krotkine via RT
<bug-Dancer-Plugin-FlashMessage@rt.cpan.org> wrote:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=65009 >
>
> Hi,
>
> thanks for your bug report.
>
> I have fixed the persistence issue. Now by default flash messages are not persistent : they are
> removed from the session at the end of the request.
>
> Note that it's at the end of the request, not just after the first template has been issued. You
> can potentially do more than one view or layout rendering in the same request. They would
> all see the flash message. At the end of the request however, the flash messages hash is
> removed.
>
> That is, unless you override the default, and set 'persistence' to a true value in the
> configuration.
>
> I've juste pushed version 0.305 which implements all that. Let me know if it works for you.
>
> About your troubles at the beginning of your bug report : what was the issue ? Even if you
> figured it out, I'd be interested to know if I could make it easier for user to make it work,
> maybe by updating the doc.
>
> Thanks,
> dams
>
