The Rendering Model

Understanding OCE URLs

When a rendering request is received by the OCE-Server application, the path components of the request URL are broken down into site, section, url handler and other information.

OCE URLs typically obey the following format:

http://domain.name/section/path/OCE_Feature/123/1

where:

domain.name - the DNS name (or IP address) identifying the site
/section/path - the section path referenced in the OCE navigation system
/OCE_ - URL handler prefix (default across all URL handlers)
Feature - the "name" portion of a specific OCE URL handler class
/123/1 - "other information" required by the URL handler in question

All URL components following the domain name/IP address are optional. The "other information" portion of the URL may or may not be compulsory depending on the URL handler requested. This is explained in further depth below.

OCE URL Handlers

OCE URL handler classes are used to interpret URL information for specific rendering purposes. For example, the default URL handler class ("OCE_Feature") is responsible for rendering feature pages from the OCE content database.

The name of the handler class to use is derived by appending a reserved URL prefix (common to all handlers) to a unique name for the class. The default prefix is "OCE_"; the remaining characters up to the following slash are used for uniquely identifying the class (e.g. "Feature"). The full class name for the previous example thus becomes "OCE_Feature".

The "OCE_Feature" URL Handler

This URL handler expects the following details to be provided in the "other information" portion of the URL:

Details in red are required for all requests.

If the feature page index is not present, it will be assumed the first page (0) was requested.

In previewing mode, the page version index (if provided) allows specific page versions to be rendered, regardless of whether the version has been authorized for publication or not. During publication, the page version index will be ignored (the version of the page currently deemed the live one will be rendered).

Internally, the OCE_Feature handler renders pages using the "OCEFeatureTemplate" wocomponent, which selects the appropriate site template wocomponent (determined from the site and section), and the appropriate wocomponents to render each of the individual page components. The template and page components are of course full wocomponents, and can thus undertake dynamic rendering decisions on a per-request basis.

Custom URL Handlers

In addition to using the built-in OCE_Feature handler, which is ideal for rendering OCE-Content objects, additional URL handlers can be written. For example, if publishing on the web a mixture of OCE-managed content and news articles from an automated feed or another database, a URL handler could be written to allow access to a particular news article (with a URL such as http://my.site/news/OCE_News/456).

See the JavaDoc documentation for further advice on implementation.

Publishing

The OCE-Server application is responsible for rendering and generating pages; but this is just one part of the OCE publishing system.

The OCE integrates with a web server through the use of a HTTP 404 error handler (currently written in Perl). When a user makes a request for a page, the page may already be on the disk, in which case it is served statically and very quickly. If the page is not stored in the cache the 404Handler will be invoked by the web server, which makes a sub-request to OCE-Server to retrieve the rendered content.

Once the page is rendered, the 404Handler will check custom headers in the returned page to determine whether the page should be cached to disk, and for how long.

Two separate processes are responsible for expiring content. The 404Cleaner script runs at regular intervals (in synchronous fashion) to remove outdated content. The DeleteFeature script can be invoked in a manual asynchronous fashion (from a client application or similar) to clear a particular feature from the cache; all related cached pages within the document root will be removed, causing the next request to trigger the 404Handler script and hence another rendering cycle.

Both the page template and all of the page components can modify the duration for which the page will be cached, so any page element which requires re-rendering in order to stay up to date can easily ensure it will be regenerated when required.