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.

jdtoronto

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.

Check out these links:

• id:212355 (A thread called PHP vs. Perl);
• http://bugs.php.net/bug.php?id=15772 (PHP bug 15772);
• http://bugs.php.net/bug.php?id=21634 (PHP bug 21634).

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;
}
[download]

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.

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.

jdtoronto

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.

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.


----------
:Wq
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!

jdtoronto

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'
[download]

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