DBPrism CMS is a Database oriented CMS, it means that unlike traditional CMS it stores content and metadata into the database.
Content and metadata is stored using Oracle XMLDB repository, it means that an annotated schemad based on Apache document-v20.xsd is used for controlling the syntax and the storage of the CMS documents.
Apache Cocoon framework is used on the server side, so the content produced by the database is aggregated, cached and transformed to produce the desired output format.
The content assets stored on the database side is automatically synchronized with Web server side using ESI invalidation protocol, it means that Cocoon will use always cached content until this content is changed by the content authors, at this point the database automatically sent a message to Cocoon notifying that the content was changed.
Each CMS user is a database user, it means that he have his own database schema and his own home a public XMLDB folders. Here a initial folder layout:
The CMS user edits the content asset on his /home/ private area, when he decides to publish the page, he uses the Front End application. The Front End Application creates a copy of the private page in the same directory on the public area.
The CMS user can link the public page in another location, it mean that the page is visible in two or more locations, when the user update the original location with a new version all the linked location are automatically updated.
The CMS user can link his public page in another public area owned by another CMS user, in that case the CMS will put this publication action under approval state, and the owner of the target area can approve or reject the publication action.
DBPrism CMS stores his content assets into Oracle XMLDB repository, so it inherits the default behaviour of the resource_view storage. It means that your pages in a CMS menu will be sorted using alphabetical order.
Oracle XMLDB repository provides linking to resources. DBPrism CMS uses this functionality into the public area for creating the same content into two or more different locations of the web site, it means that you can publish your page into an as /docs/readme.xml and create multiple links to this resource, for example into the directories /developers/docs/ and /visitors/docs/ When you decide to update the public content with the private value, the operation automatically will refresh the content of /docs/readme.xml /developers/docs/readme.xml and /visitors/docs/readme.xml .
DBPrism CMS provides a publishing workflow of two stages using the private and the public area, but you can extend it using multiples database/schema users. Each CMS user has his own private/public stage, but its not necessary to provide a public site for each CMS user, because this functionality its configured using Cocoon sitemap.xmap file
Then using multiples users and linking you can provides an N-step workflow. Here a practical example:
Your company has two content authors (author1,author2) and a revisor which control the content of the two authors and decide if is published or not, and the webmaster who control the company website.
- Create multiple users, for example author1, author2, revisor, and webmaster
- Configure the Cocoon sitemap using the public area of the webmaster
- The content authors and the revisor can mirror the site structure from webmaster's public area
- Author1 create a page in his private area, for example /docs/page1.xml
- Author1 publish his private page (/docs/page1.xml) into his public area, it not implies a public page on the company web site because is created using webmaster's public area
- Author1 create a link into the public area of the revisor, author1 do not have write permission into revisor's area, so the publishing operation is queued waiting revisor approve.
- The revisor can approve or reject the page of the author1, if he approve a link will be made into his public area linked to author1's content.
- Finally the revisor publish the content into webmaster's public area using the same operations as author1
DBPrism CMS is based on Apache Cocoon Frameworks, so the pressentation concerns and web design concepts are based into two primary artifacts, the sitemap.xmap file and the XSL styleshets.
For an in depth introduction to Apache Cocoon architecture please read the document Understanding Apache Cocoon .
In addition to the set of Apache Cocoon Generators which are responsible for producing the content, DBPrism CMS uses DBPrism Servlet Engine Generator . This generator is high performance Apache generator which gets the XML content from XMLDB repository using a Java Stored Procedure, this stored procedure is responsible for getting the content assets and making the CMS metadata for each pages. In addition to this generation it also add ESI invalidation protocol to provides an efficient caching algorithm between Cocoon internal cache system and content assets stored into the database side.
All the resources published by Apache Cocoon are controlled by the sitemap.xmap file which resides in the file system of the Servlet Container where DBPrism CMS was deployed. The webmaster responsibilities are to define which static resources are published.
DBPrism CMS's Ant tasks create a ear/war deployment files ready to use in many containers. You can add deployment resources using Cocoon's sub sitemaps concepts, look at the above link for more information and check the installation steps for more information about DBPrism CMS Ant's tasks.
