Notes, How Tos, Things To Remember, Things I'll soon forget

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 I started off using the documentation from Plack::Middleware::Session to create this test app : 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 ...

Bring together the parts I was able to find complete documentation on running dancer  with nginx using FastCGI. In the dancer deployment  it discusses using Apache and fastcgi or nginx with proxy. Often, using nginx as proxy to starman(or some other plack webserver) is probably the right thing. But sometimes using fastcgi is good idea too :) I'm running some benchmarks but it seems like memory usage is a bit smaller with FCGI but I still need to do more digging on this. Make it so Lets get all the parts install and then configure them Install the Parts Note: These parts will be very dependent on your system. I'm assuming a debian/ubuntu system below. First you need to have nginx and dancer installed. For nginx i would recommend doing something like: apt-get install nginx or building and install from source.  Next, install need Perl modules: cpanm + Dancer's Makefile.PL I like to install using Dancer's app generated Makefile.PL along with cpanm ...

Dancer does lots of great things. It has a nice clean way to define routes to handle AJAX routes using the plugin Dancer::Plugin::Ajax . ajax routes are defined in a clear way: ajax '/stuff' => sub { # do work and return }; This plugin technique allows for clear way to separate between ajax and other types of actions for the same route. ajax '/stuff' => sub { # do ajax-y stuff here }; get '/stuff' => sub { # handle html response }; Unfortunately, the one negative with Dancer::Plugin::Ajax is that is assumes all responses will be XML. A quick fix is to manually set the content type in each ajax handler. ajax '/stuff' => sub { content_type('application/json'); # do work }; or add set it as a general option in your main before hook or in each prefix route handler like: package WebApp; hook before => sub { if ( request->is_ajax ) { content_type('application/json'); } }; ...

As I was working on a small application that allowed editing of pages, I really wanted to grab the referring page to redirect after the page was updated or the edit session was cancelled by the user. It wasn't very clear to me how to grab the referer from Dancer 's POD documentation on Dancer::Request . Basically I could grab it either of 2 ways. request->referer - nice. This applies to other env options as well forwarded_for_address which pulls in X_FORWARDED_FOR request->env->{HTTP_REFERER} - feels more lower level. I read the documentation as request->env->{referer} which is not correct at all. In the end it is much easier and I think prettier than the several options I tried :) __END__

Often SOAP::Lite will try to autotype a parameter in a request and it does it wrongly (or correctly) causing the SOAP server to fail badly (for so many reasons). SOAP::Lite provides three ways to disable this typing. Two of the ways work at the client object level and the other does it at the SOAP::Data object level. Client Level The following options disable autotyping for all data items in a request: autotype method. After creating a SOAP::Lite client you can disable autotyping by $soapclient->autotype(0) . Example: my $soap = SOAP::Lite->uri($xmlns)->proxy($proxy) ->on_action( sub {"$action?type=$reqname&ns=$xmlns"} ); $soap->autotype(0); Overriding the typelookup method. You can override the typelookup to run undef/false/etc. Example: sub typelookup { return undef; } Data object SOAP::Data object provide a type method. This allows manually typing of the object. When this is set to an empty string no type is set nor is it autotyped by serializer. No...

Sometimes I just want to save the xml versions of the SOAP requests and responses (generally to share with someone else). The SOAP::Lite perldoc page points to using SOAP::Trace . It has lots of good stuff but its a bit heavy. And in my case, I'm trying to figure out how to log response and requests over http so the following will hopefully help simplify my next search. :) here is my approach, first the code (all good things start in code :) : package SOAP::HTTP::Logging; use warnings; use strict; use Exporter; our @EXPORT = qw( enable_logging disable_logging soap_log_file log_message ); our $logfile; our $logboth = 0; our $log_request = 0; our $log_response = 0; # setup global options sub enable_logging { $log_request = $log_response = 1; } sub disable_logging { $log_request = $log_response = 0; } sub soap_log_file { $logfile = shift if @_; return $logfile; } # logging sub sub log_message { my $in = shift; # SOAP::Lite pushes in the object its called on # only log ...

Template Toolkit has a very cool feature called Virtual Methods . It provide methods on native Perl5 data types. An example is this (In TT syntax): [% listy = [ 47, -47, 42, -55, 4, -24 ] %] [% listy.size %] [% listy.join(', ') %] Often its called autoboxing . Well TT allows you to define your own. The details are available in the TT VMethod Manual . In that page there is a TODO about a method called define_vmethod . Since I like to use TT from CGI::Application and I don't like to actually see its guts. I choose to find a way to add a vmethod without the unpretty $Template::Stash::LIST_OPS->{} syntax. I think that is quite unfriendly to TT noobs like most of my coworkers. I found that define_vmethod is available off the TT Context object. This is available with $tt->context or in my case off plugin TT object in CGI App $self->tt_obj->context . The parameters are context->define_vmethod( $type, $name, \&implementation ) $type - data type, 'scalar...

Frozen Perl 2009 is right around the corner, well its on Sat Feb 6. Be there or be cubed (ice cube)...

Intro As part of a project to convert an existing SOAP client library over to a new version of calls, I found that I needed a way to test potential faults and new data formats without requiring live calls. After I built it for the new stuff, I used it to test existing calls and errors as well. This code was running live for several years before I needed to change it for the new version, this inspired me to be very careful and invest in testing. On a side note, I found plenty of bugs just creating the test suite in the existing code that had been there for years. Creating the Test Suite To create the test suite, I needed to pretend to get SOAP server responses. I turned to Test::MockModule to step in and provide hooks to return them. I found that mocking these responses were pretty straightforward once I figured out how to use the SOAP::Lite deserializer. (like most things, its easy once you know how) The following outlines what I did to create the suite, well at least the process of u...

I write quite a few unit tests that have methods or subs that throw exceptions (like most good code should... this rule has numerous good exceptions! hahaha, sorry couldn't resist.). A few months ago I ran across Test::Exception . In the past I would often write unit tests for these cases like: { my $err; my $obj; eval { $obj = MyObject->new; }; ## constructor expected to fail $err = $@; ok $err, "constructor - missing parameters"; ## or for methods that aren't suppose to throw eval { $obj = MyObject->new( server => 'localhost' ) }; ## check constructor $err = $@; ok !$err, "constructor"; isa_ok $obj, 'MyObject'; } This construct became very tiring, verbose and distracts from what is really going on. (Yuck!) With Test::Exception, I can convert these annoying eval blocks into nicely contain lines. Example from above: use Test::Exception; { my $obj; throws_ok { $obj = MyObject->new; } qr/Error Message to match/, 'constructor...