On 24/01/12 19:19, Gurunandan Bhat wrote:
I would have used sessions if these shared variables typically represented "client states". Unfortunately these variables describe the state of the server (its filesystem for example) and I believe that they are best implemented insulated from sessions which are more suited to client-side stuff.
I do not look to Dancer code for some time, but I almost sure that vars are not preserved across requests.
So, the solution would be to declare your own global hash table for keep that information.
Cheers ambs
But if there was an error in my logic, I would certainly consider using sessions Thanks On Wed, Jan 25, 2012 at 12:44 AM, damien krotkine <[email protected] <mailto:[email protected]>> wrote: Don't you want to use sessions to do these sort of things ? On 24 January 2012 20:07, Gurunandan Bhat <[email protected] <mailto:[email protected]>> wrote: > Hi, > > I was wondering about the issues using a shared variable in a single App.pm > file. Here is what I mean: > > package App.pm > > my $var; > > // Initialize $var; > ..... > > Route1 => sub { > > // Modify $var > ... > } > > Route2 => sub { > > // Use $var > ... > } > > I first call Route1 then when I call Route 2, I expect that I will have the > modified value (by Route 1) of $var in route 2. Unfortunately I get an > undefined value for $var. > > Can someone more experienced than I, see if I am doing something obviously > incorrect? > > Thank you > > Regards. > > > _______________________________________________ > Dancer-users mailing list > [email protected] <mailto:[email protected]> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users > _______________________________________________ Dancer-users mailing list [email protected] http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list [email protected] http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
