FAQ : Frequently Asked Questions
FAQ Table of contents
blue line
21. Q:  Is there any way to dynamically merge other html scripts into a given html?

A:  In a sense you are requesting something like a /copy pre-compiler function. This could be extremely useful when you have many html pages sharing some pieces of html/javascript. A /copy-like function would allow to keep these common pieces external, and to include them wherever needed, thus reducing both html scripts development time and maintenance.

What, at least in my opinion, would be needed is some include function to be interpreted / executed from the client browser at page load time. Unluckily, nothing like this -- as far as I know -- is available. This means that any include function must be carried over from the server site.

There are two ways you can obtain this dynamic merging:

  1. using subprocedure gethtmlifsmult in your CGI.
    This subprocedure allows to load in memory several external IFS files containing html code. This subprocedure is highly recommended whenever several CGI's share some HTML code.
    See this page for details.
  2. including external JavaScript code
  3. using Server Side Includes.

blue line

Imbedding external JavaScript code

The SRC attribute of the <SCRIPT> tag lets you specify a file as the JavaScript source (rather than embedding the JavaScript in the HTML). For example:
<SCRIPT SRC="common.js">
</SCRIPT>

This attribute is especially useful for sharing functions among many different pages.

The closing </SCRIPT> tag is required.

The SRC attribute can specify any URL, relative or absolute. For example:
<SCRIPT SRC="http://home.netscape.com/functions/jsfuncs.js">

External JavaScript files cannot contain any HTML tags: they must contain only JavaScript statements and function definitions.

External JavaScript files should have the file name suffix .js, and the server must map the .js suffix to the MIME type application/x-javascript, which the server sends back in the HTTP header.
To map the suffix to the MIME type, add the following directive to the (traditional) HTTP configuration member:
      AddType .js application/x-javascript 8bit
If the server does not map the .js suffix to the application/x-javascript MIME type, the browser may improperly load the JavaScript file specified by the SRC attribute.


blue line

HTTP Server-Side Includes (SSI) provide these type of functionalities (for extended information on SSI, please check Using Server-Side Includes in HTTP Server for AS/400 Web Programming Guide).

Server-side includes allow you to insert information into dynamically created (via CGI) and static HTML documents before the server sends them to the client.

Note 1- The way the HTTP server performs the SSI is to scan the document before sending it to the client. This task is extremely expensive in terms of CPU load. It is therefore recommended to limit the use of SSI to the cases really needed, in order to avoid substantial HTTP serving performance degradation. For instance, requesting SSI intervention on all static pages would cause perceivable response time degradation.

We are now going to describe the steps to implement include support for CGI created HTML pages.

  1. Add the following HTTP directive to your HTTP server configuration (command wrkhttpcfg ):
                  Imbeds CGI SSIOnly
    The Imbeds HTTP directive instructs the HTTP server about the SSI services to be performed. See HTTP Server for AS/400 Webmaster's Guide Section 1.1.3.4.
    • CGI: Server-side include processing is done only for documents returned by CGI programs.
    • SSIOnly: Server-side include processing is done for documents with a content type of text/x-ssi-html, and is not done for documents with a content type of text/html.
  2. In the CGI external html which should include other texts, replace the content type
    /$section_name
    Content-type: text/html

    <html>
    ... etc. ...
    		 with 
    /$section_name
    Content-type: text/x-ssi-html

    <html>
    ... etc. ...
    The HTTP server, instructed to run SSI for CGI pages with content type text/x-ssi-html, will just scan the documents if produced from a CGI and if content type = text/x-ssi-html. Therefore the SSI-processing extra load would be kept to the very minimum requested by such documents.
    Only when receiving a CGI-originated text/x-ssi-html document, the HTTP server would scan it looking for imbedded SSI directives.
  3. The SSI directive you need to specify in the CGI external html script -- in order to have the HTTP server including another piece of html -- is:
          <!--#include virtual="/path/file" -->
    where
          /path/file
    are the path and the file name to be included, before being interpreted from the HTTP server configuration mapping directives.
Note 2. In your CGI external html include similar SSI directives in any point you want another piece of html be included. You can have more than one such SSI directive in a given external html.
Note 3. It must be clear that --as the inclusion(s) is (are) done by the HTTP server after receiving the html buffer from the CGI-- the html pieces to be included are not visible to the CGI, in other words "the html pieces to be included" are static.
Should you need to include dynamic pieces (that is, pieces to be processed from a CGI), then you should better refer use our gethtmlifs subprocedure.

blue line