ASP-Style ADP Parser for AOLserver 3.x
Overview
It is sometimes convenient in a dynamic page (such as ADPs) to put HTML code inside the control structure. For example:
<%
while {[ns_db getrow $db $row]} {
%>
Blah <%=[ns_set get $row blah]%>
...more html code goes here...
<%
}
%>
This is how ASPs work. Using current ADPs you would not be able to do this, instead you would have to do:
<%
while {[ns_db getrow $db $row]} {
ns_adp_puts "Blah [ns_set get $row blah]"
ns_adp_puts "...more html code goes here..."
}
%>
If you have a lot of HTML putting everything in a ns_adp_puts is rather inconvenient. To get around this we've built an ASP-style ADP parser which handles pages like the first example above. The parser is an AOLserver module which nicely hooks into AOLserver.
Installation
First, you will need to compile the module. Start by
downloading
the tarball. Next untar it, the directory you untar it in
will depend on which makefile you use. If you have the
entire source tree you should untar it in the root of the
source tree (it will untar nicely into its own directory).
If not it doesn't really matter where you put it. If you
untared into the root of the source tree simply run make in
the directory it created. If you didn't untar it there, you
will need to set the Makefile.withOutSrc to your makefile
(so do a mv Makefile.withOutSrc Makefile), inspect the file
to see if there is anything you need to change, and run
make.
Second, copy the compiled module into your AOLserver /bin directory. The compiled module is named nsAspStyleAdps.so. For example, cp nsAspStyleAdps.so /usr/local/AOLserver/bin.
Third, modify your nsd.tcl (or nsd.ini) to load the module and map the parser to the desired file extensions. To load the module add the following line in your ns/server/vserver/module section
ns_param nsAspStyleAdps nsAspStyleAdps.so
On our test server our modules section now looks like:
ns_section "ns/server/server1/modules" ns_param nssock nssock.so ns_param nscp nscp.so ns_param nslog nslog.so ns_param nsAspStyleAdps nsAspStyleAdps.so
Next tell AOLserver to use the new parser as the default parser or with only the specified file extensions. Our parser's name is aspStyle. To make AOLserver use it as the default parser you would add a:
ns_param DefaultParser "aspStyle"
to your ns/server/vserver/adp section. Alternativly, you could tell AOLserver to only use our parser with certain file extensions. Do this by adding a line (or lines) to your ns/server/vserver/adp/parsers section mapping the parser to the desired file extensions. For example:
ns_section "ns/server/server1/adp/parsers" ns_param "aspStyle" ".asp" ns_param "adp" ".adp" ns_param "fancy" ".fadp"
The above tells AOLserver to use our aspStyle parser for all .asp pages, the standard adp parser for all .adp pages, and the fancy parser for .fadp pages. For more information about configuring your ADP section see the AOLserver Administrator's Guide.
Fourth and Last, restart your AOLserver and test the parser. To test the parser run the test.adp included in the tarball (you'll need to copy it to your pageroot) and check the Server Log for errors.
Implementation
An ADP parser works by "compiling" a page into text and script chunks. Then NsAdpEval writes the text chunks out and executes the script chunks with Tcl_Eval. Our ADP parser makes everything a giant script chunk and puts a ns_adp_puts around any would-be text chunks. This idea was suggested by Rob Schoening. Besides allowing partial Tcl statements it also gives us "page scope" variables for AOLserver 2.1.
Potential Performance Penalties
Potential being the keyword here. Originally I thought that writing everything out with ns_adp_puts would significantly slow things down. Then I realized that instead of making a call to Tcl_Eval for every script chunk we now just call it once. Thus reducing overhead associated with each Tcl_Eval call. Does the performance penalties of calling ns_adp_puts outweigh the performance gain of one Tcl_Eval call? We don't really know. If you have any insight, let us know.
The other possible performance penalty is the parser itself (actually reading the file and building the script chunk). The parser does a bit more work, but this should be insignificant though. Especially since "compiled" pages are cached.
