The content repository does not place any restrictions on the methods employed for delivering content via a public server infrastructure. Applications are free to query the repository and process the data in any way desired.
Although there are no restrictions on publishing methodology, the repository API is intended to facilitate generic template-based publication, regardless of the specific presentation layer used. The following diagram illustrates the steps typically involved in such a publication process:
In general, there is an initial resolution step in which the server must identify the appropriate content item and then decide which template to actually parse. Following that is an execution step, during which setup tasks associated with the template is performed. Finally, the merging step combines the data and layout into a rendered page.
When you create a new content type or add an attribute to an existing content type, a view is created (or recreated) that joins the attribute tables for the entire chain of inheritance for that content type. The view always has the same name as the attribute table for the content table, with an "x" appended to distinguish it from the table itself (for example, if the attribute table for Press Releases is press_releases, then the view will be named press_releasesx. Querying this view is a convenient means of accessing any attribute associated with a content item.
Templates often display more than simple content attributes. Additional queries may be necessary to obtain data about related objects not described directly in attribute tables. The setup code associated with a template typically performs these queries after the initial query for any needed attributes.