To address your specific concerns ...

• It is strongly recommended, from both security experts and developers, that Apache/mod_perl not be used on Windows platforms. For a whole host of reasons. The Webserver I would use on Windows (if I had to deploy a webserver on Windows) would be IIS 6.0. I would also use .NET at that point, too.
• HTML::Mason isn't the only application that doesn't work with mod_perl2. Which isn't that surprising as the API for mod_perl2 hasn't been finalized yet. Technically, it hasn't been released for production work. And, no, I have no idea why RedHat has chosen to offer it with the installation. Personally, I never use the pre-installed versions of anything, other than the OS. I always compile Apache, mod_perl, etc.

  Installing Apache1 and mod_perl1 are both relatively easy tasks. There's one little gotcha (you have to make sure that mod_perl.pm is the right version - you can't have both working at the same time), but that's it.

• If something is non-trivial for you, that's a fair complaint. However, just because it's non-trivial for you doesn't mean it's non-trivial for someone else. And, frankly, my opinion is that if installing Apache is non-trivial for you, writing a secure, clean, maintainable web application is going to be exceedingly difficult.

Another note - I have been developing webapps as a career in Perl since 1995. I have never even played with Mason. I have barely played with Template Toolkit. That is not the only way to develop webapps in Perl. In fact, it's not even close to being the most common way.

New students do not pick and choose from a variety of languages. My point is that Perl isn't giving itself a chance of competing for mindshare in web development college courses because of the compatibility and usability headaches. I rarely see ANY Perl courses for web developers these days, let alone mod_perl, while PHP courses are ten-a-penny. The Perl community can ignore it if they wish but I can't.

Coming to your individual points:

• The use of WinXP was for testing only as I envisaged teaching the course in such a way that students could easily set up and practice on their home machines, which are often Windows machines. PHP works nicely with Windows, so why can't mod_perl? Someone in the Perl community needs to take the student mindshare seriously.
• I cannot recommend that new students re-compile anything. I need something which works with a simple config file as PHP does. Why is this so difficult with mod_perl+Mason? I can recompile Apache but students come to learn programming not system administration
• I loaded Apache 1.3 and the corresponding mod_perl but couldn't get a libpreq for Windows. Why isn't this libpreq bundled with mod_perl, or Mason for that matter. It's a complete joke hunting all over the internet for different bits 'n pieces like this. PHP will win every time.
• If you don't use things like Mason or Apache::Template how do you separate your presentation and business logic? How do you implement templating? Seriously, I'm interested in alternatives.

Currently, I use CGI::Application for the code and HTML::Template for the presentation layer. It's rudimentary, but gets the job done. Using that setup also allows me to use PDF::Template and Excel::Template for different formats.

AFAIK, Template doesn't easily generate PDF or Excel files. (The docs and the book seem to imply that to create PDF or Excel files using TT, you must generate the PS (for PDFs) or the MS XML (for Excel), both of which are non-trivial.) I do want to migrate to TT for its ease of use, but I haven't had the time to create TT plugins for those formats.

Plus, frankly, PHP serves a very important purpose - allowing less-experienced programmers to create smaller¹ web-applications. Perl has a much higher learning curve. Personally, I wouldn't teach Perl as the first language for programming anything, let alone web applications. If I were teaching general programming, I would start with either Pascal or LISP, both of which were designed for teaching. If I were teaching web applications, I would start with PHP or .NET, because they are designed to develop web applications. (The choice between the two would depend on which webserver I was using.)

After the students master the concepts behind programming, then I would teach them Perl. Perl, frankly, is too powerful for the novice user. It doesn't hold your hand enough. This fact makes it good for the expert, but bad for the novice. If you ask around, you'll find that nearly every top-notch Perl hacker knew 2-3 other languages before learning Perl. Almost invariably, those languages are from the following list:

• Pascal
• LISP
• C/C++
• Java
• BASIC
• Fortran

With the exceptions of LISP and C/C++, those languages are more rigid. Rigidity is good for novices. Pedagogy requires the gradual introduction of concepts. You can't throw someone into the deep end and expect them to swim very well. Most people are frustrated by programming and walk away. Or they develop bad habits which are almost impossible to break later on, which is even worse.

1. Yes, I am fully aware of what can be built with PHP. But, I'm also aware that those larger sites were built by people who could have just as easily built them in Perl, C++, COBOL, or ASM , for that matter. Good programmers can build X in any language. Lesser programmers need the help provided by well-designed languages. PHP is a well-designed domain-specific language.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

My point is that Perl isn't giving itself a chance of competing for mindshare in web development college courses because of the compatibility and usability headaches.

Which usability issues are you talking about? As shown in the other other responses, there are plenty of "out of the box" installations of mod_perl (even on windows). Also keep in mind that mod_perl has a different goal than PHP: it is supposed to give direct access to the Apache API, and thus is a lot tighter coupled to specific apache versions.

If you don't use things like Mason or Apache::Template how do you separate your presentation and business logic? How do you implement templating? Seriously, I'm interested in alternatives.

Mason is hardly an example of a clean separation of business logic and presentation, and neither is Apache::Template. Modules like CGI::Application or Apache::MVC do a much better job of it, IMO.

Joost.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Someone in the Perl community needs to take the student mindshare seriously.

Good job, you've just identified a volunteer opportunity!

How are PHP and Perl in competition? Many monks use PHP quite extensively, along with Java and numerous other languages. If PHP has a feature that is better than Perl's, then use PHP.

Or just use PHP::Include

Get the file called perl-win32-bin-0.10.exe
This very nice distribution consists of Perl 5.6.1, Apache 1.3.27, mod_perl-1.27, Mason, Template toolkit and others (even php-4.3.2 is there). I've used this distribution for developing Mason/mod_perl and found it easy to setup and use - it almost works right out of the box.

On the other hand, Mason doesn't require mod_perl. On Fedora you can install CGI::SpeedyCGI and use Mason's CgiHandler.

Fedora comes with Apache 2 and even mod_perl pre-installed. However, HTML::Mason won't work with Apache2 and neither will Apache::Template, the closest alternative.

One thing to note, is that mod_perl for Apache2 is still beta. I don't know why FC doesn't come with Apache 1.3 anyway, because on linux, the advantages of Apache 2 (threads) are hardly worth the upgrade, IMO. At the very least it should offer both apache 2 and apache 1.3.

Anyway, in the past I've had enough trouble with the standard (pre - 2.0) mod_perl rpms from RedHat that I always build my own binaries there.

Re-installing Apache to get 1.3 is non-trivial for me and in any case doesn't address the real issue: the Perl web development community, rather than just doing their own thing (mod_perl, Mason, Template::Toolkit), need to seriously address usability.

Running perl -MCPAN -e'install Apache::Request' also works automatically.

update: indented

Whilst I'm sure that there are various work-arounds my lament is that the Apache Perl community can't come up with a package/bundle which has been tested on, say WinXP and RH Linux, and which comes with Apache,mod_perl,Mason and TT2 without the nonesense of hunting down mod_perl and libpreq separately with all the potential version headaches. It would then be trivial for new students to get some work done as is the case with PHP. Perl would then have a chance of gaining back some of the mindshare.

Who knows, we might even see a few more authors writing about Perl web development.

If Redhat decides to only bundle an unstable and unsupported version of mod_perl, than that's primarily their fault, but hardly insurmountable, as Apache should be build by hand for any serious application anyway. You might consider another linux distribution.

As for windows, you appear to have missed the pre-build packages.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

• It's a bad idea to run Apache 1.x on Windows. Use Apache 2 for that.
• ActveState sells a competitor to mod_perl called PerlEx which runs on IIS. They have demo versions available for download. You should be able to run Mason on it, but it will require you to read some Mason docs and understand how to set up Mason under a non-mod_perl environment.
• Mason should be fine with mod_perl 2 at this point. If you find problems, please report them on the mailing list.
• There are concise instructions for running Mason with Apache 2 on Windows here. The most common approch to running Mason on Windows is to change a line in the config that tells it to use CGI.pm instead of libapreq.
• Apache::Template is not the closest alternative to Mason. I would recommend Apache::ASP or Embperl if you want something Mason-like.
• The mod_perl site has lots of documentation about libapreq/Apche::Request. Most of it is not specific to any platform. It has a small amount of information about installing it on Win32, but that is a minority platform for mod_perl after all.
• There are several binary distributions of mod_perl for Windows available from the site which do include libapreq. Randy Kobes in particular makes good ones.
• There are binary distributions of mod_perl for Fedora (as RPMs) on the mod_perl site.

jayrom

You'd think, with PHP racing ahead of Perl in popularity for small/medium-sized web development projects, that the movers and shakers behing PHP's closest competitor - mod_perl+Mason - would have made it a little easier by now to get things up and running.

Thanks. I hadn't considered the alternative since so many have recommended Mason and Embperl. Which are the best modules for this approach? Simon Cozens put out something recently along these lines, I believe.

You don't need *any* modules to do this sort of thing. Just structure your code so you have one section that displays output and another section that decides what to output and a third section to link the two.

However there are several modules that make this sort of thing easier. My current favorites are CGI::Application and HTML::Template. HTML::Template is a basic, but extremely fast and well designed templating engine that takes basic templates and fills them with paramaters. CGI::Application is a parent class that makes designing CGI state machines much simpler. Together they let you design clean, well structured code, so that each portion focuses on one specific task.

CGI::Applications work by having several "run modes", which basically states in your state machine, if you think of it that way. Typically every page that is displayed to a user is a run mode, and typically these run modes invoke html::template for the actual html generation. In this case, the specific run mode is the "Model" code, while the template you are displaying is the "View" code, and the CGI::Application base class provides the "Controller" code.

Check out Re: Why CGI::Application (and its replies) for how to design a C::A application. There are tons of good C::A nodes on Perlmonks.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

I do have a question for the framework part, does CGI::Application work with mod_perl also (the name suggests pure CGI), how about CGI::Application with Template Toolkit? I was thinking about looking into that, any comments would be great.

CGI::Application is a well behaved CGI module, and works well with mod_perl under Apache::Registry.

it's even mentioned in the docs

"What should it profit a man, if he should win a flame war, yet lose his cool?"

There is a module CGI::Application::TT that adds Template Toolkit support. Not on CPAN for some reason. Google for it.

FYI, I wrote CGI::Application::TT, but haven't put it up on CPAN yet, because I was hoping the users on the CGI::Application mailing list would give me some critical feedback on it before fully releasing it on CPAN. I haven't received said feedback yet, so I haven't been motivated enough to publish it.

I guess I should probably just upload it and let CPAN do it's thing...

- Cees

ps You can find it at http://cees.crtconsulting.ca/perl/modules/CGI-Application-TT-0.01.tar.gz for the time being.

Template Toolkit isn't the issue here, it's Apache::Template which won't run properly with Apache2.

• say "libapreq" and "win" in the same sentence and I break into hives -- I can't describe how much time we wasted on MP2 / AP2 / WinX before heading to Gentoo. Just hearing "libapreq" makes me itch -- bad memories.
• Perl's strength is TIMTOWTDI. Perl's weakness is TIMTOWTDI. I mean, look at this node -- everyone has their own preferred way of writing web apps. While this diversity of opinion is healthy and good (a vigorous ecosystem of ideas), sometimes it is easier to 'sell' simple less diverse idea sets (a factory-farming monoculture approach) -- TIMTOWTDI may be why many more use PHP vs Perl today (this is a fact, yes?) and yet is also responsible for Perl's robustness and survival.