You and I discussed this a little in the CB before you posted here. I mentioned I would think about it and try to come up with my own version of an answer. It took me a day, but here goes. As background, I recently read The Definitive Guide to Catalyst, and recently built a project around Mojolicious.
I think it's important, despite frameworks not being CGI, for people to learn some basics about CGI first. It's just a good foundation even though it's an aging set of concepts. For CGI, my trusted source is the 2nd edition of the Mouse book, CGI Programming with Perl. It's very old; a lot has changed since then in web work, but it does a good job of introducing the issues that will confront web developers. And one thing I can say about the Mouse book (2nd ed.): you can trust it. So many of the other CGI related books of that era were script-kiddie rubbish.
It's important to learn to use Perl's DBI. There is the O'Reilly book Programming the Perl DBI. It's also pretty old, but still relevant. It doesn't go into DBIx::Class, but does introduce Class::DBI. At any rate, developers are going to need to know how to use Perl's database API, and should learn basic SQL. At minimum, in the context of SQLite, but eventually PostgreSQL or MySQL. That can come with time.
Unit testing and TDD concepts are very important in a web framework setting, because you're marrying components that don't know about each other. The model needs to be thoroughly tested. The view needs to be thoroughly tested, and the controller. This will give you confidence that all the pieces will fit together correctly and do what they should. In a web environment bugs can be harder to track down than elsewhere, and the penalty can be greater, so test driven development will help to squash them before you put all the pieces together into a big monolith that obscures where the problems are. Plus, TDD gives you the confidence of being able to make big code changes if necessary. If the tests pass, your changes didn't cause problems. If they fail, you still have work to do.
Understanding templating, HTML, some JavaScript, and modern client-side or client-server interactions are important too. I know you recently finished the Template::Toolkit book from O'Reilly. I'm sure that has been helpful, although the framework I'm going to discuss later here uses its own templating system (with the option of overlaying anything you want, including TT2.)
Finally, there's dealing with the frameworks themselves. Catalyst is a "big job" getting it all going, but is extremely flexible. To use it you will need a good grasp on Moose too. Mojolicious is a lot easier to get going, though you sacrifice some flexibility. That often is not a problem.
Let's look at Mojolicious::Lite. Install Mojolicious using the docs; they're pretty easy to follow at that point. The Mojolicious people are proud of their simple, terse documentation. But sometimes its terseness forgets that people reading it for the first time haven't been through this before yet, and may need a little more help. (Yes, I know, patches are welcome.) Once you install it, open up the docs for Mojolicious::Lite. Create a directory somewhere in your home folder: ~/mojodev for example. cd into that folder and type 'mojo generate lite_app'. Inside that folder, find myapp.pl, and paste into it the first example from the Mojolicious::Lite docs. Then on the command line type: "./myapp.pl daemon" (must be executable).
Now on port 3000 of localhost you will be running a Mojolicious test/development server which is running your little application. Test it out. Visit the URL http://localhost:3000/welcome. Now visit some other localhost URL and see what happens when the document can't be found. Now begin tinkering with myapp.pl. Add some get handlers, and try them out. Notice how your URL doesn't need to map to directories anymore like old fashioned CGI. Now it maps to actions that you define.
Now you've learned the basics of playing with Mojolicious. The next step is to start building. Even within the context of a single-file (or file with helper modules) application facilitated by Mojolicious::Lite, you can still develop small models, controllers, and views, all in that one file. As your tinkering grows, they will be easy to migrate to a full Mojolicious application.
Deployment will be the next issue after that. You'll have to decide upon a back end: PSGI/Plack, FastCGI, CGI, mod_perl, etc. Configure the server with its supporting plugins, set up the server to run Mojolicious applications, and then set up your Mojolicious application folders with webserver-available permissions. Deploy, and test. Start simple by layering onto old fashioned CGI (since you already read the mouse book by now). Then when performance becomes an issue look into other options.
Update: I just realized that though I mentioned reading the Definitive Guide to Catalyst up at the top of the post, I really didn't mention anything about it later. The book starts out with a quick introduction to Moose, to building modules, and to test driven development before proceeding into Catalyst itself. While I am glad I read the book, I have to say that one thing I learned from it was that not every project needs a framework as big and as flexible as Catalyst. tye suggested to me a few months ago that I look into Mojolicious, and I'm glad because it saved me a lot of work. But the book did motivate me to dig deeper into testing, which is worth a lot to me.
Dave
In reply to Re: CGI/Frameworks: What is a good entry point?
by davido
in thread CGI/Frameworks: What is a good entry point?
by luis.roca
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |