newbie question, conversion from cgi's to dancer
Hi, I've been looking at dancer for a while, it looks great and I'm now hooked. I'd like to start to replace my current setup, but am not sure in which direction to proceed. My current site is a collection of scripts, running under Apache as seperate cgi's. I use TT for the site, with all cgi's accessing Sybase behind the scenes. My questions are: - 1. Should I run a single occurrence of dancer to handle the site, and have that control everything ? 2. If I shouldn't run one main controller, how do I run them seperately under port 80 ? 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) 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? 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. Thanks in advance.
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. 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? 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- -- Marco Fontani Glasgow Perl Mongers - http://glasgow.pm.org/ Join the RackSpace Cloud at: http://www.rackspacecloud.com/277.html
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.
participants (2)
-
Marco Fontani -
Martin Bower