RSS
| << 5.5.0- Jumping Structures and the Art of Reusing Code | Chapter5 | 5.5.2- Functions >> |
Procedures
Procedures are easy to write – they have just three parts. First is the name, second is the code that the procedure should execute, and last is an ending statement. In addition you will have to direct your main body of code to run the procedure at the appropriate point.
In our first example we may want a procedure to put the contact information for the sales department on the web page. This can be done with the following code:
Response.Write "Price quotes for this product are available from "
Response.Write "Joe at 201/555-1212.<BR>"
In order to avoid writing this same code in many places throughout the page we can put it into a subprocedure:
Sub SalesContactInfo
Response.Write "Price quotes for this product are available from "
Response.Write "Joe at 201/555-1212.<BR>"
End Sub
This first line must start with the key word Sub, then a space and the name of the subroutine. The name should start with a letter and contain only letters and numbers – no spaces or symbols. The following lines hold the VBScript code to be performed in the subprocedure. The last line must be the command End Sub.
This subprocedure can then be called from your code whenever needed, by using the statement Call followed by the name of the procedure, as in the following example:
many lines about sweaters
Call SalesContactInfo
...
many lines about vests
Call SalesContactInfo
...
many lines about hats
Call SalesContactInfo
Although you can use the Call keyword to call the subprocedure, you could just as easily call the subprocedure without this keyword:
many lines about sweaters
SalesContactInfo
...
many lines about vests
SalesContactInfo
...
many lines about hats
SalesContactInfo
The subprocedure does not have to be in the same set of ASP code as the calling statement although it does have to be part of the same web page. The following two sets of code both work fine.
|
Subprocedure in separate section of ASP |
<% |
|
Subprocedure in same section |
<% Response.Write "now in
stock." |
Parameters
You can improve your subprocedure by having more than one possible outcome. The result will depend on variables sent from your main code over into the subprocedure. You do this by sending parameters along with the subprocedure. A parameter or argument is in fact a piece of data, which is passed to the subprocedure. It is transferred by placing it in parentheses after the name of the subroutine.
Call SalesContactInfo(varParameter)
For example, let's say you have four sales specialists, each covering a different region, and you want to display the appropriate sales representative for a given user. Let us also assume that you have picked up from the user their region and stuffed it into varRegion by a simple form. You may have created a subprocedure that writes the name of the appropriate sales representative. The varRegion can be transferred from your main form over to the procedure by putting the name of the variable in parenthesis as an argument. The calling code would now look like:
<HTML>
<HEAD>
<TITLE>Example Procedures Two</TITLE>
</HEAD>
<BODY>
<%
Dim varRegion
varRegion = Request.Form("region")
Sub SalesContactInfo(region)
Response.Write "Price quotes for this product are available from "
Select Case Region
Case "North"
Response.Write "Brian at 201/555-1212."
Case "South"
Response.Write "Rob at 719/555-1212."
Case "East"
Response.Write "Pat at 604/555-1212."
Case "West"
Response.Write "John at 312/555-1212."
End Select
End Sub
%>
<H2 align="center">On-Line Clothier<BR>
New Items for September, 1999</H2>
<H3>Sweaters</H3>
<P>New selections of warm and woolly Autumn Sweaters. Special line of
colors for fall festivities including Black/Orange and our new Autumn Medley.
<%call SalesContactInfo(varRegion)%>
<H3>Vests</H3>
<P>Get ready to dance around the MayPole in this season's brightest selection of Flowered Vests. We're in-swing with the retro look featuring flowers from the 50's, 60's and 70's.
<%call SalesContactInfo(varRegion)%>
<H3>Ties</H3>
<P>No reason to look uncomfortable just because you're wearing a noose! We have a new
line of ElastoTies<EM>™</EM> with lots of bungee in the middle to allow you to <EM>Expand under Pressure</EM><SMALL>®</SMALL>.
<%call SalesContactInfo(varRegion)%>
</BODY>
</HTML>
|
If we called this code from a suitable form where we had declared that we were in the East for example, it would display the following:
|
|
The above routine will put the appropriate SalesRep info into your code. There are three changes from our last example. The most obvious change is that inside the Sub where we used to have Response.Write "Joe at...", we now have a Select…Case structure that determines which sales representative we should write onto the page.
Also notice two slight differences in the syntax. First is in the line that calls the Sub:
call SalesContactInfo(varRegion)
In order for the subprocedure to decide which sales rep to use it must know the regional location of the user. This information is passed over to the subroutine by enclosing it in parenthesis after the name of the subroutine.
Notice also that the subprocedure has a change in the first line. After the name of the subprocedure there are parenthesis that specify the data that is being sent over from the main body of code.
Sub SalesContactInfo(region)
You might be wondering why we're calling SalesContactInfo with the variable varRegion, yet when we get to the subprocedure, we're using the variable region. Is it an absentminded typo on the part of the author who has forgotten to adhere to a naming convention? The short answer is no. In the above line, Sub informs us that we're about to define a subprocedure; where SalesContactInfo is the name of the subprocedure, and region tells us that the subprocedure has an argument. We're calling this argument region only throughout the body of the subprocedure, as it describes what the subprocedure will do with the argument that's its been fed. E.g. Select Case region... In other words, it's a local variable.
Now let's look at the subprocedure call:
<%call SalesContactInfo(varRegion)%>
Here, we call the subprocedure that we defined above. When the subprocedure is called, there's a value contained within the variable varRegion – this value is passed to the subprocedure as an argument. Within the subprocedure, region adopts this value and allows the subprocedure to execute. When the subprocedure finishes its execution, region ceases to exist, but varRegion continues to exist; and we return to the main program execution.
A confusing point arises here on our definition of subprocedures and functions. Both subprocedures and functions can receive information from the main code. They can both take action on that information. But only the function can return a value to the main code. Notice that the subprocedure performs its action (For example, Response.Write a line on the page) without sending anything back up to the main code. In a function there can be some information (such as the result of a calculation) sent back for the main code to use.
Why use subprocedures?
We've already discussed the use of subprocedures as a way of saving you from re-typing code in several places. There is a second – and very important – use for Subprocedures: the clarification and readability of your programs. Code can easily run on for several screens in your editor. When you or a colleague need to maintain or modify that code, it can be difficult to see the organization of the whole page. Breaking your code into several blocks and making each of them a subprocedure can solve this. Then the beginning of your code calls each of these blocks. When a programmer looks at the beginning of the code they can immediately see the general idea of what is going on, and then jump to the appropriate subprocedure to perform the editing.
In the code below you can see how easy it would be to re-arrange the order of the subprocedures or to substitute a new model of sweaters. In this example, the first three lines after the <% call the three subprocedures that are coded in full further down into the code. You will find that these subprocedure blocks will not be executed unless they are called. Therefore, after the last Call (Call Tie98Autumn on line 11 of the following code) VBScript sees that the remainder of the page mostly contains subs; and so it skips over these, then it stops when it reaches the %> marker. (The browser will interpret the HTML tags that form the remainder of the page when the page is sent to it.) You can understand procedures better when you understand that they are only executed when (and if) called, not based on their position in the code.
<HTML>
<HEAD>
<TITLE>Example Procedures Three</TITLE>
</HEAD>
<BODY>
<H2 ALIGN="center">On-Line Clothier <BR>
New Items for September, 1998</H2>
<%
Call Sweater98Autumn
Call Vest98Autumn
Call Tie98Autumn
Sub Sweater98Autumn
Response.Write"<P>New selections of warm and woolly Autumn "
& _
"Sweaters<SMALL>.</SMALL>"
Response.Write "Special line of colors for fall festivities "
Response.Write "including Black/Orange and our new Autumn Medley. "
End Sub
Sub Vest98Autumn
Response.Write "<P>Get ready to dance around the MayPole in "
Response.Write "this season's brightest selection of Flowered Vests. "
Response.Write "We're in swing with the retro look featuring "
Response.Write "flowers from the 50's, 60's and 70's. "
End Sub
Sub Tie98Autumn
Response.Write"<P>No reason to be uncomfortable because you wear a noose! "
Response.Write "We have a new line of ElastoTies<EM>™</EM> "
Response.Write "with lots of bungee in the middle to allow you to <EM>Expand "
Response.Write "under Pressure</EM><SMALL>®</SMALL>."
End Sub
%>
</BODY>
</HTML>
Procedures Summary
To review, procedures have a name and contain some lines of code. Whenever you did a Call of a procedure, its lines of code were run. Procedures are perfect for Response.Write or other actions, but what if you want to have some lines of code that give you back an answer? For example you may frequently calculate a 5% commission on a wholesale price. Or you may want to find out the due dates of library books Note that these questions require lines of code to generate an answer that you will use in the main body of your code. Functions fill this niche by accepting some information from your code, performing calculations or decisions, then returning an answer to your code.
| << 5.5.0- Jumping Structures and the Art of Reusing Code | Chapter5 | 5.5.2- Functions >> |
