File Readers

You can create custom text file readers to process text files before they are imported into your website table.

Your file readers are located at user.publisher.textFileReaders. They are called, each one in turn, before the built-in file readers at html.data.textFileReaders.

This is an advanced topic, and is not necessary for most uses of Content Server.

Creating a new file reader

To create a new file reader, create a new script in that table.

Here's an example table with two custom file readers created:

In the above example, we've named the file readers by the creator application. This is a good convention to follow.

Parameters

An example:

on myFileReader (f, adrTable)

Return values

If your file reader does want to handle the page, it needs to place two entries in the page information table. Its return value should be 'true.'

A very simple example of a file reader might look like this. This example reads files created by the imaginary application named "MyHTMLEditor."

How it works:

Note that the script is named for the application that created it. When implementing file readers for specific creating applications, it's a good idea to do this.

If the file isn't a text file, the script returns false. It doesn't want to handle it.

Content Server only sends you text files, but you may still want to leave this check in should Content Server's behavior change or in the case of other suite's also using your custom text file readers.

We then read the page text and look for a "magic string" inside the file that identifies it as a text file created by "MyHTMLEditor." This magic string will vary depending on the creator application, though many creator apps support the standard of a meta-generator tag.

If the script doesn't find the magic string, it returns false. It doesn't want to handle this file.

If it does find the magic string, it calls a routine in the html suite that retrieves parts of the page. The script gets the title and pagetext from the html.getOneTagValue routine.

Then the script does a little custom processing: it converts all <P>s in the page text into two carriage returns. Your scripts probably will do more than this, but this is just a basic example.

Before the scripts returns 'true' (meaning that it handled the file) it places the title and pagetext into the table whose address was the second parameter passed to the script.

Finally, the script returns 'true,' meaning that it handled the file.

Next: Hooks