📄 ch5.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 5 -- Designing Your CGI Application</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 5</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>Designing Your CGI Application</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#SizingItUp" >Sizing It Up</A>
<UL>
<LI><A HREF="#WhatDoestheApplicationHavetoDo" >What Does the Application Have to Do?</A>
<LI><A HREF="#PreliminarySketches" >Preliminary Sketches</A>
</UL>
<LI><A HREF="#ScopingItOut" >Scoping It Out</A>
<UL>
<LI><A HREF="#Pseudocode" >Pseudocode</A>
<LI><A HREF="#PlanningforProcessing" >Planning for Processing</A>
<LI><A HREF="#GatheringInput" >Gathering Input</A>
<LI><A HREF="#Processing" >Processing</A>
<LI><A HREF="#GeneratingOutput" >Generating Output</A>
</UL>
<LI><A HREF="#TheFinePrint" >The Fine Print</A>
<UL>
<LI><A HREF="#Libraries" >Libraries</A>
<LI><A HREF="#Languages" >Languages</A>
<LI><A HREF="#SharewithYourNeighbors" >Share with Your Neighbors</A>
<LI><A HREF="#PlanningfortheFuture" >Planning for the Future</A>
</UL>
<LI><A HREF="#YouCanTakeItwithYou" >You Can Take It with You</A>
<UL>
<LI><A HREF="#ServerSoftware" >Server Software</A>
<LI><A HREF="#OperatingSystems" >Operating Systems</A>
<LI><A HREF="#Reuse" >Reuse</A>
</UL>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
When you encounter anything in life, your brain is subconsciously
doing a little bit of planning in your head. Maybe it's what you'll
do now that you've gotten that new raise, or how you're going
to dodge traffic to get to the new movie premiere. Whatever it
is, you make a plan of attack, and then you decide how you want
to follow up on that plan. You might do it, you might wait, or
you might ditch it and start concentrating on something else or
nothing at all. Aren't choices great?
<P>
You have plenty of choices when you sit down to write a CGI program.
For instance, you can hack away in your programming language of
choice until something pops out that's somewhat like what you
thought you wanted when you sat down. You could also sit for some
indeterminate amount of time while you flow-chart, plan, re-flowchart,
analyze, call a few committee meetings together, and try to agree
on what the heck the thing's going to be, much less how it's going
to work. There's also that wonderfully large area in between.
<P>
CGI applications can be anything from a couple of lines of code
to a behemoth that does more things than a Swiss army knife with
an attitude. The key factor in any CGI development effort is how
you're most comfortable with getting from point A to point B.
If it's five lines of Perl, you may just want to do it between
commercials or while you're waiting for some big file to download.
The more complex an application is going to be, the more design
time you'll probably want to spend on it.
<P>
This chapter is all about different components of CGI design.
It's impossible to be psychic and know what you're going to want
your application to do, so instead we'll cover the basics and
more in a general overview, including the following:
<UL>
<LI><FONT COLOR=#000000>Sizing It Up-How much work do you have
in front of you?</FONT>
<LI><FONT COLOR=#000000>Scoping It Out-Designing with CGI in mind.</FONT>
<LI><FONT COLOR=#000000>Taking a Byte-Making your design reality.</FONT>
<LI><FONT COLOR=#000000>Taking It with You-Portable code.</FONT>
<LI><FONT COLOR=#000000>The Fine Print-Some other issues.</FONT>
</UL>
<P>
There's nothing that says the design process has to take any longer
than you need it to. None of the things in this chapter takes
much time to apply to any CGI design process, whether it's just
a couple of lines of code or a huge project that threatens to
overwhelm you. By the end, no matter what kind of application
you're making, you'll be in a good position to go out and make
it happen quickly and easily. (And hopefully not spend too much
time visiting <A HREF="ch6.htm" >Chapter 6</A>, "Testing
and Debugging.")
<H2><A NAME="SizingItUp"><FONT SIZE=5 COLOR=#FF0000>Sizing It
Up</FONT></A></H2>
<P>
CGI comes in three difficulty levels: "Oh, that's easy,"
"I think I saw a script that does that," and "Ummm...."
The fun part, though, is that two different people can easily
assign very different difficulty levels to the same project, based
on their experiences. So the first question to look at becomes:
What's your first impression of how hard your application will
be for you to create? If it's the first CGI script you've ever
tried to make, or the first one using a particular function, chances
are it's not going to be something you view as a casual thing
to do while brushing your teeth.
<P>
As you write more and more, you familiarize yourself with basic
concepts and tricks, and you get to the point where what was once
frightening or frustrating becomes run of the mill. No matter
how familiar you are with a language or even the CGI functions,
though, you've got to start at the beginning to develop a complete
idea of what your application will do.
<H3><A NAME="WhatDoestheApplicationHavetoDo">What Does the Application
Have to Do?</A></H3>
<P>
This is an easy question to answer, normally. Chances are it has
to perform a specific function or set of functions, for a specific
reason. People who are learning or just hacking about might not
want to address a function so much as explore a concept, so the
purpose may be more ambiguous. It's important, though, to make
sure you have the purpose of the application set firmly in your
head when you begin, so that you can keep a focus on just what
it is you're going to make use of to meet your goal.
<P>
Just as there are roughly three levels of difficulty for a CGI
program, there are roughly two schools of thought for CGI programs:
Want User Input and Don't Want User Input. This doesn't rule out
either class getting data from some other source like a file,
a camera, or some other process, but it narrows down what kinds
of things the application is going to be playing with. If you
want user input, there's some mechanism on the user's side that
allows him or her to dynamically control what information you
receive, like a form. If you don't, there's probably a fixed link
like "View the LochNess MonsterCam" or "Get a Random
Link."
<P>
This is just the first of many questions you want to cover to
get a better feel for your application. Don't worry about getting
things down on paper and analyzing them; this isn't rocket science
yet. All you want to do is clarify your position on what the program
will do and what it won't do, by thinking over some of the following
questions:
<UL>
<LI><FONT COLOR=#000000>Do I need to accept input from the user?</FONT>
<LI><FONT COLOR=#000000>Will I be reading or writing to files?</FONT>
<LI><FONT COLOR=#000000>Will I be reading data from other sources,
like external devices?</FONT>
<LI><FONT COLOR=#000000>What kind of output will be sent back
to the user?</FONT>
</UL>
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
In the formal design process, this is what's more stoically referred to as the "Needs Analysis."</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
Now you're ready to move up in the world and start thinking about
the program and everything you're going to want it to do.
<H3><A NAME="PreliminarySketches">Preliminary Sketches</A></H3>
<P>
Mental picture firmly in hand, it's time to start making some
sketches, to put a framework around the application itself. One
of the easiest ways to do this is by sitting down and writing
the flow of your program in words, putting down the steps as you
see them in nontechie, crystal clear language. It's almost a sketch
of your program, using the logical flow of what you feel it needs
to do as an outline for code that will come later. You start out
with the purpose of the program, then work from there. Let's take
an example:<BR>
<P>
<I>Purpose: Collect Product Survey Data from Customers</I>
<CENTER><TABLE>
<TR><TD WIDTH=55><CENTER><I>Steps</I></CENTER></TD><TD WIDTH=535>
</TD></TR>
<TR><TD WIDTH=55><CENTER>1.</CENTER></TD><TD WIDTH=535>Give customers some way of entering data.
</TD></TR>
<TR><TD WIDTH=55><CENTER>2.</CENTER></TD><TD WIDTH=535>Get the data that's been entered.
</TD></TR>
<TR><TD WIDTH=55><CENTER>3.</CENTER></TD><TD WIDTH=535>Store the data the customers supply.
</TD></TR>
<TR><TD WIDTH=55><CENTER>4.</CENTER></TD><TD WIDTH=535>Thank the customer for stopping by.
</TD></TR>
</TABLE></CENTER>
<P>
<P>
You don't need any programming experience to make a sketch like
that. This isn't the point where you concern yourself with what
can and can't be done; this is where you idealize what will happen
in very general terms. You'll be able to refine your program sketch
as you go along, but already you have something that many developers
don't have: a written outline of the program. If you're ever in
a position where you need to lay out your site's functions to
someone who's not familiar (or doesn't want to be familiar) with
the technical side of things, a brief description like that is
all the person needs to see in order to know what's going on.
If that person wants to know the intimate details and inner workings,
you can always give him or her those from one of the later sketches,
but short and sweet is normally the best.
<P>
Now you have a real conceptual outline, but it doesn't do much
for the details. The next step is to add those details. Things
like the following: What will they use to enter the data? What
data should they be entering? Are there certain bits of information
we need them to enter? Where do we want to store the information?
What kind of format should the information be stored in? As you
can see, it's just the next logical step of questions. You've
left the "Why" of the application behind, and now you're
at the "What." It just takes a little bit more information
to extend the program sketch out into more detail.<BR>
<P>
<I>Purpose: Collect Survey Data from Customers</I><TABLE>
<CENTER><TR><TD WIDTH=55><CENTER><I>Steps</I></CENTER></TD><TD WIDTH=535>
</TD></TR>
<TR><TD WIDTH=55><CENTER>1.</CENTER></TD><TD WIDTH=535>Customers Fill out a Survey Form on our Web site.
<BR>
The survey form asks for Name, e-mail address, product version, and comments.
</TD></TR>
<TR><TD WIDTH=55><CENTER>2.</CENTER></TD><TD WIDTH=535>Information is read from the form.
</TD></TR>
<TR><TD WIDTH=55><CENTER>3.</CENTER></TD><TD WIDTH=535>Information they entered is examined.<BR>
Did they give us an e-mail address? A name?
</TD></TR>
<TR><TD WIDTH=55><CENTER>4.</CENTER></TD><TD WIDTH=535>If they gave us the information we needed, store it.<BR>
Should be added to a text file.
</TD></TR>
<TR><TD WIDTH=55><CENTER>5.</CENTER></TD><TD WIDTH=535>If they didn't give the information we needed, ask them to do it again.<BR>
Should be an HTML page.
</TD></TR>
<TR><TD WIDTH=55><CENTER>6.</CENTER></TD><TD WIDTH=535>Once we have the information, thank the customer for stopping by.<BR>
Should be an HTML page.
</TD></TR>
</TABLE></CENTER>
<P>
<P>
Now you know a little more about just what elements need to be
in your design. You're going to need a form, and you're going
to need that form to accept data in four specific fields: Name,
E-Mail Address, Product Version, and Comments. Your program needs
a convenient way to read the form data and then to be able to
process it to make sure you gather the information you need. There's
even the beginning of some error-catching code. If they provided
what you were looking for, then you store it to a text file; if
not, then you send them back a response asking for them to provide
the missing information. At the end, assuming everything goes
okay, you thank them for their time.
<P>
So far, there's nothing to it. That's the point: The design phase
of a CGI application isn't brain surgery or rocket science. There's
nothing difficult about expressing in plain language what you
want a program to do, and it gives you the opportunity to review
what you're going to do before you ever spend any time really
coding it. That way, if you want to add something or change something,
you haven't spent a whole lot of time getting into details that
might not really matter later on. The goal is speed and clarity,
and a simple outline meets that goal easily.
<P>
Once you have this outline and it looks like it will meet your
needs, you're ready for the next step: figuring out how you're
going to accomplish each task.
<H2><A NAME="ScopingItOut"><FONT SIZE=5 COLOR=#FF0000>Scoping
It Out</FONT></A></H2>
<P>
While a CGI application is a single entity, it's composed of parts
that each performs very distinct functions. The key to a successful
design is to recognize each of those pieces and see how they fit
together to accomplish your goal. To do this, you just have to
look at the steps of your outlined application and relate them
to a CGI function. One of the best ways of doing this is to turn
your outline into <I>pseudocode</I>.
<H3><A NAME="Pseudocode">Pseudocode</A></H3>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -