My blog is where I keep my notes. Most of the time updates will happen in bursts of activity. All links go offsite to blog.leecarmichael.com at Blogger since Google has a very good service.
I just came across a test like:
And of course, it was silently doing something/nothing/everything. I'd guess most experience Perl coders will notice that the eval will only run the test if the request doesn't throw an exception. Which might be kind of ok but there is no catch or check of the $@ later.
If a check is added for $@ later, it will make the test pattern pretty messy
Please don't write this type of test. Please.
Instead use Test::Exception and drop into a sub. Something along the lines of:This is better for a couple of reasons:
A few weeks on #dancer channel, a user was having issues using Dancer::Session::PSGI. I've never worked directly with Plack besides reading the handbook and few play apps. (well a few weeks ago, I dug into Dancer::Debug.). Using both together was an intriguing problem stuck in my mind.
The person on the channel was reporting unreliable reading of session data and other odd behavior. As I started to dig into the problem, I realized that i need to create two apps, one pure Plack and one Dancer with middleware wrapper. I created a public repo on github with my test apps: Dancer and Plack session.
Since, I didn't want to deal with html and wanted a bit of structure with return data, I made both test apps return JSON and have pretty simple routes
Next I created a Test Dancer PSGI app, which basically had a way to show value and update it. Here is the non-exciting Dancer app:
I updated bin/app.pl to use Plack::Builder directly instead of creating a wrapper (which I'd like to try as well probably in a branch):
With those all setup, I started both apps using plackup but each with slightly different command lines:
magic-bus> plackup pure_plack/bin/app.psgi &
magic-bus> plackup -p 3000 dancer_plack_session/bin/app.pl &
I created a curl_cookie script to use and store cookies and verbose dump out request/response information. I needed to see what cookies where getting sent in and back.
After i fired up each app server, the first set of requests dumped the following:
Well that is odd. A couple quick bullets:
The initial session being created to the first request to Dancer not finding the existing plack session information. After that initial request, then it would pick up plack session data. The current behavior would lead to this confusing response the 2nd time from Dancer app:
"visits" : 2
I fixed up Dancer::Session::Abstract to use 'plack_session' cookie and that resolved the session not getting read on initial request.
A bit unexpectedly, I see that Dancer is setting cookie with different session id than PSGI. PSGI includes its own session cookie. This is expected since the Plack middleware runs after Dancer (think of the onion from handbook: ).
Here is example of response made to Dancer app:
In the end its working now. Dancer is able to pull in session information from Plack session but its still a bit messy. I'm not sure if multiple session cookies is considered a bug or not. I think it might be best to have Dancer not do any cookie stuff and only use the session data if its available in the environment but looking over the Dancer session code, this doesn't look straightforward w/out major changes to core Dancer code.
Any ideas out there?__END__
The template engine configuration directive supports passing through various options like start_tag and stop_tag as explained in Dancer::Template::TemplateToolkit POD. And alludes to being able to pass other options.
To pass TT options like those found in Template::Constants, there must be a DEBUG section in engines -> template_toolkit, usually found in config.yml.
Here is an example:
sudo yum list installed