The Cofax Java Framework
Across the tiers a shared library of Java classes are utilized that make up the Cofax API.
The API allows any developer to add functionality to Cofax without having to modify the base source code. A vendor can write all sorts of plug-in modules to add new features to Cofax.
This API includes, but is not limited to, the following:
Template Loading Classes
Templates can be used from various sources. By abstracting out this process, a Template Loading Class can be implemented to load a from a web server across the internet, a SQL Server you have access to, or in our default implementation, from your file system.
Template Application Classes
These parse and apply templates to content. Different template classes can be used to work with different types of templates. For example, we currently use our WSIWYG Templates. Our WSIWYG Templates are an easy way use HTML files marked up with special comment tags. Using WSIWYG Templates, a designer can "view source" a live page, static or dynamic, make changes, ensure that the comment tags are in place and the template is immediately usable. Another class can use XSL templates instead. Other classes could be easily written to use other conventions/systems for templates. Our WYSIWYG Template system also works with templates that are applied in a hierarchical structure. For example, a master template is applied to all Inquirer stories if no section-specific templates are found. If a story-specific template is found, then it overrides the section template. This makes the system very flexible. A designer can either apply one template for everything, or use specific templates for section (i.e. sports) and even individual items. In addition different hierarchies of templates can be applied to the same content set for different sites! (In Rajiv's bias opinion, no other system in the market has these features.)
Data Store Handling Classes
These can load and parse data from various sources and create a content object. One class is able to load the content from XML files. Another class is able to load the content from Cofax' s SQL database. Other custom classes could be written to load content directly from the back-end newsprint-publishing system's export data or by directly querying the newsprint system's database. One of the features of these classes is that they can be used to convert/transfer content from one source to another. Any pair of these classes serves as a conversion-filter program. Another advantage is that the Cofax System is not tied to any one particular type of backend system. It can already use SQL, ODI, flat-file-XML as the data store. Other classes can be written to work with other kinds of data stores. If computer-resources permit, Cofax can even use some newsprint publishing systems as the data store.
One of the test modules/classes, which was developed for Cofax could load data from MediaStream's remote web server. Such a class with remote content wrapping and caching technology can even enable Cofax to use a remote web site as a data store.
The data store has been carefully designed. It has several architectural advantages. Here is an example:
Cofax stores where an article goes in the sections/mappings container (articles to sections/mapping table in case of an SQL data store) and not in the articles container (articles table in case of an SQL data store).
A sections/mapping entry describes which section/channel page the article will show up in (the mapping code), and where on that page the article will show (the position/ranking code), and from when to when the article will show up there (the start and end dates). Using this scheme, Cofax is able to make an article appear on different pages at different places at different times. Since the position/ranking code is specific to the section/mapping page, it can mean placement on the top cell on the home page or show at the bottom on another given page.
These provide a wrapper and to the Cofax Functionality and the interface to the presentation system in use. We currently have two versions: Java Servlets that will work on any Servlet enabled web server. COM objects for use from ASP. Other classes could be written to work with other front-ends.