Instant Web Publishing Guide

Chapter 4 | Designing a database for Instant Web Publishing 34
Script steps tips and considerations
Although many script steps work identically on the web, there are several that work differently due
to design limitations. Before sharing your database, evaluate all scripts and buttons 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, you can 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 will stop
the script from continuing.
1 If the Allow User Abort script step is set to Off, (default), 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 will stop scripts.
1 Some scripts that work with one step from a FileMaker Pro client may require an additional
Commit Records/Requests script step to save the data to the host. Because web users don’t
have a direct connection to the host, they aren’t notified when data changes. For example,
features like conditional value lists aren’t as responsive for web clients because the data must
be saved to the host before the effects are seen in the value list field.
1 Similarly, any script that modifies data should include the Commit Records/Requests step,
because all data changes aren’t visible in the browser until the data is saved, or “submitted” to
the server. This includes script steps such as Set Field, Set Field By Name, Insert Text, Insert
Calculated Result, Insert from Last Visited, Insert Current Date, Insert Current Time, Cut, Insert
Copy, Copy Record/Request, Copy All Records/Requests, and Paste. Many single-step
buttons should be converted into scripted buttons to include the Commit Records/Requests
step. When you design scripts that are executed from a web browser, it’s a good idea to include
the Commit Records/Requests step at the end of a script to make sure all changes are saved.
1 To create conditional scripts based on the type of client, use the Get(ApplicationVersion)
function. If the value returned includes FileMaker Web Publishing you know that the current
user is accessing your database with Instant Web Publishing. For more information on
functions, see FileMaker
Pro Help.