Custom Web Publishing Guide

14 FileMaker Server Advanced Custom Web Publishing Guide
1 Some new query commands and parameters have been added, and some have become obsolete. To
access data in a database, you must specify a layout. For security reasons, accessing data without
specifying a layout is no longer supported. See
appendix A, “Valid names used in query strings.”
1 Each web user can have a unique global field value that persists as long as a session is active. For general
information on global fields, see FileMaker Pro Help. For information on using global fields with
Custom Web Publishing, see
“About the syntax for specifying a global field” on page 88.
FileMaker scripts and Custom Web Publishing
The ScriptMaker
™
feature in FileMaker Pro is useful for automating frequently performed tasks, or for
combining several tasks. When used with Custom Web Publishing, FileMaker scripts allow web users to
perform more tasks or a series of tasks.
FileMaker supports about 70 script steps in Custom Web Publishing. Web users can perform a variety of
automated tasks when you use scripts in a query string for a URL or in a
<?xslt–cwp–query?> processing
instruction in an XSLT stylesheet. To see script steps that are not supported, select the
Indicate web
compatibility
checkbox in the Edit Script dialog box in FileMaker Pro. Dimmed script steps are not supported
on the web. For information on creating scripts, see FileMaker
Pro Help.
Script tips and considerations
Although many script steps work identically on the web, there are several that work differently, as described
in the table below. Before sharing your database, evaluate all scripts that will be executed from a web
browser. Be sure to log in with different user accounts to make sure they work as expected for all clients.
Keep these tips and considerations in mind:
1 Use accounts and privileges to restrict the set of scripts that a web user can execute. Verify that the scripts
contain only web-compatible script steps, and only provide access to scripts that should be used from a
web browser.
1 Consider the side effects of scripts that execute a combination of steps that are controlled by access
privileges. For example, if a script includes a step to delete records, and a web user does not log in with
an account that allows record deletion, the script will not execute the Delete Records script step.
However, the script might continue to run, which could lead to unexpected results.
1 In scripts, select Run script with full access privileges to allow scripts to perform tasks that you would not
grant individuals access to. For example, you can prevent users from deleting records with their accounts
and privileges, but still allow them to run a script that would delete certain types of records under
conditions predefined within a script.
1 If your scripts contain steps that are unsupported, for example, steps that are not web-compatible, use the
Allow User Abort script step to determine how subsequent steps are handled.
1 If the Allow User Abort script step option is enabled (on), unsupported script steps stop the script from
continuing.
1 If Allow User Abort is off, unsupported script steps are skipped over and the script continues to execute.
1 If this script step is not included, scripts are executed as if the feature is enabled, so unsupported script
steps stop scripts.