3.3 Redirecting Template Page for Response Output

Sometimes it is desirable to display a page other than the default (change the delivery mechanism for the response template) after executing a CGI request (either a GET or a POST). For example, you might want to redirect the page after a login or after executing a search. One way to do this is by modifying the service call through the component architecture, and specifying a different template page. Another more flexible way to do this as needed is to specify the urlTemplate parameter, to redirect the response page to a HCSP or HCST, and reformat the results in any way you want.

This section covers the following topics:

3.3.1 Basic Concepts

You should be somewhat familiar with IdocScript, and Dynamic Server Pages (HCST, HCSP, HCSF) before attempting this exercise. You should also be somewhat familiar with Component Architecture. It would also be helpful to be familiar with HTML FORM objects.

3.3.2 Creating a HCST Page

As an example, we will create a HCST page that can be used as a URL template to reformat the search results. We could also create a HCSP, but for simplicity, we will use a HCST. We will name the file test_result.hcst, and have it contain the following text:

<table width=300>
<tr bgcolor="#000000" style="color: #ffffff;">
<td><b>Title (Author)</b></td>
<$loop SearchResults$>
<tr <$if doShade$>bgcolor="#E5E7D4"<$endif$>>
<td><a href="<$URL$>"><$dDocName$></a></td>
<td><$dDocTitle$> (<$dDocAuthor$>)</td>
<$if doShade$><$doShade=""$><$else$><$doShade="1"$><$endif$>

Next, we should check this file into the Content Server. For simplicity, we will check it into the Public security group, with a content type of ADACCT, and the Content ID test_result. Its URL will then be something like this:


3.3.3 Reformatting the Search Results Page

To test our new template, we will start by going to a search page. Enter in any search criteria and click Search. You should see the standard search page with your results contained in it.

Now, add this text to the end of the URL that brought you to the search results page:


You should now see the same search results formatted in a minimalist HTML page. Note how the full URL is not used, but just the URL relative to your host computer.

If you would like the default search page to always format pages with this template, you can change the HTML FORM object on the search page to also have this field:

<input type=hidden name='urlTemplate'

This can be done by creating a component that modifies the include query_results_options to contain the sample HTML. Alternatively, the value for urlTemplate can be calculated dynamically on the search page with JavaScript, to redirect to different pages based on the metadata entered by the user.

3.3.4 Additional Options

In addition to urlTemplate, you can also use the parameters docTemplateName, docTemplateID, or RedirectUrl to change the result page. These all have different behavior, as follows:

  • urlTemplate: Set to the full relative URL of the hcst page you want to use. For example:


    Because RedirectURL doesn't work with all service calls, and pre-6.0 versions of Content Server have minor data pollution bugs with docTemplateName and docTemplateID, it's usually safest to use urlTemplate. However, if you change the Content Type or the Security Group of your template, then the URL will no longer be valid and will need to be updated. Also, this parameter is not recommended for overriding the template used for a 'POST' service.

  • docTemplateName: Set to a dDocName of a template (for example, test_result). Like urlTemplate, but finds the location of the latest released Web-viewable for a document with dDocName of docTemplateName.

  • docTemplateID: Set to a dID of a specific revision of a template (for example, 100). Like docTemplateName, but finds the Web-viewable of a specific dID revision.

  • RedirectUrl: Set to the last part of a CGI URL back into the Content Server (for example, IdcService=DOC_INFO&dID=<$dID$>). This is only for the few dozen 'POST' services that execute the action prepareRedirect, such as CHECKIN_NEW and SUBMIT_HTML_FORM.

  • By using a redirect after each HTML 'POST', the response page can be safely refreshed by the end user without reissuing the post. In the definition of each of these services there is a 3:prepareRedirect:….:0:null line. The RedirectUrl overrides the results of the prepareRedirect method and allows a different URL to be used as the location for redirects. The RedirectUrl can have Idoc script in it that will be executed just before the redirect is issued. This can create complex Idoc script nesting, because the RediretUrl assignment will typically occur in a resource includes. For example:

    … Standard Idoc form beginning …
    <input type=edit name=myparam value=''>
    <input type=hidden name=RedirectUrl
    … Standard Idoc form closure …

Much of the Idoc script is nested inside an Idoc literal string. This delays the execution of the script until the redirect URL is being computed. That allows the RedirectUrl to pick up the value of 'myparam' even though the user has still to select its value.

A single quote is used on the outside and a double quote on the inside. This reduces confusion and because both HTML and Idoc script support both single and double quotes for quoting, it is sometimes a good idea to switch between the two for nesting constructs.

Note the usage of the 'xml' function. This guarantees that the input field's value is a well-formed HTML literal string construct. In this particular case, it is not needed. But for more complex constructs it can be helpful.