|
|
The first consideration to be made when sitting down to implement a web site with HyperContent is where will the data live, and where will it end up? HyperContent relies on a single FileSystem API to communicate with both the data repository and the destination for output. Multiple implementations of this API are included; the standard repository implementation uses a locally mounted filesystem and stores data, metadata, and historical revisions of files in a custom structure, as well as providing locking and full content searching. A local non-editioning version is available to publish standard data files to a locally mounted filesystem, and FTP and SFTP implementations make it possible to push content to a filesystem on a remote server, for example if your web servers are on different machines than HyperContent.
Up to four filesystems are configured for each project; a filesystem must be configured for the repository, and if the project is intended to produce output, preview, build and publish filesystems should also be configured. The preview space is for volatile renderings of content that may not be intended for publication. The build space is where current data is rendered to, and can be reviewed for accuracy before being published. The publish space is where built files are copied to in order to make them public. The preview, build and publish filesystem typically map into the document tree of a web server, so that their contents can be viewed with a browser.
Here is a sample configuration XML fragment that shows the four filesystems configured using the four main included implementations, with comments indicating what each of the arguments is.
|
|  |
