Thanks Jacopo Cappellato for the original document creation on OFBiz CMS, contents in this document are referred from it.
Basic Concepts: DataResource and Content records
Let's suppose that we want to define content (that we will include in a screen) for the text "This is the text that will appear on screen.".
First of all we have to define a DataResource representing this text. The most common options we have are the following: SHORT_TEXT, ELECTRONIC_TEXT, URL_RESOURCE.
Data Resource of type SHORT_TEXT
This is the simplest version and is useful when you have to store short texts.
Data Resource of type ELECTRONIC_TEXT
This is similar to the SHORT_TEXT version, but gives you greater flexibility because you can store long texts in the textData field.
Embedding FTL markup in the text
The tree above DataResource records works well when the content is a simple text or a markup language (html, xml etc...) that just needs to be rendered as is. If you want to embed FTL markup (directives etc...) that needs to be processed before the rendering you can achieve this using the dataTemplateTypeId attribute:
in this way all the Freemarker instructions in the text will be executed before rendering the screen.
Now we have to create a Content record that is associated to the DataResource. No matter what type of data resource you have choosen, the Content record is the same:
Note that the contentTypeId is "DOCUMENT": all pages and sections of pages should be this type.
The Sub-Content Pattern
This is a pattern used find and render sub-content of a Content record by specifying two things:
contentId - the parent contentId to find sub-content of
mapKey - the value of the mapKey field in the ContentAssoc between the parent- and sub-content to look up by
The ContentAssoc.contentTypeId should be SUB_CONTENT.
There can be multiple ContentAssoc records between the parent- and sub-content because of the fromDate field that is part of the primary key. To find the one we want we follow the standard pattern of sorting by -fromDate (newest first) and make sure the current date is greater than the fromDate and that either the thruDate is null or the current date is less than or equal to the thruDate.
We will see the Sub-Content Pattern in action below in two scenarios:
to decorate the various sections of a screen DECORATOR template (see section "Content and decorator templates")
to provide a clean way to reference content in URL for web content sites (see section "Defining the publish point")
Content and decorator templates
If you want to embed the content of a DataResource in an existing template (to decorate/fill a region of it) you can use the decoratorContentId attribute:
In this decorator we have placed a new placeholder for the header section, using a variable named "header" that is referenced using the syntax
Then we have defined a new DataResource/Content pair to set the content for the header ("This is the text for the decorator header."). The association is done using the ContentAssoc entity (see the last line in the code block): the mapKey attribute is where you set the name of the variable used in the decorator template.
Here are a few hints to consider when you are preparing the content for a decorator template:
you can always get a reference to the Content for the Decorator (and associated resources) using following variable
you can always get a reference to the Content for the decorated (current) screen (and associated resources) using following variable
above code renders the content record associated to the main one with the mapKey "sub1"
when you define a hook for a region, it is usually a good idea to use a syntax like this:
In this way, when the decorated screen is rendered, if a "footer" record is associated to the decorated screen, then it is used that footer before defaulting to the default one (if available) associated to the decorator Content
Using the <content/> element in a screen definition.
You can easily include the content directly inside the <widgets> section of the screen definition with the following directive:
How to setup a content driven website: WebSites, publish points and default pages
Here are some tips to quickly setup a website whose content can be managed using the OFBiz built-in features of the Content management framework.
Make sure that, in the web.xml file you have an entry to set in the session the webSiteId of your site:
Add to the controller.xml file the following (or similar) entries:
With the above setup, by default all the incoming requests will be dispatched to the CmsEvents event; this event will use the data in the Content data model to generate the content of the page and will return it back to the browser. In this way it will be possible to add new pages just editing the data in the Content data model and without editing the controller.xml file.
Defining the web site publish points
Next step is to define at least one publish point for the web site.
A Web Site Publish Point is a special Content record that is not associated to a DataResource and its contentTypeId is WEB_SITE_PUB_PT: this is a Placeholder ContentType that is not meant to be rendered, but rather used to organize other content associated with it.
The Web Site Publish Point Content entry is associated to the WebSite thru the WebSiteContent entity, using a webSiteContentTypeId equal to "PUBLISH_POINT".
Here is an example of this data setup:
Adding a new page
Defining a new content driven page is as simple as defining a new Content/DataResource pair (as described in the above sections) of type DOCUMENT and then associating it to one of the web site publish points; the association, done thru the ContentAssoc entity (of type SUB_CONTENT) can be direct or indirect (i.e. the content record is a child of one of descendants of the publish point). For some examples of this setup see the section "URI formats to access Content information" below.
Defining the default page
This is an optional step. You can define a default content driven page for the web site, that is used when no page (content) is specified in the URI. The Content/DataResource pair for the page is the same of a standard page (the content page needs also to be associated, directly or indirectly, to a publish point) and the association to the WebSite as the default page is done with an entry like the following one:
The page defined by the EXAMPLE_CONTENT content will be used as the default page for the web site.
URI format to access Content information
According to the way the CMS site has been setup, you will be able to use the following URI format to visit the Content managed screens.
In the following examples we will adopt these values:
<BASE URL>: This is the base url of the application; we will assume "https://localhost:8443/cmssite"
<CMS>: This is the entry point for all the CMS managed content (as defined in the controller.xml file); we will assume "cms"
<CONTENT ID OF THE SCREEN>: This is the contentId of a content record of type DOCUMENT that is associated to a DataResource containing the information to be rendered to the browser; we will assume the value EXAMPLE_CONTENT
<BASE URL>/<CMS>/<CONTENT ID OF THE SCREEN>
This will only work if the Content record with id EXAMPLE_CONTENT is a node of a tree having a web site publish point as its root. The EXAMPLE_CONTENT content can be directly associated to the publish point: