in reply to Need generic advise on how to use modern perl for building webpage and which modules should be installed.

You can go full out with Catalyst and Class::DBI DBIx::Class (edit: i dislike both and avoid ORMs in general although i have found that Ruby's Active Record solution takes care of the duplicity problem) but i would look at either Dancer or Mojolicious::Lite to create your framework. You most likely will want to incorporate some AJAX calls and such frameworks help to keep your code clean. I also recommend using Template::Toolkit as your templating engine but as long as you are using a templating engine then you should be better off than not. There are plenty of CPAN modules that allow you to communicate with database servers et. al. And last but not least, use Twitter Bootstrap to handle dynamic JS and CSS styling and help with AJAX and JQuery calls.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
  • Comment on Re: Need generic advice on how to use modern perl for building webpage and which modules should be installed.
  • Download Code

Replies are listed 'Best First'.
Re^2: Need generic advice on how to use modern perl for building webpage and which modules should be installed.
by Ravenhall (Beadle) on Aug 13, 2015 at 21:33 UTC

    Mojolicious has its own templating language -ep- which is basically Perl itself.

    I was also a big fan of Template Toolkit, and still use it on occasion. Yet I hardly ever use it for web templating anymore, because ep is so flexible. It is also nice to have one less dependency in the mix.

    I highly recommend that you spec out the app as suggested, but would encourage you to favor building interfaces as collections of dynamically generated 'widgets' rather than monolithic pages. Having to work on a few such monstrosities I can tell you that the pain of 'just one change' becomes:

    1. change the template
    2. fiddle with the javascript
    3. muck about with your objects/backend code
    4. resist the urge of self-defenestration

    I won't even mention how bad it becomes when there are database changes as well.

    Think of parts of your page as widgets (or boxes, cartons lol) whatever. Decompose the interface into many pieces that can be generated independently. Then the 'just one change' might actually be small enough to just require one of the steps above, and probably not the last one.