On 1/23/2014 08:47, Andrew Solomon wrote:
When you say "the modules that do the work in my app" I'm assuming you mean the model in an MVC architecture.
Nope. MVC is a bad fit for our app. (...Which is the main reason we rejected Catalyst and Jifty when looking at Perl web frameworks to replace Apache::ASP.) When I say Perl module, I mean a *.pm file. Maybe you prefer to call them them Perl packages, after the "package" keyword? I'm making a distinction between the generated lib/Foo.pm file, which we want to keep as small as possible, and our lib/Foo/*.pm module files, which contain the bulk of our Perl code. If you had to slice our app on MVC lines, the Perl web server code is mostly "C" with essentially no "M" and as little "V" as is practical given the nature of web apps. As browsers get more powerful, we're moving more and more "V" code into the JS layer. But again, MVC isn't a good abstraction for our app. A better description for the Perl layer in our app is "glue," binding the back-end C++ servers to the front-end JS code. Perl still makes great Internet Duct Tape, as far as we're concerned.