📄 ch16_01.htm
字号:
<?label 16. Guidelines for Better CGI Applications?><html><head><title>Guidelines for Better CGI Applications (CGI Programming with Perl)</title><link href="../style/style1.css" type="text/css" rel="stylesheet" /><meta name="DC.Creator" content="Scott Guelich, Gunther Birznieks and Shishir Gundavaram" /><meta scheme="MIME" content="text/xml" name="DC.Format" /><meta content="en-US" name="DC.Language" /><meta content="O'Reilly & Associates, Inc." name="DC.Publisher" /><meta scheme="ISBN" name="DC.Source" content="1565924193L" /><meta name="DC.Subject.Keyword" content="stuff" /><meta name="DC.Title" content="CGI Programming with Perl" /><meta content="Text.Monograph" name="DC.Type" /></head><body bgcolor="#ffffff"><img src="gifs/smbanner.gif" alt="Book Home" usemap="#banner-map" border="0" /><map name="banner-map"><area alt="CGI Programming with Perl" href="index.htm" coords="0,0,466,65" shape="rect" /><area alt="Search this book" href="jobjects/fsearch.htm" coords="467,0,514,18" shape="rect" /></map><div class="navbar"><table border="0" width="515"><tr><td width="172" valign="top" align="left"><a href="ch15_03.htm"><img src="../gifs/txtpreva.gif" alt="Previous" border="0" /></a></td><td width="171" valign="top" align="center"><a href="index.htm">CGI Programming with Perl</a></td><td width="172" valign="top" align="right"><a href="ch16_02.htm"><img src="../gifs/txtnexta.gif" alt="Next" border="0" /></a></td></tr></table></div><hr align="left" width="515" /><h1 class="chapter">Chapter 16. Guidelines for Better CGI Applications</h1><div class="htmltoc"><h4 class="tochead">Contents:</h4><p><a href="ch16_01.htm">Architectural Guidelines</a><br><a href="ch16_02.htm">Coding Guidelines</a><br></p></div><p>Like many forms of programming, CGI programming with Perl is abalance between art and science. As an art form, Perl is such auniquely expressive language that you have the freedom to accomplishthe same tasks in many different ways. However, thinking of Perl as ascience, you will want to choose methods based on balancing suchreal-world requirements as performance, security, and teamdevelopment.</p><p>Furthermore, any program that is useful in one context will generallyevolve to be useful in others. This requires that a program beflexible and have the capability to grow. Unfortunately, programs donot grow by themselves. They require the dreaded m-word: maintenance.Maintenance is usually difficult, but it can be made easier by takingsteps to make sure that the code is readable as well as flexible.</p><p>Because of these concerns, seasoned CGI developers typically end upsticking to a set of guidelines that help their code live up to theseexpectations. In a corporate setting, these guidelines tend to becomethe standards through which teams of developers understand how toeasily read the code that their neighbors produce.</p><div class="sect1"><a name="ch16-28753" /><h2 class="sect1">16.1. Architectural Guidelines</h2><p>The <a name="INDEX-3101" /> <a name="INDEX-3102" /> <a name="INDEX-3103" /> <a name="INDEX-3104" />first step in learning any languageconsists of being able to accomplish small tasks without the compilercomplaining. However, larger programs are made up of more than justsyntactically correct statements. The details of how the small partsof a program fit together is just as important as making sure thatthose same small parts compile successfully.</p><p>In other words, a program is literally more than the sum of itsparts. Attention must be paid to developing the program in order toaccommodate design goals such as flexibility and futuremaintainability. Sometimes this is referred to as"<a name="INDEX-3105" /> <a name="INDEX-3106" />programming in the large" or"strategic programming." This section emphasizes specifictips on how to architect a CGI application for these design goals.</p><a name="ch16-1-fm2xml" /><div class="sect2"><h3 class="sect2">16.1.1. Plan for Future Growth</h3><p><a name="INDEX-3107" />Web sites may<a name="INDEX-3108" /> <a name="INDEX-3109" /> <a name="INDEX-3110" />start small, but they typically grow andevolve over time. You may start out working on a small site withoutmany developers where it is easy to coordinate work. However, as websites grow and the staff that develops and supports the web sitegrows, it becomes more critical that it is designed well. Developersshould have a development site where they can work on their owncopies of the web site without affecting the production web server.</p><p>As web sites grow and multiple developers share work on projects, asystem to track changes to your applications is crucial. If you arenot using a <a name="INDEX-3111" /><a name="INDEX-3112" />revision control system, you shouldbe planning for one. There are numerous commercial products availablefor revision control in addition to open source implementations of<a name="INDEX-3113" />CVS and RCS. Supporting for a revisioncontrol system is an important consideration when makingarchitectural decisions.</p><p>You can configure this a number of different ways. Here are a fewexamples:</p><ul><li><p><em class="emphasis">Web developers share a common development webserver.</em><a name="INDEX-3114" /> <a name="INDEX-3115" /> This is thesimplest solution and can work for small groups but quickly becomesunwieldy for large projects. This does not support revision controlat a user level, and there is no stable code base because everythingis in flux. One developer would be unable to test a component withanother developer's code while the second developer is makingchanges to that code.</p></li><li><p><em class="emphasis">Web developers have their own directory tree on the webserver.</em><a name="INDEX-3116" /> In this example,each developer has a home directory on the web server and can accessa copy of web server's contents beneath this directory. This isrelatively easy to set up and works if HTML links are relative to thecurrent directory. This supports revision control systems becausedevelopers can periodically check in (preferably stable) snapshots oftheir code. Other developers can update their directories with thesesnapshots and even develop code in parallel.</p></li><li><p><em class="emphasis">Web developers have their own copy of the web serverrunning on a separate port.</em><a name="INDEX-3117" /> This requires the mostconfiguration because the web server must be reconfigured each time aport is added for a developer. This works for all relative URLs,whether they contain full paths or paths relative to the currentdirectory. This also supports revision control.</p></li></ul></div><a name="ch16-2-fm2xml" /><div class="sect2"><h3 class="sect2">16.1.2. Use Directories to Organize Your Projects</h3><p>CGI applications <a name="INDEX-3118" /> <a name="INDEX-3119" /><a name="INDEX-3120" />often<a name="INDEX-3121" />consist of several related files,including one or more CGI scripts, HTML forms, templatefiles -- if you are generating output with templates, data files,configuration files, etc. If your development system is separate fromyour production server (as it should be), then these systems may havedifferent directory structures.</p><p>On your development system you should develop a directory structurethat helps you organize this information easily. On systems thatsupport <a name="INDEX-3122" />pointers todirectories,<a href="#FOOTNOTE-22">[22]</a> it is a good idea to place all the files for a given CGIapplication within one directory. For example, if you had an webstorefront application, you might store the components insubdirectories within<em class="filename">/usr/local/projects/web_store</em> like so:</p><blockquote><a name="FOOTNOTE-22" /><p>[22]Such pointers could include symlinks onUnix or aliases on MacOS; Windows shortcuts are not transparent toapplications and thus will not work in this context.</p></blockquote><blockquote><pre class="code">/usr/local/projects/web_store/ cgi/ conf/ data/ html/ templates/</pre></blockquote><p>You could then create the following <a name="INDEX-3123" /> <a name="INDEX-3124" />symlinks that map this content into thecorresponding directories your web server uses:</p><blockquote><pre class="code">/usr/local/apache/htdocs/web_store -> /usr/local/projects/web_store/html//usr/local/apache/cgi-bin/web_store -> /usr/local/projects/web_store/cgi/</pre></blockquote><p>You may also wish to add <a name="INDEX-3125" />globaldirectories for data, configuration, and template files:</p><blockquote><pre class="code">/usr/local/apache/data/web_store -> /usr/local/projects/web_store/conf//usr/local/apache/conf/web_store -> /usr/local/projects/web_store/data//usr/local/apache/templates/web_store -> /usr/local/projects/web_store/templates/</pre></blockquote><p>Besides making it easier to locate all of the components that arepart of the web store application, placing all of your contentbeneath a common directory such as<em class="filename">/usr/local/projects/web_store</em> makes it easier tomanage this application with a revision control system.</p><p>Note that it is slower for the web server to follow a symlink than tostay in the document root, so this structure makes more sense on adevelopment system than on a production system.</p></div><a name="ch16-3-fm2xml" /><div class="sect2"><h3 class="sect2">16.1.3. Use Relative URLs</h3><p>Your <a name="INDEX-3126" /> <a name="INDEX-3127" /> <a name="INDEX-3128" /> <a name="INDEX-3129" />web site will be most flexible if you userelative URLs instead of absolute URLs. In other words, do notinclude the domain name of your web server when you do not need to.If your development and production web servers have different names,you want your code to work on either system with very littlereconfiguration.</p><p>Whether these relative URLs contain fully qualified paths or pathsthat are relative to the current directory depends on how you haveconfigured your development system, as we previously discussed.However, primary navigation elements, such as navigation bars, almostalways use fully qualified paths, so configuring your developmentenvironment to support this allows the development environment tobetter mirror the production environment.</p></div><a name="ch16-4-fm2xml" /><div class="sect2"><h3 class="sect2">16.1.4. Separate Configuration from Your Primary Code</h3><p>Information that is likely to <a name="INDEX-3130" /><a name="INDEX-3131" /><a name="INDEX-3132" />change in the program or that isdependent upon the environment should be placed in a separate setupfile. With Perl, setup files are easy because you can write the filein Perl; they simply need to set one or more global variables. Toaccess these variables in a CGI script, first use Perl's<tt class="function">require </tt>function to import the configurationfile.</p><p>In some scenarios, each web developer may need differentconfiguration parameters. By storing file paths in a configurationfile, web developers can test their applications with their owncopies of data and HTML files. However, that does not mean that CGIscripts need to require multiple files; another advantage to usingPerl for setup files is that they are easily extended. A CGI scriptcan require a single configuration file that requires other files.This easily supports configuration files for both applications anddevelopers. Likewise, if a CGI application grows so large that asingle application configuration file is difficult to manage, you canbreak it into smaller files and have the primary configuration filerequire these smaller sections.</p></div><a name="ch16-5-fm2xml" /><div class="sect2"><h3 class="sect2">16.1.5. Separating Display from Your Primary Code</h3><p>The display<a name="INDEX-3133" /> <a name="INDEX-3134" /> <a name="INDEX-3135" />associated with a CGI scriptis one of the most likely things to change in the lifetime of anapplication. Most Web sites undergo some look and feel change duringtheir evolution, and an application that will be used across severalweb sites needs to be flexible enough to accommodate all of theirindividual cosmetic guidelines. We discussed many of the argumentsfor separating display from logic in <a href="ch06_01.htm">Chapter 6, "HTML Templates"</a>.</p><p>However, even beyond keeping <a name="INDEX-3136" />HTML separate from code so that HTMLmaintainers have an easier time, it is a good idea to develop thecode that handles display (such as template parsing calls, CGI.pmmethods, etc.) separated from the rest of your program logic. Thisallows you to change the solution you use for generating display withas little effort as possible. You may at some point decide you wantto port all your CGI scripts from CGI.pm to templates or vice versa.</p><p>Another reason for separating display from the main program logic isthat you may not want to limit your program to displaying HTML. Asyour program evolves, you may want to provide other interfaces. Youmay wish to convert from basic HTML to the new XHTML standard. Or youmight want to add an XML interface to allow other systems programs tograb and process the output of your CGI script as data.</p></div>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -