[dancer-users] Confused about types and globals

Warren Young warren at etr-usa.com
Thu Jan 23 14:18:11 GMT 2014


I'm trying to get my head around Dancer2, and am having trouble because 
it doesn't look entirely like Perl to me.

For example:

     get '/foo/*' => sub { ....

What is "get", exactly?  I assume it is a function that takes a string 
and a coderef, and you're taking advantage of Perl's optional 
parentheses and fat comma to create a Perl-based DSL.  The problem is, I 
can only find examples and tutorial docs, not a reference that outright 
confirms that, so I'm left with this uneasy feeling that I don't truly 
understand what's going on here yet.

I tried to answer this myself before posting.  I thought it might be a 
package-global function, but there is no "sub get" in Dancer2.pm.  I 
also tried looking for a POD reference page on metacpan that explains 
this, but it ends up being a fully manual search since the metacpan 
search engine can't help with a generic term like 'get', and there are 
~50 namespace pages to dig through.

Another example: context->destroy_session

The only way I can think of for that to work without a sigil is for 
'context' to be another global (?) function that returns an object 
reference, rather than be an object reference itself.

There is no "context" in Dancer2.pm, so I'm left wondering where it 
comes from.  In one place, the tutorial docs say it is passed in to a 
"before" handler, while in other places it is assumed that you can just 
*use* this entity without having one passed into the route handler.

I care about this because I'm trying to port a fairly complex app from 
Apache::ASP to Dancer2, and this app is already broken up into many 
separate modules.  Because of this, the tutorial docs' assumption that I 
am writing all of my server-side code within the top-level module's 
route handlers doesn't apply.  I'm not going to consolidate dozens of 
modules of code into this one module, just to solve the namespace 
problems.  That just trades one problem for another.

Ideally, I want my top-level module to be as small as possible, doing 
little more than set up the route handlers, delegating all the real work 
to other modules.  To do that, I need to know where these objects come 
from, their exact data type, and which package's namespace they live in. 
  Then I'll know how to reference them or pass them around to the 
modules that do the work in my app.


More information about the dancer-users mailing list