in reply to When to use ORMs, Catalyst, etc
Once upon a time (for years actually) I invented my own templating system. Then I discovered HTML::Template and gradually moved to that finding it saved time. I scoffed at Template::Toolkit and Mason. Now I still scoff at Mason :) because I don't feel like learning it (I may learn and stop scoffing at it one day though) but I do use Template Toolkit 2.
I selected TT2 because I selected Catalyst, but I like it very much (not my ideal but quite useful). Honestly I can say TT2 is a big time-saver. I fumbled a little until I was able to use it to make an email template as I used to use HTML::Template, but I know that it is capable and I just have to learn more to unlock more features. For example I discovered belatedly that it can do some very useful filtering (FILTER command). I also wrote a wrapper to make plaintext templates but realized this also was already available. With DBIx::Class you can throw a resultset at a template through the Catalyst stash and quickly make nice-looking reports. It is so easy that you are tempted to do it over and over but probably you could save even more time by making some generic report template (I think this should be a Catalyst extension myself). And you can even access objects related to those retrieved from within the TT2 template itself, without looking them up in your program even.
So I do recommend TT2 as a big timesaver and quite powerful and easy to update tool. Personally in catalyst I do a regex on the template file name and use that to choose which CSS file to use (i.e. "public" or "portal").
As for databases, I used to use hand-rolled DBI. Worked great, but then I moved to Class::DBI which I liked a lot.. although it seemed slow and a bit wierd or hard to find out how to do something, sometimes. Now I used DBIx::Class (because of Catalyst) and I like it. However I found there is a little bit of a lack in describing philosophy and recommended approaches to newbies. If you already know a lot about databases then it is great. The user community is great too. I think there is far too little written about ORMs, and also about just how much performance is given up. Also there is too little written I think about how a perl programmer should approach designing an app (when he is thinking in OO terms to start with) when a database and ORM is involved. In particular (I posted on the DBIx::Class ML recently about this) docs about how to design a db with the DBIx::Class::Relationships module could be improved. So I am not the person to say anything definitive about ORMs but I certainly like using DBIx::Class better than the Class::DBI code I used to write. It feels more robust, there is more extensive functionality, documentation, and support I think, and I think you can do more without thinking/writing SQL. For example I used to write a number of custom SQL searches but this is more perlish now.
I used to invent my own form code over and over, tried some different modules, then moved (after using Catalyst) to HTML::Widget which felt clunky and obscure (and is being obsoleted by a new module made by its authors) and settled on FormBuilder which I like very much, it even makes Javascript popups automatically for you. There are more data validation modules out there to try if you wish too. I definitely recommend using FormBuilder (the CGI version or the Catalyst version) since you just define you form and it builds it for you, and just tweaking a single setting will make it editable or not. I no longer need a designer to make nice forms.
Now as for frameworks, there are several and I haven't tried them all. I wish someone would write about experiences with all of them and characterize each one.
So once upon a time I built my own framework. I've built my own encrypted persistent forms, my own sessions, etc. Then I moved to CGI::Application and that seemed quite useful. It still took a long time to make big apps but there are useful plugins for it and it organizes things, which was a plus. (I haven't used it in a while but it is probably great.) Then I moved to Catalyst, which I like a lot.
It is a massive time saver, and has many plugins that make many things just work, like authentication, role-based authorization, sessions, breadcrumbs, etc. I think here too it could use more docs but it is extremely useful I found, and it works well with TT2 and DBIx::Class. There is plenty to continue to learn about with it but it also works well.. I had a standalone perl demon for testing right away and it was a snap to install a FastCGI persistent server too. A quick start doc would have been useful to get past the initial trepidation and actually understanding how it works. Also with Catalyst there is a tension I think between perl hacker types wanting to stuff everything into the Catalyst Controller (the module holding subroutines that are keyed directly to URLs) and rolling code into the Model modules which would allow you to call them from the command line or other kinds of interfaces. Some docs about that would be useful too, I get it from the mailing list.
So I think if you are making a simple CGI app you can use the CGI:: modules as they are I think, since some of them seem to just be updated for Catalyst separately, but it would be a very good idea to try something very simple in Catalyst, or in a few other frameworks, to get your feet wet and see what it's like. I think Catalyst would be very good for a team of your size since you can break things apart into modules for different people.
In particular, I have found with Catalyst that I can quickly prototype a function and then push through alpha, beta and live stages on a per-function (per-url) basis and feel very safe that the whole thing won't explode. I don't use tests much yet in it yet but there are hooks for them too. Anyway this means I was able to have very short cycles and was able to include the client in a dialog about each function. I used OpenOffice Draw to make the most important flowcharts and a limited number of screen layout mockups, but stopped that and just moved to prototyping with TT2 after a while. So I can say that Catalyst makes it easy to keep subroutines small and modular, and I think it even reduces the time to develop. In particular it was quite easy to add ACL rules (to control whether public users or logged in customer or admin can access certain URL paths) and tweak the dispatcher (in Root.pm) using regex tests on requested urls too, making an exception or an error page if I needed to.
So anyway I've turned into a Catalyst fanboy and while I'm interested in others (Jifty? Gantry?) that might be even more streamlined, I think as long as you get it to build with automatic follow using the cpan utility (since there are a LOT of modules involved), Catalyst will save you time, keep you sane, and provide fertile ground for further learning and development. In particular it is quite easy to make a proof of concept of a new function and then quickly implement a demo, then roll it into the live site. Built-in Catalyst modules enable many such functions to be done with minimum coding. It is naturally suited to short, incremental development cycles and promotes organic development and upgrading of functionality as you go. Most of the time I find I am documenting too much or spending too much time reading/fretting when just diving in and seeing how it feels will save time.