Server Response Files

The next task that you will likely want to perform with any web application is to parse information from a web user, make some decision about the data, and return a response to the web user. Taking the NewSimpleATLServer project and adding some code, the SRF may be changed from the Hello World web application to a web application that either prompts the web user for his or her name and favorite color or tells the web user what his or her name and favorite color are. After the SRF has been established, the request handler DLL class may be edited to provide the necessary functionality to support the needs of the SRF.

Tags in Server Response Files

The SRF provides many features that make it an attractive alternative to Extensible Stylesheet Language (XSL) or Extensible Stylesheet Language Transformation (XSLT), as well as ASP.NET web forms, in terms of offering a mechanism to format and display ATL Server output while abstracting the presentation logic from the business logic. The design view, as shown in Figure 16-11, in ATL server provides a layer of abstraction for accessing the request handler DLL and writing HTML code. Through the use of tags placed throughout the SRF, you can perform simplified scripting that’s optimized for dispatching function calls to request handler DLLs, similar to the XSL or XSLT files that parse and manipulate the content of XML. Just as an XSL or XSLT file has some type of processing instruction at the top to indicate how the file should be used, so, too, does the SRF. The SRF also supports simplified amounts of looping and decision capabilities, as with an XSL and XSLT file.

Figure 16-11: Design view of NewSimpleATLServer.srf

Tags in a SRF are designated by two pairs of curly brackets that enclose the argument, which most often correlates to a tag attribute inside the request handler DLL. Tag attributes within the request handler DLL are mapped to functions that perform some task and return some data that will be inserted into the SRF. A single SRF may call many request handler DLLs. The SRF may also include other SRFs using the include tag, and SRF files support code comments.

Handler and Subhandler Tags

The first tag that any SRF likely contains is the handler tag. The handler tag specifies the request handler DLL that will be accessed when searching for the functions specified by the replacement tags in the SRF. A subhandler tag may also be specified. A single SRF may call functions from one or more request handler DLLs. Aliases may be specified in the handler or subhandler tag. Using the aliases, replacement tags may be formed to call functions from a given request handler DLL using the alias.function name. The default syntax for a handler tag is as follows:

{{handler <<handler name>>.dll/Default}}

By default, Visual Studio .NET will always deploy the DLL files in the same directory as the SRFs. Because placing binaries usually represents a particular layer of abstraction that is different from the code that is hosted in the SRFs, it is often preferable also to deploy the binary files in a separate directory on the server. A common choice is a subdirectory from the web root or virtual directory root named bin. (The phrase bin is short for the word binary.) Given the scenario of using a bin subdirectory to store the DLLs, the handler tag appear as follows:

{{handler bin\<<handler name>>.dll/Default}}

Replacement Tags

The replacement tag is the most often used SRF tag. Replacement tags in SRFs are the developer’s point of access to the functions contained in the request handler DLLs. The replacement tag will request the response from the request handler DLL that hosts the desired function and insert the response at that point in the SRF in which the replacement tag exists. Replacement tags also support instructions for calling functions, and they can pass arguments to functions in the request handler DLL. For example, an if..else..endif situation may be established using the command {{if <<FunctionName>>}} to start the if portion of the execution. Else and endif are specified by {{else}} and {{endif}}, respectively.

In the NewSimpleATLServer project, the SRF checks a function with an attribute name HaveNameAndColor, as shown in the following source code for NewSimpleATLServer.srf. If HaveNameAndColor returns a value of true, the name and favorite color entered by the web user is displayed. If any one of the items are not known, HaveNameAndColor will return a false and the SRF will prompt the user for his or her first name, last name, and favorite color. Replacement tags also support while..endwhile instructions for looping.

<<html>> <<HEAD>> <</HEAD>> <<BODY>> <<P>>{{//comments can appear before handler tag}}<</P>> <<P>>{{handler bin\NewSimpleATLServer.dll/Default}}<</P>> <<P>>First let me say : {{Hello}}<<br>> <</P>> <<P>>{{if HaveNameAndColor}} <</P>> <<P>>I can rest easy now because I know your name is:  {{YourName}}<</P>> <<P>> and your favorite color is: {{YourFavoriteColor}} <<P>> {{else}} <<P>>Tell me this:<</P>> <<FORM  action="NewSimpleATLServer.srf" method="post">> <<P>>First Name <<INPUT  type="text" name="firstname">><</P>> <<P>>Last Name <<INPUT  type="text" name="lastname">><</P>> <<P>>Favorite color <<INPUT  type="text" name="color">><</P>> <<P>> <<INPUT  type="submit" value="Submit" name="Submit1">> <</P>> <</FORM>> <<P>>{{endif}}<</P>> <</BODY>> <</html>>

Caution 

Replacement tags in SRFs that refer to a nonexistent attribute in the request handler DLL will return an HTTP 500 Internal Server Error. This appears to be a difficult error to catch, because many conditions can cause HTTP 500 Internal Server Errors. No auto complete feature is available in Visual Studio .NET to show the available attributes in the request handler DLL when a developer is editing a SRF, so the chances of misspelling a request handler tag are quite likely.

As shown in the source code listing for NewSimpleATLServer.srf, the SRF code behind the design view shown in Figure 16-11, the file is an HTML document. The only difference between an HTML file and the SRF is the presence of tags enclosed by the curly bracket pairs: {{ }}. None of the server controls that are afforded the web service or web form projects are available in the ATL Server project by default. Since the file extension for the SRF is mapped to the ISAPI extension DLL, it is possible to map HTM, HTML, or any file to the ISAPI extension DLL and have it processed as though it were a SRF with the file extension .srf.

Note 

The ability to comment in the SRF is not as robust as it is for other types of solutions, such as code in an executable program or a web service. Sometimes spaces placed before or after replacement tags will cause the SRF to fail. Comments may be placed before the handler tag. The HTML (!--) or the C++ (//) styles of comment may be used to specify the tags. Comments cannot appear on the same line of code with other tags, such as replacement tags. For example, the following line will cause the SRF to return an HTTP 500 Internal Server Error: {{endif // if HaveNameAndColor }}.