Custom Web Publishing Guide
Table Of Contents
- Chapter 1 Introducing Custom Web Publishing
- Chapter 2 Preparing databases for Custom Web Publishing
- Chapter 3 Accessing XML data with the Web Publishing Engine
- Using Custom Web Publishing with XML
- General process for accessing XML data from the Web Publishing Engine
- About the URL syntax for XML data and container objects
- Accessing XML data via the Web Publishing Engine
- Using the fmresultset grammar
- Using other FileMaker XML grammars
- About UTF-8 encoded data
- Using FileMaker query strings to request XML data
- Switching layouts for an XML response
- Understanding how an XML request is processed
- Using server-side and client-side processing of stylesheets
- Troubleshooting XML document access
- Chapter 4 Introduction to Custom Web Publishing with XSLT
- Chapter 5 Developing FileMaker XSLT stylesheets
- Using XSLT stylesheets with the Web Publishing Engine
- About the FileMaker XSLT Extension Function Reference
- About the URL syntax for FileMaker XSLT stylesheets
- About the URL syntax for FileMaker container objects in XSLT solutions
- Using query strings in FileMaker XSLT stylesheets
- Specifying an XML grammar for a FileMaker XSLT stylesheet
- About namespaces and prefixes for FileMaker XSLT stylesheets
- Using statically defined query commands and query parameters
- Setting text encoding for requests
- Specifying an output method and encoding
- About the encoding of XSLT stylesheets
- Processing XSLT requests that do not query FileMaker Server
- Using tokens to pass information between stylesheets
- Using the FileMaker XSLT extension functions and parameters
- About the FileMaker-specific XSLT parameters set by the Web Publishing Engine
- Accessing the query information in a request
- Obtaining client information
- Using the Web Publishing Engine base URI parameter
- Using the authenticated base URI parameter
- Loading additional documents
- Using a database’s layout information in a stylesheet
- Using content buffering
- Using Web Publishing Engine sessions to store information between requests
- Using the session extension functions
- Sending email messages from the Web Publishing Engine
- Using the header functions
- Using the cookie extension functions
- Using the string manipulation extension functions
- Comparing strings using Perl 5 regular expressions
- Checking for values in a field formatted as a checkbox
- Using the date, time, and day extension functions
- Checking the error status of extension functions
- Using logging
- Chapter 6 Testing and monitoring a site
- Appendix A Valid names used in query strings
- About the query commands and parameters
- Using the query commands
- -dbnames (Database names) query command
- -delete (Delete record) query command
- -dup (Duplicate record) query command
- -edit (Edit record) query command
- -find, -findall, or -findany (Find records) query commands
- -layoutnames (Layout names) query command
- -new (New record) query command
- -process (Process XSLT stylesheets)
- -scriptnames (Script names) query command
- -view (View layout information) query command
- Using the query parameters
- -db (Database name) query parameter
- -encoding (Encoding XSLT request) query parameter
- -field (Container field name) query parameter
- fieldname (Non-container field name) query parameter
- fieldname.op (Comparison operator) query parameter
- -grammar (Grammar for XSLT stylesheets) query parameter
- -lay (Layout) query parameter
- -lay.response (Switch layout for response) query parameter
- -lop (Logical operator) query parameter
- -max (Maximum records) query parameter
- -modid (Modification ID) query parameter
- -recid (Record ID) query parameter
- -script (Script) query parameter
- -script.prefind (Script before Find) query parameter
- -script.presort (Script before Sort) query parameter
- -skip (Skip records) query parameter
- -sortfield (Sort field) query parameter
- -sortorder (Sort order) query parameter
- -styletype (Style type) query parameter
- -stylehref (Style href) query parameter
- -token.[string] (Pass values between XSLT stylesheets) query parameter
- Appendix B Error codes for Custom Web Publishing
- Appendix C Converting CDML solutions to FileMaker XSLT
- About the process of converting CDML solutions to FileMaker XSLT solutions
- Conversion of CDML action tags, variable tags, and URLs
- Conversion of the -error and -errornum CDML variable tags
- Conversion of obsolete CDML action tags
- Conversion of supported CDML action tags
- Conversion of obsolete CDML variable tags
- Conversion of supported CDML variable tags
- Conversion of CDML boolean parameters to XPath boolean parameters
- Conversion of CDML boolean operators to XPath
- Conversion of CDML intratag parameters to XSLT-CWP
- Manually fixing CDML conversion errors
- Conversion of CDML replacement tags to XSLT-CWP
- Index
Valid names used in query strings 77
1 Database names, layout names, and field names used in query strings are case insensitive, such as
–lay=mylayout to specify MyLayout.
Note Field and database names that are used in XSLT statements outside of query strings are case sensitive
and must exactly match the actual names used in the database. For example, in this statement:
<xsl:value-of select="fmrs:field[@name='LastName']"/>
the field reference “LastName” must exactly match the name of the LastName field in the database.
1 For the –find command, the value of a field is case insensitive. For example, you can use Field1=Blue or
Field1=blue. For the –new and –edit commands, the case you use in the value of a field is preserved and
stored in the database exactly as you specify in the query string. For example, LastName=Doe.
About the FileMaker Query Strings Reference
The FileMaker Server Advanced CD includes a FileMaker database called Query Strings Reference.fp7 that
contains brief descriptions and examples of each of the FileMaker query commands and query parameters.
You can open the FileMaker Query Strings Reference in the Custom Web Publishing Reference folder on the
FileMaker Server Advanced CD.
About the syntax for a fully qualified field name
A fully qualified field name identifies an exact instance of a field. Because fields with common names can be
based on different tables, you must use fully qualified names, in some cases, to avoid errors.
The syntax for specifying a fully qualified field name is:
table-name::field-name(repetition-number).record-id
where:
1 table-name is the name of the table that contains the field. The table name is only required if the field is not
in the underlying table of the layout specified in the query string.
1 field-name(repetition-number) is the specific value in a repeating field, and is only required for repeating
fields. The repetition number starts counting at the numeral 1. For example, field-name(2) refers to the
second value in the repeating field. If you don’t specify a repetition number for a repeating field, the first
value in the repeating field is used. The repetition-number is required for the –new and –edit query
commands involving repeating fields, but it is not required for the –find command.
1 record-id is the record ID, and is only required if you are using a query string to add or edit records in portal
fields. See the following sections
“Adding records to a portal,” and “Editing records in a portal.” The
record-id is required for the –new and –edit query commands involving portal fields, but it is not required
for the –find command.
Note To be accessible, fields must be placed on the layout you specify in the query string.
Adding records to a portal
To add a new record to a portal at the same time you add a parent record, use the –new query command and
do the following in query string for the request:
1 Use the fully qualified field name for the related portal field.
1 Specify 0 as the record ID after the name of the related portal field.
1 Specify at least one of the fields for the parent record before specifying the related portal field.
1 Specify the data for the match field (key field) in the parent record.