Custom Web Publishing Guide

Chapter 5
|
Developing FileMaker XSLT stylesheets 63
Using content buffering
When content buffering is disabled, the Web Publishing Engine streams the result of an XSLT
transformation directly back to the client. Content buffering is always disabled unless you explicitly enable
it. If you enable content buffering, the Web Publishing Engine stores the transformed content until the entire
transformation is finished.
Content buffering is required for XSLT stylesheets that manipulate headers. Because headers are written
before the response body, the body must be buffered so that the added header information can be included.
There are four FileMaker extension functions that require the XSLT transformation result to be buffered:
1 fmxslt:create_session(): See “Using the session extension functions” on page 64.
1 fmxslt:set_header(): See “Using the header functions” on page 67.
1 fmxslt:set_status_code (): See “Using the header functions” on page 67.
1 fmxslt:set_cookie(): See “Using the cookie extension functions” on page 68.
In order for these FileMaker extension functions to work properly, you must include the following XSLT
processing instruction in the top level document for the request:
<?xslt-cwp-buffer buffer-content="true"?>
Important If you have a base stylesheet that includes another stylesheet, then the base stylesheet must
include the <?xslt-cwp-buffer?> processing instruction. This instruction is ignored if it is used in an included
stylesheet.
A benefit of using the processing instruction to buffer the response is that the Web Publishing Engine can
determine the length of the response and set the Content-Length header in the response. Buffering the
response might reduce the Web Publishing Engine’s performance.
Using Web Publishing Engine sessions to store information between requests
You can use the Web Publishing Engine’s server-side sessions to track and store any type of information
between requests. Sessions allow you to create a web application that is able to maintain state by using
persistent arbitrary pieces of information between requests. For example, user client information that is
entered on a first form page could be stored in a session and then used to populate values on a subsequent
page.
By default, the Web Publishing Engine will use a cookie to store the session ID. To accommodate clients
that do not allow cookies, you can use the
fmxslt:session_encode_url() function to add the Session ID to the
URL. To guarantee compatibility in all situations, it is recommended that you encode all URLs written out
to the page with the
fmxslt:session_encode_url() function. This function adds to your URL a semicolon-
separated parameter called
jsessionid, which is the identifier for the particular client’s parent session.
For example, instead of placing the following link on a page:
<a href="my_stylesheet.xsl?–db=products&–lay=sales&–grammar=fmresultset&–findall">hyperlinked text</a>
You should encode all links on a page as follows:
<a href="{fmxslt:session_encode_url('my_stylesheet.xsl?–db=products&–lay=sales&–grammar=fmresultset
&–findall')}">hyperlinked text</a>