Volume Number: 17 (2001)
Issue Number: 09
Column Tag: Advvanced WebObjects 5

Deep into the request/Response Loop

by Emmanuel Proulx

Customizing Web Component Processing

This new column covers various advanced topics of programming Web applications with WebObjects 5. It is targeted towards knowledgeable WebObjects developers who are looking for that extra wisdom to help them go further.

In this first article, I introduce the Request/Reply loop, and how to customize it and control how Components are processed. I hope this will be valuable to you.

From the time a user clicks on a hyperlink to the time the page is displayed in the browser, lots of things happen. Of course, the browser and the Web server first initiate the communication and ask for a page. If you installed WebObjects with the CGI adaptor (as opposed to a native one), the following type of URL is used:

http://server.domain.subdomain/cgibin/WebObjects/ApplicationName

Here the WebObjects adaptor program is being called, and if there is an application called "ApplicationName" registered, it is being executed. WebObjects builds a page and returns it, calling your code to fill in the blanks. This part is very transparent. But the building of a page is not. How does it work? What happens? When does it happen?

Knowing the answer to these questions is important to expand, tweak and adapt your WebObjects program to the specific requirements of your target system. Figure 1 illustrates how it works:

Figure 1. Objects of the Request/Response Loop.

The WebObjects adaptor program builds a Request object, which encapsulates the original "Get/Post" message received by the Web Server. This object is passed around the framework as WebObjects works on the Component (page template). Then WebObjects builds the Response object, which encapsulates the returned (pure HTML) page.

During this time, many classes of the framework call each other. You know about the Application and Session classes. You just learned about the Request, Response and Component classes. When they interact, they call different functions at different times.

Knowing when the functions are called and overriding the correct function is the key to customizing the request/response loop. Figure 2 illustrates the different objects and methods and their interactions. The next sections describe them further, and prescribe when to overload them.

Figure 2. Interactions Between Methods.

The Application class is a subclass of the virtual WOApplication class. Your Application class will only have a single instance per server. This class contains the main() function. By default, the generated code for this function calls WOApplication.main(), which creates a Singleton instance of your Application class. You have to use the following definition so your subclass will be recognized:

public class Application extends WOApplication

I have also stated that the Application object is accessible from all Sessions on the server, and its main use is to share data among them, and to hold global business logic. The Application's underling goal is to manage the Sessions and the request/response loop. Typically, you overload at the Application level if your code is general to all clients. That said, here are the main functions that you can overload to customize the framework to your needs:

• main(String []) : Overload to initialize variables before the system is started. Note that the default behavior is to call WOApplication.main(), which creates an instance of Application.
• Application() (Constructor): Ideal to put the system-wide initialization code.
• handleRequest(WORequest): Takes care of a single iteration of the request/response loop. The base implementation calls awake(), takeValuesFromRequest(), invokeAction(), appendToResponse() and finally sleep().
• awake():Called by the framework when there's a new request, before WebObjects begins processing it. Overload for example when you want to keep statistics of the frequency at which the system is being used.
• takeValuesFromRequest(WORequest, WOContext): The base implementation calls Session.takeValuesFromRequest(). As its name stipulates, this function should be overridden when you want to process the request object from the application object.
• WOResponse infokeAction(WORequest, WOContext): The base implementation executes the action associated to a Request, by calling Session.invokeAction(). This function should be overridden if you intend to act upon the action itself (for example, to stop one from being executed).
• appendToResponse(WOResponse, WOContext): The base implementation calls Session.appendToResponse(). As its name says, this function should be overridden to add to the Response, or for any post-action operation.
• sleep(): Called by the framework after a request/response is done with, before WebObjects waits for the next one. Overload for example when you want to keep statistics of the requests duration.
• finalize(): The Application's destructor function is ideal to put the system-wide cleanup code.

The Session object is a subclass of the virtual WOSession class. Your Session class has one instance per HTTP connection. WebObjects creates all instances for you, but you have to use the following definition:

public class Session extends WOSession

The main use of the Session class is to hold connection-specific information and business logic. Under the hood, it's also in charge of terminating itself and holding the Editing Context (database objects). You will notice that most of the functions you can overload are similar to the Application's. This is so you can decide the scope of your overloaded code. Typically, you overload at the Session level if the code is connection- or client-specific. The interesting functions are:

• Session() (Constructor): The constructor is called a single time shortly after WOApplication.awake() is called, but won't be called again for the current client. This function is ideal to put the connection-specific initialization code.
• awake(): Called by the framework when there's a new request, during WOApplication.awake(), before WebObjects begins processing the request. The base implementation calls WOComponent.awake(). Overload to call request-specific initialization code.
• takeValuesFromRequest(WORequest, WOContext): Called during Application.takeValuesFromRequest(). The base implementation calls takeValuesFromRequest().in the page that was requested. This function should be overridden when you want to process the Request object from the Session object.
• WOResponse infokeAction(WORequest, WOContext): Called during Application.invokeAction(). The base implementation executes the action associated to a Request by calling invokeAction() in the page that was requested. This function should be overridden if you intend to act upon the action itself (for example, to stop one from being executed), depending on a client-specific state.
• appendToResponse(WOResponse, WOContext): Called during WOApplication.appendToResponse(). The base implementation calls appendToResponse() in the page that was requested. This function should be overridden to add to the Response, or for any post-action operation.
• sleep(): Called by WOApplication.sleep() after a request/response is done with, before WebObjects waits for the next one.
• finalize(): The Session's destructor function is ideal to put client-specific cleanup code.

The Component objects are subclasses of the virtual WOComponent class. There can be multiple instances of a Component, and they are usually represented by local references.

WebObjects creates an instance of the Component with the name "Main" for you, returning it to the client browser, but you have to use the following definition:

public class Main extends WOComponent

You are responsible for creating instances of other Components. Usually, a Component is returned when an action is invoked. In that case, you create an instance of a Component by using this syntax:

WOComponent anAction() {
  return pageWithName("ComponentName");
}

The main use of the WOComponent subclass is to hold page-specific data and logic. On top of that, Components have the ability to generate the result page (using method generateResponse()). Again, most of the functions you can overload are similar to the Application's and the Session's. Typically, you overload at the Component level if the code is page-specific. The functions you can overload are:

• Web Component Constructor: The constructor is called when pageWithName() is called. This function is ideal to put the page-specific one-time initialization code. Use awake() to put page-specific per-request initialization code.
• awake(): Called by the framework when there's a new request, during WOSession.awake(), before WebObjects begins processing the request. The base implementation does nothing. Overload to call page-specific per-request initialization code.
• takeValuesFromRequest(WORequest, WOContext): Called during WOSession.takeValuesFromRequest(). The base implementation calls WOElement.takeValuesFromRequest(), where WOElement is the root element () of the hierarchy of the page. The function is then called recursively on each element of the hierarchy. This function should be overridden when you want to process the Request object from the current page.
• WOResponse infokeAction(WORequest, WOContext): Called during WOSession.invokeAction(). The base implementation executes the action associated to a Request directly. This function should be overridden if you intend to act upon the action itself (for example, to stop one from being executed), depending on a page-specific state.
• appendToResponse(WOResponse, WOContext): Called during WOSession.appendToResponse(). The base implementation calls WOElement. appendToResponse(), where WOElement is the root element () of the hierarchy of the page. The function is then called recursively on each element of the hierarchy. This function should be overridden to add to the Response, or for any post-action operation.
• sleep(): Called by WOSession.sleep() after a request/response is done with, before WebObjects waits for the next one. Ideal for per-request page-specific cleanup code.
• finalize(): The Component's destructor function is ideal to put one-time page-specific cleanup code. Use sleep() to call per-request page-specific cleanup code.

There's an object that I skipped on purpose here, the WOElement object. You usually don't subclass this class, unless you want to write your own customized elements. You can avoid this trouble by using custom components instead, which is easier to write. The interesting member functions are the constructor, takeValuesFromRequest(), invokeAction(), appendToResponse() and finalize(). The usage of these functions should be trivial.

As stated before, the Request class encapsulates a Get or a Post HTTP request. The base class for WORequest is WOMessage, so some of the characteristics explained here are inherited from that base class.

The framework uses an instance of WORequest to pass it around during the pre-generation phase (awake(), takeValuesFromRequest() and invokeAction() functions). Here's a partial list of the information held in this class:

• A list of "cookies" (cookies are key/value pairs stored in the client's Browser). Keys are user-defined only. Cookies will be discussed in their own section.
• A list of all submitted form fields when applicable (Post request only). Form fields will be discussed later on.
• A list of "headers" (headers are key/value pairs containing the context of the request).
• The bits that make up the requested URL.
• Other request information (encoding, languages, protocol, request type).

I will skip cookies and form fields; they are covered later on. As for headers and the other information, there's no prescribed way of using these. It's up to you to figure out how to use them in your advantage. I can only show you how to access them. Following is an overview of the available functions.

Headers

Accessing headers is done with these functions of the class WORequest:

• NSArray headerKeys (): Returns a list of all available header names as Strings. Use these as keys in functions headerForKey() and headersForKey().
• String headerForKey(String) and NSArray headersForKey(String): These functions return the value (or values) of a header, when you pass the header's name (key). Use the first for single-value headers, and the second for multiple values.

But what are the fundamental request headers and what are they used for? Here's a link that lists some of the basic request headers:

http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html

But there may be other headers, because some are specific to the Web browser. To find out about those extra headers, the first thing that comes to mind is to overload takeValuesFromRequest() in one of Application, Session or Main, and print them out.�The following piece of code does exactly that:

public void takeValuesFromRequest(WORequest r, WOContext c) 
{
  super.takeValuesFromRequest(r,c);
�
  if(r.headerKeys() == null) return;
  for(int i=0; i< r.headerKeys().count(); i++) {
    String key = (String)r.headerKeys().objectAtIndex(i);
    NSArray values = r.headersForKey(key);
    System.out.println("Found header " + key + 
      ": " + value.toString());
  }
}

Here's what the output might look like:

Found header: accept-charset = ("iso-8859-1,*,utf-8")
Found header: accept-language = (bg)
Found header: accept-encoding = (gzip)
Found header: connection = ("keep-alive")
Found header: user-agent = ("Mozilla/4.6 [en] (WinNT; I)")
Found header: host = ("localhost:3878")
Found header: accept = ("image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*")
Found header: referer = ("http://www.imaginarypenda.com/gotosite.html")

Dismantling URLs

Next, let's have a look at the functions returning the parts of the requested URL. Let's use an example for each function. Imagine the user wrote the address:
http://www.imaginarypenda.com/cgi-bin/WebObjects/App

Here are the methods of WORequest to take a URL apart:

• String uri(): Returns the last part of the whole URL, from the first slash to the end. For example, if the user typed the URL above, this method should return "/cgi-bin/WebObjects/App".
• String adaptorPrefix(): Provides the adaptor's name. For example it could be "/cgi-bin/WebObjects/" on Mac OS X or Unix, or "/cgi-bin/WebObjects.exe/" on Windows. This example shows the CGI adaptor prefix; it may be different if using a native Web server adaptor.
• String applicatioNumber(): Returns the user-requested application number, when provided. This information is usually not provided by the user in the URL (as not shown above). In these cases, this functions returns -1 and meaning any one instance of the application was called.
• String applicationName(): Returns the application's name. In our example, it is "App".

Let's dissect some URLs and see which function return which part. Here are three examples.

• The first example below shows a MacOS X-based server, pointing to any instance of Find-A-Luv (no instance number). In this case, applicationNumber() will return -1.
• The second is a Windows-based server, pointing to any instance (we could have skipped the -1).
• The third is a Unix-based server, with native adaptor (no CGI involved), and pointing to the third instance.

http://www.aUrl.com   /cgi-bin/   WebObjects/          /   Find-A-Luv
http://www.aUrl.com   /cgi-bin/   WebObjects.exe/        -1   /   Find-A-Luv
http://www.aUrl.com   /WebObjects/      3   �   Find-A-Luv
�   adaptorPrefix()      applicationNumber()      applicationName()
�   
�   uri()

Other Request Info

Following is an brief overview the "other information" functions:

• method() String Any valid HTTP method, like "GET", "PUT, "POST", "HEAD", etc. See http://www.w3.org/Protocols/HTTP/ Methods.html for a complete list of methods and their usage.
• browserLanguages() NSArray of String The list of languages (see your browser's language preferences).
• content() NSData Always null unless there was raw data posted with the request.
• httpVersion() String For example, "HTTP/1.0".
• userInfo() NSDictionary A set of key/value pairs, passed around during the processing of the request. Empty by default, but you can use it to convey data around the framework.

I don't want to spend too much space on these functions since their usefulness is limited.

The Request's counterpart is the Response object, which encapsulates the page returned to the requesting browser. The WOResponse class is also a subclass of WOMessage, so some of the characteristics we'll cover come from that base class.

Typically, the Response object is created by the framework and passed around the elements hierarchy during the generation phase. Then it is passed to the Component, Session and Application objects, during the post-generation phase. All of this is accomplished by function appendToResponse().

The information in this object is very similar to the Request object. The difference is that you can change this information, and write to the buffer holding the returned page. Here's an overview of the kind of information you can get and set:

• A list of cookies. Cookies will be discussed in their own section.
• A list of resulting headers.
• The actual contents of the returned page.
• Other request information (status, encoding, protocol).

Response Headers

We saw how to get headers in previous sections. The same getter functions exist in the WOResponse object (headerKeys(), headerForKey(), headersForKey()). On top of that, you can set the headers returned to the browser:

setHeader(String value, String key) and setHeaders(NSArray values, String key): These functions fix the value (or values) of a header, given its name (key). Use the first for single-value headers; use the second for multiple values.

A list of basic response headers can be seen at:�
http://www.w3.org/Protocols/HTTP/Object_Headers.html

Response Text

For getting and setting the contents of the returned page, WOResponse has many methods. Here are a few of them:

• NSData contents(): The raw bytes that constitute the returned HTML. An NSData object encapsulates an array of bytes (byte []), and the interesting functions are bytes() and length().
• setContent(NSData): Replaces the whole returned page with the one you provide.
• appendContentString(String): Adds the specified string to the end of the resulting page without changing anything.
• appendContentHTMLString(String): Adds the specified string to the end of the page, but escapes the HTML-specific characters. For example, the character '<' will be changed to '&lt'.

WARNING: you usually don't want to use setContent() because it wipes out the previously computed HTML. Use the append...() methods instead.

Other Response Info

The "other information" methods of WOResponse include:

• defaultEncoding()
  setDefaultEncoding(int) Gets and sets the default encoding, specifying the character set that should be used by the returned contents.
• contentEncoding()
  setContentEncoding(int) Gets and sets the encoding, specifying the character set that is being used by the returned contents.
• httpVersion() Gets and sets the a string indicating the protocol format
• status()
  setStatus(int) Gets and sets the status, indicating if the generation was successful (status() returns 200) or if an error occurred. See this page for a list of status codes: http://www.w3.org/Protocols/HTTP/HTRESP.html
• userInfo()
  setUserInfo(NSDictionary) A set of key/value pairs, passed around during the processing of the response. Empty by default, but you can use it to convey data around the framework.

As you've seen here, there is more to a request/response loop than simply asking for a page and getting the HTML back. Many objects and methods are called along the way. As we've seen, most of the methods can be overloaded to intervene in the loop at a specific moment. We've also looked at the ways to manipulate the request and response themselves. Again, what to do with this knowledge is up to you, but I can almost hear your brain pondering.

Emmanuel Proulx is a Course Writer, Author and Web Developer, working in the domain of Java Application Servers. He can be reached at emmanuelp@theglobe.com.