On Thu, Feb 13, 2014 at 11:37 PM, Warren Young <warren@etr-usa.com> wrote:
I tried passing the return value of session() into a function in another module which purposely does not "use Dancer". Thus, I cannot use the global DSL functions without explicit qualification.
This other module modifies the session object, so the code looked something like this:
package App::Helper;
sub do_something_interesting { my ($session) = @_;
$session->{foo} = 'bar'; # ... and lots more like that }
To my surprise, I found that in the calling route handler...
get '/myroute' => sub { do_something_interesting(session());
session 'more' => 'changes here'; }
...the changes to the session object made by the helper module got lost.
I finally tracked it down to the fact that session(X, Y) automatically calls flush() on the object for you, whereas session() with no parameters returns a hashref that doesn't auto-flush itself.
On one level, I guess live and learn. But, is it good design for Dancer to simply forget all my changes? Why doesn't the second line in my route handler simply continue to modify the in-memory session object, and flush all the changes at once?
It does not make sense to me that calling session() as a getter (as opposed to a setter) should write out the session on each access. To do that would probably require using Tie::Hash to have it invoke flush() on every modification of the hash. I'm not sure if that extra complexity is worth the benefit. -Naveed Massjouni