Custom Web Publishing Guide

Accessing XML data with the Web Publishing Engine 35
Switching layouts for an XML response
The –lay query parameter specifies the layout you want to use when requesting XML data. Often, the same
layout is appropriate for processing the data that results from the request. In some cases, you might want to
search for data using a layout which contains fields that, for security reasons, don’t exist in another layout you
want to use for displaying the results. (To do a search for data in a field, the field must be placed on the layout
you specify in the XML request.)
To specify a different layout for displaying an XML response than the layout used for processing the XML
request, you can use the optional –lay.response query parameter.
For example, the following request searches for values greater than 100,000 in the Salary field on the Budget
layout. The resulting data is displayed using the ExecList layout, which does not include the Salary field.
http://192.168.123.101/fmi/xml/fmresultset.xml?-db=employees&-lay=Budget&Salary=100000&Salary.op=gt&-find
&-lay.response=ExecList
Understanding how an XML request is processed
There are several query parameters that affect the processing of an XML request and the generation of an XML
document.
Here is the order in which FileMaker Server and the Web Publishing Engine process an XML request:
1. Process the –script.prefind query parameter, if specified.
2. Process the query commands, such –find or –new.
3. Process the –script.presort query parameter, if specified.
4. Sort the resulting data, if a sort was specified.
5. Process the –lay.response query parameter to switch to a different layout, if this is specified.
6. Process the –script query parameter, if specified.
7. Generate the XML document.
If one of the above steps generates an error code, the request processing stops; any steps that follow are not
executed. However, any prior steps in the request are still executed.
For example, consider a request that deletes the current record, sorts the records, and then executes a script. If
the –sortfield parameter specifies a non-existent field, the request deletes the current record and returns error
code 102 (“Field is missing”), but does not execute the script.
Using server-side and client-side processing of stylesheets
The Web Publishing Engine supports server-side processing of an XSLT stylesheet, and also allows you to use
a query parameter that specifies client-side processing of a stylesheet.
It is important to understand the differences between the two ways to process stylesheets, and the security
implications of using client-side processing. Server-side processing is more secure than client-side processing
because server-side processing does not give web users access to the unfiltered XML data. With server-side
processing, the data is presented in a form that the data owner or the XSLT stylesheet author decides is
appropriate to present. Server-side processing hides the database names, field names, and other
implementation details from web users. Server-side processing can also be used to specify statically defined