> ----- Original Message ----
>
>> From: Fred Moyer <f...@redhotpenguin.com>
>> To: Perrin Harkins <per...@elem.com>
>> Cc: David E. Wheeler <da...@kineticode.com>; mod_perl list
>><modperl@perl.apache.org>
>> Sent: Thu, June 16, 2011 4:18:17 PM
>> Subject: Re: How do you use mod_perl for your web application?
>>
>> On Thu, Jun 16, 2011 at 1:13 PM, Perrin Harkins <per...@elem.com> wrote:
>> > On Thu, Jun 16, 2011 at 4:07 PM, David E. Wheeler <da...@kineticode.com>
>>wrote:
>> >> Whatever old man!
>> >
>> > I know, it's just a reality of working on applications that have been
>> > around for years. These tools are so reliable that they tend to stick
>> > around. If I started something new I would probably use Plack, since
>> > I've enjoyed using similar stuff in Python.
>>
>> Maybe I'm not completely grokking how people are starting new projects
>> using Plack, but it seems like the way to go is to not use Plack
>> itself to write the code, but to use one of the many web frameworks
>> (Mason2, Catalyst, Mojolicious) and then use Plack to specify what
>> webserver is used. Plack is just middleware.
>>
>> There is a Mason handler for Plack, so it almost seems like you could
>> migrate your existing application to the Plack middleware stack while
>> changing little in your Mason codebase.
>>
>> I see the role of mod_perl2 going forward as not something that
>> applications are written on, but something that webserver middleware
>> interfaces with.
>
> Sigh. The big win with mod_perl2 is you get to interface with the rest
> of the C modules for httpd, often via subrequests. At the ASF we've
> been running mod_perl2 as our frontline mailserver for over 5y, and recently
> I wrote an ASF-wide CMS with it that's gaining more and more users as
> time goes on, in under 5K LOC. Haven't seen the need for app frameworks
> because most of my code is mod_perl2 specific- it just won't work in any
> other webserver.
Agreed with this ....
I've been looking around at all these discussions the situation I'm in
is probably more complex than writing a single application I manage a
large infastructure for a large scientific institute with a small core
webteam - and upwards of 200 developers. So my approach to development
is probably considerably different to some of the projects here.
Currently we are migrating our website to a new "mod_perl" backed
system. It has many requirements so our framework (Developed in house)
has to be compact, easy, flexible, and easily extensible, but at the
same time give good diagnostics and stop bad code being submitted.
The system is a mixture of:
* mod_perl handlers to perform routing, mapping URL spaces to
perl modules; to handle temporary files; improve error reporting;
handle user identity etc; built in caching, optimisation of images/
js/css;
* mod_perl output filters to handle page decorating;
* javascript/css libraries tied into the system;
* integrated support for AJAX;
* a series of modules which handle Components (parts of pages which
can be included into static HTML/dynamically generated HTML);
and Actions (web pages, JSON/XML documents etc)
* an SVN based sandbox/dev/staging/production system to pubish
code, and check quality tool to force good HTML, Javascript;
* tools to monitor changes, etc
* ability to write applications as either CGI scripts, mod_perl
(using registry) [but both are frowned on], Ruby, PHP, Java,
HTML/JavaScript and
still have the benefits of the decoration and component system
(Ruby, PHP, Java etc just produce raw HTML containing component
instructions)
e.g.
http://www.sanger.ac.uk/resources/databases/tiffin/table.jsp?col=3
Is a JSP wrapped using Perl to look like the rest of the site...
In other projects I combine it with PHP to handle a lot of the
initial set up - parsing cookies for users etc and populating
variables that other applications can use;
It has a few more lines of code than yours - but the core of the
system is quite compact - it's just the fluff and added features
which make it longer... (plus getting the code through perl::critic!)
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
