This change affects the portal-commons library which facilitates the creation of content portals that retrieve their content from betacms. The portal-commons library allows the creation of URIs (RESTful portal api) ) that retrieve resources from a betacms repository and generate web pages to present the resources. Either the URIs (as part of the URI parameters) or the resources themselves may refer to page templates (Facelets XHTML code) which are utilized by the portal-commons library in order to generate the web pages.

Currently Portal Page Templates (Facelets XHTML code) are stored in files that reside inside the Application Server within the Portal war structure. For example if a portal URI that requests a collection of content objects specifies as a template parameter the template named 'blogEntryTemplate' then the portal common library tries to find inside the root directory of the portal war a file named 'blogEntryTemplate.xhtml' and uses it to render a web page that presents the requested collection of objects.

While the current approach offers a lot of flexibility for a developer to design and test her templates it makes quite difficult for ordinary users to apply simple changes to templates since it requires to have read / write access to the server and continuously sync their local changes to the server.

This approach will be enhanced to permit facelet xhtml code (page templates, page layouts and page components) to be stored inside betacms and executed from there.

The enhancement assumes that there is already available the appropriate content object type for storing page template code inside betacms. A special content object type named 'resourceRepresentationTemplateObject' has been created for this purpose and is provided out of the box as part of the default internal repository schemas. Check issue BCMS-83 for this enhancement.

Additionally special properties for defining representation templates for content objects have been defined as part of the core modeling element 'contentObjectType' and thus are inherited by each defined content object type. For this enhancement see jira issues: BCMS-74 and BCMS-84

Assuming the above enhancements this issue refers to the enhancement of 'AbstractContentObjectResource' class in portal-commons library. The 'provideResource()' and 'provideResources()' methods in this class should be enhanced to take into account the existence of templates inside betacms repository.

The algorithm for providing a singe resource (requested by id or system name) should be the following:
-------------------------
Check if user has specified a template in Resource URI
 if YES
    check if the page template exists as a 'resourceRepresentationTemplateObject' stored in betacms repository.
    The object should have a systemName that equals to the provided template name
    If we find the object and the "xhtml" property is filled
          then we outject the systemName so that the 'dynamicPage.xhtml' can use it to retrieve the page template content.
          The 'dymanicPage.xhtml' page will be a special facelets page that utilizes the BetaCMS Resource API to get and run the template from betacms
   else
          check if page template exists as an xhtml file stored in root directory of web application

if NO template specified in URI
    check if the content object has a value stored in "resourceRepresentationTemplateObjectReference" property and outject the systemName so that the 'dynamicPage.xhtml' can use it to retrieve the page template content

if NO value stored in "resourceRepresentationTemplateObjectReference" property
    check if the content object has a value stored in "resourceRepresentationTemplateName" property and if the value corresponds to a template stored in the the root directory of portal war and return the filename as the view id

if NO value stored in "resourceRepresentationTemplateName" property
    check if a template named after the contentObjectType exists in repository. The convention is that the system name of the template should be equal to contentObjectType suffixed with "Template"
    e.g. "portalSectionObjectTemplate" for content objects of type "portalSectionObject"

if the above did not succed
   check if a template named after the contentObjectType exists in web app root folder. The convention is that the file name of the template should be equal to contentObjectType suffixed with "Template.xhtml"
   e.g. "portalSectionObjectTemplate.xhtml" for content objects of type "portalSectionObject"

if the above also did not succed
    use the default page template for all content objects with name "contentObjectTemplate"
    check if the default template exists in repository
    or alternatively check if default page template for all content objects exists as an xhtml file stored in root directory of web application

if none of the above succeded the return page not found
----------------

The algorithm for providing a collection of resources should be:
---------------
check if the page template has been provided in request URI parameters
If YES
   set as working template the requested template
if NO
   set as working template the default template for resource collections which is 'contentObjectListTemplate'

Then check if the working template exists as a 'resourceRepresentationTemplateObject' stored in betacms repository and forward navigation appropriately
Alternatively check if working template exists as an xhtml file stored in root directory of web application and forward navigation appropriately

if none of the above succeeded return page not found
--------------------

IMPORTANT NOTICE:
Existing page template files that correspond to the templates for rendering specific content types should be renamed from 'contentType.xhtml' to 'contentTypeTemplate.xhtml', e.g. 'portalSectionObject.xhtml' should be renamed to 'portalSectionObjectTemplate.xhtml'