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. However, on both Fedora1 and WinXP my experiences have led me to conclude that, much as I prefer Perl to PHP, I will have to go with PHP for most web projects and for teaching a new course I have planned: "Open Source Web Development". mod_perl+Mason is by far the superior technology but when it comes to usability it hits ground zero as there are still so many compatibility issues.
Installing on WinXP was OK up to a point. I installed Apache 1.3 instead of 2.0, knowing how touchy Mason can be with 2.0. I then installed Perl 5.8 from ActiveState. All OK so far. ActiveState don't do mod_perl for some reason so I hunted down mod_perl from the Apache mod_perl website. Fine so far. Next HTML::Mason from ActiveState with mod_perl now configured within httpd.conf. It loaded OK but wouldn't work due to missing Apache::Request. Tried ppm> install Apache-Request but nothing. Searched Google and discovered that Apache::Request is part of libapreq. Someone tell me why it isn't in the same namespace/format as other Apache Perl modules. Several posts by similarly confused users indicated that ActiveState's libapreq doesn't work with mod_perl. The Apache mod_perl site had only one paragraph dealing with the issue and a link to a libapreq.ppd file. When requested from ppm> install this produced an error: "No suitable installation target found for package libapreq". Someone suggested creating my own ppd file but I'd had enough by then and it's non-trivial anyway.
With Fedora Core I hit similar problems. 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. 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. When there was no PHP on the block non-sysadmin users would probably fall back on simple CGI if they couldn't get everything to work but in the last few years the alternative for many who have pulled out their hair over these issues is to simply switch to PHP which "just works". PHP is now the MacOSX to Perl's Linux from Scratch. If you need to teach students how to get a web development environment up and running PHP is going to win over mod_perl+Mason every time because the latter doesn't give itself a chance to leave the starting block.
20040812 Janitored by Corion: Moved from Perl Monks Discussion
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.
------
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
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.
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.
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 smaller1 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.
- 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
That being said, I'm at a loss as to why newbies are being taught mod_perl (or are they not newbies???). Perl itself will be enough for these students to handle without the complexities of mod_perl thrown in.
Or just use PHP::Include
It comes with Apache and mod_perl all bundled.
I am not sure what the compatibility with Mason is though, but this has worked nicely for me as a mod_perl Apache server on Windows.
jayrom
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.What usability are you talking about? You haven't installed anything yet. I run debian, and doing apt-get install apache-perl will install a nice apache 1.3 binary with mod_perl, which just works (tm).
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.
As for windows, you appear to have missed the pre-build packages.
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.
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.
- 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.
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.Ignoring all of your technical difficulties, why are you so focused on embedding executable code inside html pages? Generally speaking, the common consensus is that you should seperate the "business code" from the "display code", in what is commonly called MVC. Embedding exeutable code in web pages doesn't really go along with this. Why not just teach them the proper way to design web applications from the beginning?
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.
------
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
- 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.