[Dancer-users] newbie question, conversion from cgi's to dancer

Marco Fontani mfontani at cpan.org
Wed Mar 16 16:17:15 CET 2011

> My current site is a collection of scripts, running
> under Apache as seperate cgi's.

CGIs or mod_perl handlers?

> I use TT for the site, with all cgi's
> accessing Sybase behind the scenes.

DBD::Sybase and DBI directly, or using a DBIx::Class schema?

> 1. Should I run a single occurrence of dancer to handle the site, and have
> that control everything ?

Very well possible. You should use different module files for the
different areas of the site which are conceptually separated.
Within a common area of the site, you will then place the various
get/post subs for the actions you need performed on that section.


package yoursite;
# boilerplate
get '/' => sub { template 'homepage' }

package yoursite::admin;
# boilerplate
# if you want the admin stuff under
# /administration/
# but you want to call the module admin
prefix '/administration';
# all these routes will be under /administration/:
get '/' => sub { template 'admin/home' }; # views/admin/home.tt
# other routes

> 2. If I shouldn't run one main controller, how do I run them seperately
> under port 80 ?

You run one "app" which in the example above is a collection of the whole.
One way is to use plackup (say listening on and have
Apache redirect specific URLs to it
Or simply redirect _all_ to it, and use a separate subdomain or
specific directory to handle static files, which are best served by
the webserver directly.

> 3. I'd like to keep my scripts seperate, how can I implement this
> within Dancer? the examples I've seen so far seem to have all the code in
> the same place, and seem to be one dancer application for each app (as per
> my cgi setup)

See the above example: you can use multiple packages to group together
routes which have a common purpose, for example either "users site" vs
"administrative bit" or deeper like "administration for foo",
"administration for bar", "users site for baz", etc

You could also create one package per URL, but that may become a
bit... extreme...

> 4. Currently Apache caches the DB connections and they are shared across the
> scripts, this is fast and easy to use. How would I replicate that?

That's done using Apache::DBI right?
Using Dancer::Plugin::Database or Dancer::Plugin::DBIC this should
create -one- connection per process. This means that if you launch
your app and tell plackup to spawn 10 processes, you will have 10
connections max to the database.

> Apologies if any of the questions are basic, but I read the cookbook,
> introduction and Tutorial and they didn't seem to answer the above.

The above is what I've found out / used so far, I would love to find
out if others have better/different ways of doing this ;)
Your mileage may vary!!


Marco Fontani
Glasgow Perl Mongers - http://glasgow.pm.org/
Join the RackSpace Cloud at: http://www.rackspacecloud.com/277.html

More information about the Dancer-users mailing list