Calling scripts within scripts
A Component for calling a URL from an ASP script and reading back the output
Overview
When writing an ASP script, it is sometimes useful to temporarily transfer execution to another script, and then continue the original script with the result of the called script.
This is what the AspRetrieve
component does. You can think of it like
calling a procedure.
The AspRetrieve
component acts similar to the new function
Server.Execute in IIS 5.0. In addition, you can pass parameters, either
by GET or by POST.
The functionality of the AspRetrieve
component in brief:
- call any URL from within an ASP script
- pass parameters to the URL either in the URL itself (i.e. by GET) or by POST
- retrieve the results form the called URL as a string
Because I only needed limited functionality, only textual results are correctly returned from the called URL. i.e. you can call a HTML page, or an ASP script, but you cannot call a GIF or JPEG image, since the latter two return binary data.
If you would like to extend the functionality, I would love to have this new version.
Details
The AspRetrieve component consists of two parts:
- A MFC/ATL component that uses the Wininet functions to call an URL
- Some ASP functions that aid in accessing the MFC component
In addition I included some examples
Installation
- Compile the MFC/ATL part of the component, using Visual C++ (I used the german version of Visual C++ 6, SP3)
- Copy the component to whatever directory you want it, ensuring the account under which IIS runs (IUSR_XXX) has the correct permissions to access the component
- Register the compiled component using regsvr32 (which is
in your windows' system directory). Just type
regsvr32 aspretrieve.dll
at the command prompt - Copy the ASP function file retrieve.inc to whatever directory you want
- Include retrieve.inc in your projects and begin using it
Usage
When everything is installed correctly, just include the retrieve.inc
file in your ASP scripts and call the two functions Retrieve(url)
and RetrievePost(url,params)
. You can either use relative
URLs or absolute URLs for calling.
A practical use of the component is at those places, where you would
need a lot of Response.Write
statements to produce HTML
output. Those functions can now be separated into extra ASP files,
feeded with parameters and called via the AspRetrieve component.
Example
Imagine you have a function that creates a table by code.
Without the AspRetrieve component, you would write something like this to implement the function:
sub makeTable( byval cols, byval rows ) dim c,r Response.Write "<table border=""0"" width=""100%"">" ' create rows. for r=1 to rows Response.Write "<tr>" ' create cols. for c=1 to cols Response.Write "<td width=""100%""></td>" next Response.Write "</tr>" next Response.Write "</table>" end sub
You call the function like this:
<% makeTable 10, 20 %>
When using the AspRetrieve, you implement the function in a separate ASP script like this:
<table border="1" width="100%"> <% ' create rows. dim c,r for r=1 to Request("rows") %> <tr> <% ' create cols. for c=1 to Request("cols") %> <td width="100%"></td> <% next %> </tr> <% next %> </table>
You could then write a wrapper to simplify calling:
sub makeTable( byval cols, byval rows ) Response.Write Retrieve( "maketable.asp?cols="&cols&"&rows="&rows ) end sub
And finally you would call the wrapper in your code
<% makeTable 10, 20 %>
Conclusion
The advantages of using AspRetrieve are that you can divide a complex application into individual modules. You can create a library of ASP scripts that you can call as needed.
In addition by cutting down the
number of times you need to use Response.Write
, you
simplify your code. Having code in separate files, you can even use a
graphical layout tool to modify your files, which is impossible if you
construct your page with Response.Write
.
Another benefit is that you no longer need to include all files "at
compile-time" using the <!--#include--> directive
, but can
"include" these files dynamically at runtime using the Retrieve
function! (a feature that e.g.
JSP has by default).
Please feel free to ask any questions you have by e-mail: keim@zeta-software.de.