Structure of Perl CGI code

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

Survey time :)

I've been trying several approaches to coding a small multi-page order entry web site. The pages are login, order entry, and confirmation. I've so far not found an approach I like that seems it would scale well for larger sites. One given in this project is HTML::Template or a similar method of separating the Perl from the HTML.

The .pl-per-page doesn't seem to work well as the validation of one page is generally followed by the display of another. The all-in-one-.pl approach, with a top level dispatch and separate processing and display subs seems cleaner in some respects, but gets messy as the site grows. I've sketched a few OO ideas but so far haven't hit anything I like.

So, I ask you, fellow monks: What approach have you found that works well and is easily maintained? Mind you, I'm not looking for implementation details or code examples - although they wouldn't be ignored - just a high level overview. Pointers to good references are welcome.

Comment on Structure of Perl CGI code

Replies are listed 'Best First'.
Re: Structure of Perl CGI code by one4k4 (Hermit) on Oct 30, 2001 at 23:52 UTC
This is quick, and just my $0.02, but.. I like the concept of modes. Think `/cgi-bin/script.pl?mode=order` Then, you can do many things.. Create a hash with references to subroutines, and.. `my %mode_hash = (order => \&mode_order, confirm =>\&mode_confirm); my $mode = param('mode') \|\| "order"; #default mode &{$mode_hash{$mode}}; # executes the mode subroutine` [download] I know there is more than one way to call the subroutine in the mode hash, but like I said, this is just spilled out from memory. Anyway, that scales here at work. We have a similar approach, using mod_perl and Apache. The intranet here is huge, and it seems to provide (the dev team, at least) with understood and managable code.... _14k4 - perlmonks@poorheart.com (www.poorheart.com)	[reply] [d/l] [select]
Re: Structure of Perl CGI code by larsen (Parson) on Oct 30, 2001 at 23:56 UTC
I tend to choose single-script approach for CGIs. In Scaling single-script CGI applications I've pointed out why I've chosen this technique, and some related problems.	[reply]
Re: Structure of Perl CGI code by kwoff (Friar) on Oct 31, 2001 at 00:25 UTC
I think something to consider here is HTML::Mason. It's based on mod_perl, so it scales better to large traffic than CGI (though pure mod_perl is more efficient). It separates the HTML from the Perl, so HTML people can do their thing while you do your thing.	[reply]
Re: Structure of Perl CGI code by lachoy (Parson) on Oct 31, 2001 at 01:10 UTC
Related discussion: CGI/Mod Perl Application Design philosophy - which way do we go?. Even though the title mentions mod_perl, it's mainly about CGI. Chris M-x auto-bs-mode	[reply]
Re: Structure of Perl CGI code by moodster (Hermit) on Oct 31, 2001 at 01:00 UTC
I've never worked professionally with web development under perl, mind you, but I do have some experience with various Java application servers and Java ServerPages. One popular approach is to have a Servlet (which would be roughly equivalent to a .pl) which does authentication, bookkeeping, determines what function you're calling, grabs data from a DB, prepares output and then calls the appropriate ServerPage (which would be a HTML::Template or other template format) which produces the output. For small applications one Servlet is enough, but when they get larger you split them according to what functionality they serve. This approach works quite well, is scalable and has the bonus that it separates logic from presentation (which many people belive to be a good thing). Me? I never practice what I preach. I'm in love with CGI.pm and am in the middle of writing my own page layout framework for my own site. I will have roughly one cgi script per function and all HTML will be generated on the fly without relying on template engines. I'm probably reinventing the wheel, but I don't mind as long as I'm learning from the experience. Cheers, -- moodster	[reply]
Re: Structure of Perl CGI code by drewcifer (Novice) on Oct 31, 2001 at 01:57 UTC
I tend to prefer to have a separate master file that drives the entire site depending on how large they are. I generally start most of my projects as standalone CGI with the intention of porting them to mod_perl so I create a handler subroutine that is the first thing called in my applications. The handler then calls different sub-handlers depending on the mode and the submode cgi params. I have used HTML::Template for small projects but have been really considering Template Toolkit for all future projects. The code is structured around the classic Model-View-Controller pattern. See this article for a good example of this. Good luck.	[reply]
Re: Structure of Perl CGI code by dshahin (Pilgrim) on Oct 31, 2001 at 05:10 UTC
I really like CGI::Application in conjunction with HTML::Template and (preferably) mod_perl. CGI::Application gives you the option for the multi-form from one .pl conundrum by introducing the notion of a 'run-mode' (IIRC) that maps to a subroutine of the same name. It's nice and modular, and builds on the already excellent CGI module. d$hahin	[reply]
Re: Structure of Perl CGI code by shotgunefx (Parson) on Oct 31, 2001 at 09:56 UTC
For large applications, I prefer the all-in-one approach, mapping subs to states/screens. Only one place to break or upgrade. All states and expected inputs can be known to the program so it's easier to validate correct input between states and also to kick people back to previous screens if there is an error. Usually, for integrating look and feel, we insert the output from the script into a template page from the site. Usually by having the designer place a special tag within it and this is where the output goes. This way they can change the main layout without program modifications. -Lee "To be civilized is to deny one's nature."	[reply]