in reply to OT - Apache Toolkit - PHP & mod_perl

Apache::ASP is a solid tool which many sites are using, including redhat.com. 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.

  • Comment on Re: OT - Apache Toolkit - PHP & mod_perl

Replies are listed 'Best First'.
Re: Re: OT - Apache Toolkit - PHP & mod_perl
by etcshadow (Priest) on Oct 06, 2003 at 20:44 UTC
    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
[reply]
Re: Re: OT - Apache Toolkit - PHP & mod_perl
by jdtoronto (Prior) on Oct 07, 2003 at 01:36 UTC
    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

[reply]
      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.

[reply]
[d/l]

In Section Seekers of Perl Wisdom