Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

OT - Apache Toolkit - PHP & mod_perl

by jdtoronto (Prior)
on Oct 06, 2003 at 18:12 UTC ( #297023=perlquestion: print w/replies, xml ) Need Help??

jdtoronto has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed monks,

I am doing quite a deal of research based on responses to a previous post here on CGI Application Frameworks.

One monk suggested looking at Apache::ASP. On the web site they talk about using Apache Toolkit. This has raised a number of issues in my mind. Principally Will mod_perl and PHP coexist? I have a HTML type fresh out of college doing some work on my sites and he uses PHP, not Perl. I am okay with that - I stay in the back room and write the big stuff. He fiddles with a bit of form validation and some very simple DB stuff. But htis raises some morequestions I need to ask :)

  • Has anyone used Appache Toolbox, if so what is your reaction to it?
  • Do other monks have any suggestions about using mod_perl and PHP4 together? I have read some comments that they just do not co-exist happily.
  • Does anybody have any comments on Apache::ASP?
I have also looked at PageKit - but it seems to have not been updated recently. Anyone got any comments there?


Replies are listed 'Best First'.
Re: OT - Apache Toolkit - PHP & mod_perl
by Juerd (Abbot) on Oct 06, 2003 at 18:42 UTC

    PHP and mod_perl can co-exist perfectly. For as far as any PHP solution can be perfect. It may be a better idea to teach the guy some Perl and let him use PLP instead. In many situations, it uses less CPU/memory resources and is a bit faster.

    If he really wants to use PHP, or you don't trust him with mod_perl and you both work on the same site, then PHP::Session can be a life-saver. That, and HTML/CSS templates without executable code in them. Simple variable substitution works best (and is fastest anyhow. Remember all, in many, many cases, templating toolkits are overkill) if you use several languages.

    Do, however, insist that the other code in a Perl-ish manner. Foreach is so much easier to maintain than C-style for, and split/join is nicer than lots of substr and index. :)

    Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

Re: OT - Apache Toolkit - PHP & mod_perl
by cbraga (Pilgrim) on Oct 06, 2003 at 19:13 UTC
    Beware: you'll someday find yourself having two code bases, one in PHP and one in Perl, and unable to blend both into a single program — working with two languages often leads to writing the same code twice. This is specially the case with PHP since making it bind to any other language is hell (I speak from experience). I'm not saying use one language or the other, but the sooner you choose one the better. (Guess which one I'd choose ;)
      Oh and I know which one I choose!

      The other guy doesn't work on my big apps. He does a few simple scripty things mainly to do with validation of form data, checking email addresses, valid structure of phone nnumbers and such for 'quicky' things we do for a variety of clients. He has just finished a two year part time community college level course here in Canada covering web design and all that sort of stuff. So he did HTML, graphics creation and manipulation and programming. Sadly, much of the programming time was spent on PHP.

      I have been looking around and found some nice looking modules on CPAN for handling forms and validation, so I think he might be told to learn Perl faster than he thinks it is going to happen!

      His HTML and graphical stuff is very good, he has started doing some templates for me as well, so I will be keeping him for now. As a matter of very serious policy, I will NEVER allow two languages to co-exist in one project.


Re: OT - Apache Toolkit - PHP & mod_perl
by neilwatson (Priest) on Oct 06, 2003 at 18:38 UTC
    1. Apache toolbox is very cool. Although, once everthing is available for Apache 2 I don't think Toolbox will be needed as much.
    2. I believe mod_perl and php can exist together without difficulty.
    3. I've no experience to comment on Apache:ASP.

    Neil Watson

Re: OT - Apache Toolkit - PHP & mod_perl
by dmitri (Priest) on Oct 06, 2003 at 20:23 UTC
    For the love of God, do not use PHP. After having to occasionally do PHP for several years, I've grown to hate it.

    Check out these links:

    These are just a few examples to make you realize that no one should ever use PHP, no matter how convenient it is. It is a pain to maintain between upgrades, as new features break old APIs, and does not have a good security history.
Form Validation
by Wally Hartshorn (Hermit) on Oct 06, 2003 at 21:57 UTC

    You indicated that one of the main things he would be doing in PHP is form validation. If that's the case, you might want to take a look at Data::FormValidator. That makes form validation in Perl a snap (to the point where, frankly, it won't take up a significant amount of his time).

    Here's an example from the program I'm just finishing up:

    sub validate_fields { my $self = shift; my ($results, $error_page) = $self->check_rm( 'show_form', { required => [qw/ case_name file_type date interim_final case_summary /], optional => [qw/ alias penalty_amount compliance_plan_requirements compliance_plan_requirements_value /], require_some => { program_name => [ 1, qw/ pn_open_burning pn_asbestos pn_permit pn_monitoring /], }, dependencies => { reimburse_value => ['reimburse'], }, constraints => { interim_final => qr/^interim$|^final$/i, order_date => sub { return ParseDate(shift); }, }, filters => ['trim'], msgs => { any_errors => 'err__', prefix => 'err_', missing => 'Required Field', }, }, ); return $error_page; }

    This is actually part of a CGI::Application-based program, so we're using CGI::Application::ValidateRM instead (which just inherits from Data::FormValidator and calls the appropriate CGI::Application run_mode if necessary).

    We just list which fields are required, which are optional, which are a "choose at least one of these" group, which must have values that match a certain regex, are required only if some other field has a value, etc. We even verify that the date they've entered is valid.

    If there's a problem, the form is automagically filled in with the values that they've entered, along with text indicating which fields have problems.

    When combined with HTML::FillInForm, that leaves very little fiddling that we have to do to process web forms. That allows us to focus on the actually business logic of the program.

    Anyway, PHP would work fine for doing form validation, but if that's the primary way in which it will be used, you might be better off in the long run just using Perl. It should take just a little time to get something like this going.

    Wally Hartshorn

    (Plug: Visit JavaJunkies, PerlMonks for Java)

      This is actually the combination I am looking at. We dynamically generate a lot of forms now, mainly from a four year old script that uses HERE documents! But - the clients want a variety of customisable forms, they all collect basically the same info and the validation varies only a little. So I have designed, but not yet coded, a dynamic form generator that requires the template be loaded into a BLOB in a MySQL database and the validation information will be retrieved from other fields - all of which gets merged with a standard form block which is customised using CSS. The client ID is implicit in the URL and the correct form is built - on the fly & correctly - despite changes in the surrounding info on the page and style/colour changes.


Re: OT - Apache Toolkit - PHP & mod_perl
by CountZero (Bishop) on Oct 06, 2003 at 19:31 UTC
    Our company web-site uses PHP for some pages and Perl for others.

    Apache does not seem to mind.

    This week we will upgrade to Apache 2, so we keep our fingers crossed and hope things keep working.


    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: OT - Apache Toolkit - PHP & mod_perl
by perrin (Chancellor) on Oct 06, 2003 at 20:30 UTC
    Apache::ASP is a solid tool which many sites are using, including It's one of the top three in-line Perl web development tools, along with Mason and Embperl. It does more for you than most, offering a simple syntax for working with sessions and cached data.

    You mentioned that you were concerned about writing maintainable code, so be careful: an in-line Perl system can be a problem, in the same way that PHP/JSP/ASP can. If you aren't careful, you'll end up with spaghetti code. It is possible to use a disciplined approach with separate modules and even a model-view-controller style if you are careful about it.

      Yeah. ABSOLUTELY separate your business logic and dataase access from your display logic. Your ASP pages should be kept pretty light on the business/DB logic (ideally containing almost none), keeping most of that in your modules.

      Apart from the obvious aspects of maintainability, you will find this to be a very good thing down the road, if (when) you find yourself writing various standalone scripts to access and manipualte these same business objects. This is one of the ways in which perl shines over PHP (although PHP has gotten better about this... it used to be that the only real way to make a "command-line-script" to manipulate your business objects was to use curl or wget :-0)... in a properly written mod_perl app, you can do any business object manipulation from a script (and easily) that you could from your web UI.

      Not an editor command: Wq
      You mentioned that you were concerned about writing maintainable code, so be careful: an in-line Perl system can be a problem, in the same way that PHP/JSP/ASP can. If you aren't careful, you'll end up with spaghetti code.
      For this reason alone I have now taken Apache::ASP off my list along with Mason and Embperl. In my opinion, based on the maintenance problems of some of my earlier code, a clear and distinct separation of logic and presentation is essential. Well, for me it is anyway!


        For this reason alone I have now taken Apache::ASP off my list

        Don't throw it out... just do as suggested and seperate the logic. Apache::ASP can handle this very nicely.

        In your global.asa file, (and other includes) make your business logic, including functions that return the data needed to display on a page.

        In your asp pages, keep the logic simple; just simple loops to build the html structures needed, stuff like that. It should be mostly html. Use includes to refactor html that appears on multiple pages. Heck, asp includes can even take parameters that can be used to customize the file being included.

        I'm using php4, mod_perl, and Apache::ASP all in one server. Having tried several languages, I'm moving everything over to Apache::ASP, because it combines perls rich modularity (CPAN) and mature language with the ease of ASP's sessions and web handling.

        Here's my configure line for apache...(1.3.x) it doesn't build everything for you, but it seems like it is the hardest step.

        './configure' '--prefix=/usr/lib/php' '--with-imap=../imap' '--with-my +sql' '--with-zlib' '--with-apache=../apache_1.3.27' '--with-gettext' +'--enable-track-vars' '--with-db3' '--enable-bcmath' '--with-config-f +ile-path=/usr/local/apache/conf/' '--with-ldap=/usr' '--enable-ftp' ' +--without-gd' '--with-mcrypt'

        Oh, it also has ssl built in... I guess the configure script found it automatically.

Re: OT - Apache Toolkit - PHP & mod_perl
by Anonymous Monk on Oct 07, 2003 at 10:34 UTC
    Cute trick under linux: Make sure you have binfmt_misc enabled Install PHP(5 if you want) Then do something like this: echo ":PHP:E::php5::/usr/local/bin/php5:" > /proc/sys/fs/binfmt_misc/register Then enable regular CGI in apache and make sure .php or .php5 is counted as CGI type. It'll get executed as a CGI yes, but it'll operate perfectly with any apache mods or even another version of PHP. I use it on my hosting service to provide both PHP4 and PHP5 at the same time. Also recommend looking at PHP5. Its a bit beta at the moment but proper object semantics and exceptions are well worth while.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://297023]
Approved by Thelonius
Front-paged by Thelonius
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (2)
As of 2022-09-24 15:56 GMT
Find Nodes?
    Voting Booth?
    I prefer my indexes to start at:

    Results (114 votes). Check out past polls.