The C2MS system is designed as an enterprise content management system that can manage both internal content as well as linked content. In order to deal with the many different types of content available as well as the varying promotion requirements typically found with each C2MS provides a block infrastructure. Blocks are best thought of as individual nuggets of content. A block can represent any type of content – an event, an image, a product or even a collection of other blocks like a slideshow of images. Developers must make the C2MS system aware of these content types by registering a new block type. Every block type will receive an entry in the cbmBlockType table, as well as optionally be associated with RenderType and PublishType classes (e.g. RenderSample, PublishSample). The Render class is responsible for loading the content and displaying it when placed within a user view. The Publish class is responsible for moving the block content between promotion stages.
Each block in the C2MS system is represented by an entry in the table “cbmBlock”. The cbmBlock table contains only enough information to refer to a block – not the block’s data itself. It is expected that every block will either use it’s own internal data representation (a file on disk, other database entry, etc.) or extend one of the pre-built C2MS block types for data storage. A GUID key, block_id, uniquely identifies every single block in the system. Blocks may also specify that they are dependent on other blocks to function (e.g. a slideshow may be dependent on images within that slideshow) by creating reference entries in the cbmBlockDependency table. The c2msfoundation module provides many helpers and model classes to work with blocks. It is HIGHLY recommended that the only access to block tables be via these provided helpers instead of direct DAO calls to the cbmBlock tables.
Some blocks represent “super-views” — blocks designed primarily to place other blocks into sections. To accommodate this C2MS features a BlockView. A BlockView is made up of one or more sections, each of which can contain a block. The C2MS provided “page” block type uses block views to allow users to place content blocks into template sections. The cbmBlockView table allows a block to be placed into a cbmSection by creating a cbmblockviewSection record.
Block views have one other major function – they serve to join content to a URL represented in the table cbmUrl. It is important to use a BlockView to provide access to your content and not go directly to the block in order to allow for more than one view of data without having to duplicate that data. Let’s, for example, take the hypothetical block type “product” and assume we want to display this as a web page. If we wrote a renderer for product (RenderProduct) that displayed the product in a fixed fashion we would have to duplicate the product’s data in order to provide a “condensed” and “full” view of the product. By using BlockViews we create two block views — both pointing at the same block_id — but each specifying a different template (e.g. product-brief, product-full).