ch5.htm

CGI programming is the hottest stuff to look out for in this book

been dreading trying to figure out in your program. Don't imagine
any longer. Review <A HREF="ch4.htm" >Chapter 4</A>, with your
outline in hand, and see what you can find to save yourself some
effort.
<H3><A NAME="Languages">Languages</A></H3>
<P>
What programming language are you going to write this in? More
importantly, what programming languages do you know? That will
often make the decision for you. If you're ambitious enough to
be versed in more than one programming language, you'll want to
consider which language gives you the most benefit in using it.
Speed of development is great, and thus the immense popularity
of scripting languages, but how important is speed? Native compiled
functions are normally a good bit faster than interpreted languages,
but the speed of development can be a lot slower and fraught with
more difficulty.
<P>
Are you going to need to take this to a different operating system?
If you're starting on Windows, for instance, were you thinking
of taking your Visual Basic program to a UNIX server? Let's hope
not, or you'll be disappointed (at least at present).
<P>
Be sure that if where you start and where you end up are different,
you're prepared to use the right language. <A HREF="ch2.htm" >Chapter 2</A>,
&quot;The CGI Specification,&quot; provides a number of details
on the languages you can and might choose, and now might be a
good time to review it if your mind isn't already made up.
<H3><A NAME="SharewithYourNeighbors">Share with Your Neighbors</A>
</H3>
<P>
Faster isn't always better because it takes more effort on the
server machine to do things as fast as possible. Remember, your
application may be trying to compete against itself for memory
space and general file access, and you can't hog it all! The following
three principles suggest a couple of different tactics you can
use to be friendly to your server's environment.
<H4>Slow It Down</H4>
<P>
Two things you can do to make your applications more processor
friendly are to slow it down and to be careful with memory. To
slow it down, all that's required are occasional pauses. These
don't have to be long pauses-in some cases no more than a tenth
of a second or so-but if you've just done a huge process that
takes up tons of memory and are about to do another, give your
poor server a chance to recover. Imagine if it's running 30 copies
of your application at once-or more.
<H4>Minimize Memory</H4>
<P>
Being careful with memory is more appropriate for compiled applications
because most scripting languages don't normally force you to deal
with memory allocation. If you're expecting to receive no more
than 2K of data, don't specify that your program has a 20K buffer
&quot;just in case.&quot; If you want only 2K of data, force your
program to read in only 2K of data, and dump the rest of it. This
will also protect you somewhat from bogus or accidental requests
that fill the input buffer with lots of junk. Also, take out any
unreferenced local variables. C compilers often give you an error
when they see them, and there's good reason: they're a waste of
space.
<P>
Remember, though, that if you start to get tricky and reuse variables
just to save a little bit of space, you can start making it much
harder to make sense of your code. Be careful with memory, maybe
even border on stingy, but keep your sanity and structure it so
that the code is easy to deal with.
<H4>Enough Files to Go Around</H4>
<P>
If your program will be reading from files or writing to them,
it's a good idea to place a <I>lock</I> check inside the program
if you want to make sure that data doesn't get overwritten. A
lock check can be as simple as creating a temporary file that
the program checks for before trying to open or write to a specific
file. If the temporary file is there, the program waits a moment
and then checks again, until the lock is gone. Be sure to delete
the lock file when the program has no more need for it!
<H3><A NAME="PlanningfortheFuture">Planning for the Future</A>
</H3>
<P>
One thing that is so easy to do during development, but so often
overlooked, is the inclusion of comments. Are you going to remember
why you did something in a particular way six months from now?
Would someone else be able to review your code and understand
it if they had to? There's no need to comment every line, but
well-organized code with comments before major sections or tricky
operations can turn a potential nightmare into a walk in the park
when you have to make changes.
<P>
Placing comments is also a good way to notify yourself in areas
where you think problems could develop later on, or where you
want to add an additional function in the next version of the
code. Sometimes these are just revision notes where you mark down
what you've changed and what might still need to be changed later;
sometimes they're just lines inserted wherever you feel like it.
Do what comes naturally.
<H2><A NAME="YouCanTakeItwithYou"><FONT SIZE=5 COLOR=#FF0000>You
Can Take It with You</FONT></A></H2>
<P>
If you have the luxury of writing your CGI application on the
server that will eventually house it, moving your code around
isn't really a big deal. Maybe you want to change a directory
or two, change some permissions, or make other minor modifications,
but the script has been running on the machine it needs to run
on, and you're happy. Now you want to move the script to another
site or sell it to someone, and they're running something different.
Whoops, you're not so happy anymore.
<P>
The wonderful world of Web servers is not homogeneous. There are
multiple operating systems in use by sites and different HTTP
server software available for every platform. What you specify,
design, and implement may not be portable to someone else's server.
If you never want anyone to use your code except you, that may
not be a bad thing. If, on the other hand, you're hoping to sell
a special program that you wrote to the widest possible audience,
you need to consider the differences in what's out there and account
for them in your design. What are these all-important differences?
Well, they can be broken down into two main categories: server
software and operating systems.
<H3><A NAME="ServerSoftware">Server Software</A></H3>
<P>
One of the easiest moves (normally) is between types of server
software and staying on the same operating system. So maybe you
have a Perl script on a Windows NT machine running Process Software's
Purveyor, and you want to move it to another department's NT machine
running Netscape's Commerce server. For the most part, there's
not much to be concerned about...right? Well, a lot depends on
your code.
<P>
For instance, let's look at directory structures. If you've hard-coded
in paths to your files, do those paths exist on the new server?
Different software and site maintainers mean that there's not
some fixed location you can count on for data or storage. Your
program needs to be able to adapt to these situations: If you
coded it in C, would you want to have to recompile every time
a directory structure change was made? Probably not. If you're
depending on information from the server, whatever the form, your
program needs to be flexible enough to take changes into account.
<P>
One way of being flexible is with a configuration file. Most programs
can easily find a file that's in the directory they're running
from or in some directory that must exist to have any chance for
the program to run. In the configuration file, you can set up
directory paths, variables, and other important information that
will then be read dynamically by your program. This allows people
(whether it's you or someone else) to modify those values without
modifying the program itself.
<H3><A NAME="OperatingSystems">Operating Systems</A></H3>
<P>
There's no one operating system that everyone runs. Sure, there
are companies that would sure like to change that, but it's a
fact of life that major differences exist on the very base levels
of systems, and your program may have to take those into account.
One of the first steps in this direction is to use an interpreted
language, such as Perl or Java. These are both available on a
number of platforms and don't necessarily require changes in order
to make the code run on a different type of machine-that is, if
the language has the functions you need.
<P>
One of the most difficult things about planning for cross-platform
functions is that many components that are common in one environment
may be completely alien to another. Take the common <TT><FONT FACE="Courier">ls</FONT></TT>
command for listing files on the UNIX side or <TT><FONT FACE="Courier">grep</FONT></TT>,
which performs text string pattern matching. It wouldn't be at
all uncommon to write a program that listed out the files in an
FTP site's directory, sorting them by file size or date. But if
you wrote something that relied on either the <TT><FONT FACE="Courier">ls</FONT></TT>
or <TT><FONT FACE="Courier">grep</FONT></TT> command and then
took it to a pc, you'd be in trouble. How can you possibly accommodate
differences on such a base level? With a little bit of trickery...
<P>
The configuration files mentioned in regard to server software
come into play here. Provide a tag that specifies the operating
system and evaluate that within your program. If it's possible
for the functions you'll be doing, provide an alternate route
for commands that may differ. For instance, Listing 5.3 shows
a small fragment of Perl pseudocode that uses a variable called
<TT><FONT FACE="Courier">os</FONT></TT> to specify which operating
system it's being run under.
<HR>
<BLOCKQUOTE>
<B>Listing 5.3. Building operating-system independence into your
scripts.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">if ($os eq &quot;UNIX&quot;) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;....<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
if ($os eq &quot;NT&quot;) {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;....<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<BR>
if ...<BR>
else&nbsp;&nbsp;{<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;..insert error
code here..<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Notice that if you take this route, you'll also need to provide an error case if the configuration file doesn't exist, is inaccessible, or is just plain wrong.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
Another item to take into account is the capability to access
certain files. Assuming you get around basic operating system
command set differences, you still have to make sure that you
don't rely on reading information from files that just don't exist.
For instance, much of the data that's stored in server configuration
files on UNIX is stored in the Registry in Windows NT. Because
it's almost impossible to code a generically cross-platform function
that accesses the Registry, the focus of the code isn't necessarily
&quot;no changes&quot; for portability, but rather &quot;few changes.&quot;
<P>
The more you can do to make the code easy to translate between
different systems and servers, the less frustration you'll encounter
if the time ever comes to do so. In commercial CGI work, this
is imperative; you can't spend all your life developing programs
based on the WinCGI standard if you're planning on trying to win
an account at a UNIX-intensive shop. However, by being familiar
with what's involved in changing over, all the rough work will
already be done, and you'll just reap the benefits.
<H3><A NAME="Reuse">Reuse</A></H3>
<P>
Another thing to consider when thinking of portability is whether
or not you can put your current code to good use somewhere else,
either through creating your own custom library or just cutting
and pasting. More general functions like reading, parsing, and
decoding data are the most commonly used library functions, but
what about situations that are unique to your class of CGI applications?
<P>
If you're evaluating serial numbers, for instance, and connecting
to a database to gather information about the user of that serial
number, wouldn't it make sense to create a function that does
that and then include it in the code? In Perl, this is as easy
as creating a different Perl script with some subroutines in it,
then inserting a <TT><FONT FACE="Courier">#require 'myscript.pl';</FONT></TT>
line at the beginning of your new script. Throughout the rest
of your program, you can call subroutines from your other script
just as if you had typed them into the new script's code.
<P>
The more you access a function and the more complex it is, the
more you should think about reusing it. After a while, between
libraries you build yourself and ones you've found from other
sources, your programs can be created faster and more efficiently,
because as long as the method of use is the same between scripts,
you'll be bringing in a precreated and pretested segment of code
to perform an otherwise annoying function. And who better to write
a library of functions useful to you than you? 
<H2><A NAME="Summary"><FONT SIZE=5 COLOR=#FF0000>Summary</FONT></A>
</H2>
<P>
The design and execution of a CGI program don't have to be torturous.
It's very easy to take a rough idea and turn it into an outline
that you can use to make your application run smoothly; you just
need to spend the short amount of time it takes to review and
re-review until you're sure it meets your needs. One of the benefits
of a methodical design process is that it means less time will
be spent trying to figure out why you did something a certain
way, and it will give you or anyone else who needs to modify the
code all the details necessary to see where the changes they need
to make should go, and how they'll need to interact with the rest
of the program. Measure twice; cut once.
<P>
<HR WIDTH="100%"></P>

<CENTER><P><A HREF="ch4.htm"><IMG SRC="pc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="#CONTENTS"><IMG SRC="cc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="index.htm"><IMG SRC="hb.gif" BORDER=0 HEIGHT=88 WIDTH=140></A><A HREF="ch6.htm"><IMG 
SRC="nc.gif" BORDER=0 HEIGHT=88 WIDTH=140></A></P></CENTER>

<P>
<HR WIDTH="100%"></P>

</BODY>
</HTML>