On Wed, Mar 16, 2011 at 4:17 PM, Marco Fontani <mfontani@cpan.org> wrote:
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?
just DBD::Sybase and DBI
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.
Example:
yoursite.pm package yoursite; # boilerplate get '/' => sub { template 'homepage' } true;
yoursite/admin.pm 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 true
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 127.0.0.1:5000) 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?
yes exactly
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-
thanks for the response, I appreciate it. lots to read through and understand.