This section has three main purposes:
- To detail which fields in the Table will be receiving which values from the XML file.
- To optionally detail which fields should be used as extra parameters in the Request (to narrow down the information to be returned in the XML).
- To optionally detail which fields should be used in 'cache control' – used when the lookup is not performed 'Always' (see General Settings).
The field mapping can also recursively work through recordlink and multi-record link fields in the Table to map fields on the linked Table.
Select the Table which will receive the imported data.
Response record element XPath
Enter the XPath to specify where in the XML file structure the fields to be imported will be found. This is typically one or more element names separated by slashes.
For a typical RSS feed, this is: rss/channel/item
For each value that is to be considered by the lookup, you need to add an entry to the Fields list.
First specify the field in the table. This will receive the imported value from the feed.
The remaining options available in this dialog will vary slightly depending on the datatype of the table field selected.
Include in cache control
If this checkbox is checked, and the General Option “Perform Lookup” is set to “When no matching records in table”, then the lookup will not be performed if there is a record in the table whose field's value matches the search string.
If multiple fields have this checkbox checked, then they will all need to match in order to prevent the lookup being performed.
If the lookup is not being triggered by a user's search or by a Test tab form (which provides its own search form) then the cache control is no relevant, and the lookup is always performed.
Request parameter name
If the value entered in the search string is to be passed forward to the feed server as a parameter (to affect or restrict the records returned) then this field should contain the name of the parameter as it should appear in the request querystring.
If the lookup should only be performed if the search string is greater than a certain length, enter the minimum acceptable length. If the search string is less than this the lookup is skipped, but the query is still executed, returning an matching fields from the underlying cache table to the user.
See 'Minimum length' above. This defined the maximum acceptable length of the search string.
This identifies the element in the XML file containing the value to be stored in the table field.
Whilst normally used, it is technically possible to leave this blank if the mapping is only being used to define a request parameter, and there is no returned value to store. However even if left blank, you still need the field to be present in the table.
See: XPath Namespaces for example syntax.
Response value prefix
Any string entered here is prepended to the beginning of the returned value before it is stored in the table field.
Response value suffix
Any string entered here is appended to the end of the returned value before it is stored in the table field.
The cache Table Field mapping dialog specifies the mapping of values in the feed file to fields in the Table. The exact behavior of the import depends on the datatype of the field in the table:
If text is being imported, its value is imported verbatim, truncated as necessary to fit.
If an image is being imported, the text field will contain the URL of the image.
The value is imported verbatim.
The value is imported verbatim, preserving any HTML formatting.
If the feed contains an URL to an image, the image will be imported.
The image will keep its original filename (excluding any path elements). The filename must be unique within the scope of the table record to avoid overwriting other images associated with that record.
If filename collisions will be an issue, consider storing the images in a separate table, joined to the main table. That way each image will be in its own record, and collisions will become impossible.
If cache-control is selected on an image datatype, then the images will always be imported, (even for records that already exist, in order to determine if the image itself has changed - the comparision is not simply based on whetehr the filename has changed). This can add significantly to the duration and bandwidth requirements of the process.
Files are treated in the same way as Images.
A wide range of ISO date formats are understood and imported.
Mon, 23 Aug 2010 15:33:03 +0100 (EDT)
The lookup will select the matching value (case sensitive comparison).
If there is no match, and a default value has been defined for the dropdown field, then the default will be used, otherwise no value will be selected.
Cache control will be tested against the Record Identifier of the linked Table, or to a specified field from the linked Table. (If the specified field is itself a Record Link field, then the process carries forward into that linked Table. This may continue any number of times)
If no match is found, a new record will be created in the linked Table.
Multi Record Link
Works in the same way as Record Link - see above