Instant Web Publishing Guide
Table Of Contents
- Chapter 1 About publishing FileMaker Pro databases on the web
- Chapter 2 Publishing your database on the web
- Chapter 3 Working with FileMaker databases on the web
- Chapter 4 Designing a database for Instant Web Publishing
- Tips for designing layouts for Instant Web Publishing
- Tips for working with data in a web browser
- General database design considerations
- Working with graphics, sounds, and movies on the web
- Setting the initial layout and view
- Hiding the status area to customize the interface
- Specifying the sort order for web users
- Scripts and Instant Web Publishing
- Hosting databases with FileMaker Server Advanced: an overview
- Documenting your solution
- Chapter 5 Testing, monitoring, and securing your site
- Index
28 FileMaker Instant Web Publishing Guide
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 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 will stop scripts.
1 Some scripts that work with one step from a FileMaker Pro client may require an additional
Commit Record/Request 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 Record/Request step, because
all data changes aren’t visible in the browser until the data is saved, or “submitted” to the server.
This includes several script steps like Cut, Copy, Paste, and so on. Many single-step buttons
should be converted into scripted buttons to include the Commit Record/Request step. When
designing scripts that will be executed from a web browser, it’s a good idea to include the Commit
Record/Request 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 “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.
1 Because there are intermediary technologies involved when accessing a FileMaker Pro database
from a web browser, you must assess the activities on the web server before closing a file. Some
scripts open additional “windows” in the virtual FileMaker environment on the web server, and
they must be closed before the session can be terminated. Any open windows will be closed
automatically if web users click the
Log Out button or when the session times out. For more
information, see “
Creating a script to log out of a database and close the session,” below.
1 After converting your files, you should open each script that web users might run and enable
Indicate Web Compatibility to ensure that the script will execute properly with Instant Web
Publishing.