This chapter contains the following:
This section contains the following:
A community template is comprised of a set of services (channels) and the visual layout. However, the layout is not always dictated by the community template as in the case with wiki community template where the layout is dictated by the wiki itself. Community templates define (in the role display profile document) the type of services available for the community, the default settings for each service, and the containers that bind the services.
Physically, a community template is a properties file, and image, plus one or more display profile documents. There are display profile documents, one per community role (such as OWNER, VISITOR, MEMBER). Each role template defines services and the layout associated with the particular role (see Managing Membership for more information on these roles). The content of the role template is represented in a display profile document. In essence, a community template contains the logic for handling different roles (one display profile document per role) and depending on the one or more roles, you get a different set of services and a different layout. There are also display profile documents to customize the content when communities are marked for deletion (deleted.xml) or disabled (disable.xml).
Communities are created from a community template. The system may have any number of community templates. In the Enterprise Sample, end users choose a community template when they create a community.
The community templates are stored on filesystem. Community templates are stored in PortalServer-DataDir/portals/portal-URI/communitytemplates directory (referred to as communityTemplateBaseDir). Note that this means that each Portal (in a multi-portal deployment environment) will and must have its own set of community templates. The resource bundle in communityTemplateBaseDir defines the meta data associated with each template. In addition, each template has its own directory where the role templates are stored.
communityTemplateBaseDir -+-- template1 -+-- deleted.xml | | | +-- disabled.xml | | | +-- member.xml | | | +-- owner.xml | | | +-- visitor.xml | -+-- template2 -+-- deleted.xml | | | +-- disabled.xml | | | +-- member.xml | | | +-- owner.xml | | | +-- visitor.xml | -+-- template3 -+-- deleted.xml | | | +-- disabled.xml | | | +-- member.xml | | | +-- owner.xml | | | +-- visitor.xml | +-- template1.properties | +-- template1_en.properties | +-- template1_fr.properties | +-- template2.properties | +-- template3.properties | +-- template3_en_US.properties | +-- ...
The display profile disabled.xml and deleted.xml files control the content when the community is disabled or marked for deletion. See Managing a community status for more information.
The portal administrator can add a new community template, update an existing community template, archive and restore community templates on the system, and export community templates from one portal instance to others and/or keep them in sync.
Each template is made up of one or more role templates (member.xml, owner.xml, visitor.xml, deleted.xml, disabled.xml) in XML format. The template directory includes the XML files for the roles that it will serve; for example, member.xml for the community member, owner.xml for the community owner, and visitor.xml for the community visitor.
Each role template is a display profile document for community users in that role. The file must be based on the display profile DTD.
<?xml version="1.0" encoding="utf-8" standalone="no"?> <!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd"> <DisplayProfile version="1.0" priority="%COMMUNITY_DP_PRIORITY%"> <Properties/> <Channels> <Container name="%COMMUNITY_CONTAINER%" provider="JSPTableContainerProvider"> <Properties> <String name="title" value="%COMMUNITY_NAME%"/> <String name="description" value="%COMMUNITY_DESCRIPTION%"/> <Boolean name="compileToRealPath" value="true"/> </Properties> <Available>...</Available> <Selected>...</Selected> <Channels>...</Channels> </channels> <Providers/> </DisplayProfile>
The tokens (surrounded by %), described below, in the display profile are dynamically replaced by actual values by the template engine when a community is created.
Specifies the (user-friendly) name given to the community. For example, tourists.
Specifies the unique string identifying the community. This name is strictly an internal representation and does not get exposed in the user interface. For example, jdo__tourists.
Includes a description of the community.
Specifies the top-level container for the community. For example, jdo__touristsContainer.
Specifies the display profile merging priority given to the resulting community display profile. Each role is given a different value. By default, 1000 for the visitor role, 1005 for the member role, and 1010 for the owner role.
Specifies the Search server URL for the community.
Specifies the search database for the community content.
Specifies the discussions database.
Specifies the ID of the portal. For example, portal1.
Each template includes a resource bundle properties file which defines the meta-data associated with that template. The resource bundle is referred to as the descriptor file that can be localized. Each template descriptor file (must) define the following properties:
Specifies an unique ID of the template. The ID must match the template directory name. For example, Baseball for a template directory named Baseball with role templates (or XML files) for all three supported roles.
Specifies an user-friendly name used in the user interface (portal desktop) to identify the template. For example, Baseball Template.
Contains a verbose description of the template including the services it offers. For example, Baseball-themed template containing the following services: Player Statistics, Game Discussions, TV Schedule, and Online Chat.
Includes the list of tokens used in the template role files. This merely serves an informative purpose and is not required. For example, %COMUNITY_ID% %COMMUNITY_DESCRIPTION% %COMMUNITY_CONTAINER%.
Specifies either the absolute or relative URI to the portal context. For example, http://images.domain.com/images/baseball.jpg. The relative URI must be relative to the portal web-app context path.
id=Baseball name=Baseball Template description=Baseball-themed template containing the following services: Player Statistics, Game Discussions, TV Schedule, and Online Chat tokens=%COMUNITY_ID% %COMMUNITY_DESCRIPTION% %COMMUNITY_CONTAINER% previewImageURI=http://images.domain.com/images/baseball.jpg |
To create a new or modify an existing template, following the instructions in this section. You can create a template in one of the following three ways:
Export the template, add content, and import the content using the psadmin utility.
Create content and import the content to overwrite existing template.
Add new files to existing templates.
Go to the communityTemplateBaseDir.
Create a:
New directory for the new template
Copy an existing template to the new template directory
For example, type:
cd PortalServer-DataDir/portals/portal-URI/communitytemplates mkdir NewTemplate cp 2column/* NewTemplate/ |
Modify the role based display profile documents in the new template directory as needed.
For more information on the role based display profile documents, see Template Syntax and Semantics.
Create and edit the properties file to include the properties described in Template Descriptor File and save the file.
For example, to create a new properties files for the new template, type:
cp 2colimn.properties NewTemplate.properties |
Or,
touch NewTemplate.properties |
In order to see the newly added template, log out of any current portal session and re-login to see the change.
Go to the communityTemplateBaseDir/template directory and open the file you wish to modify.
Log out of any current portal session and re-login to see the change.
In a muti-portal environment (when there are more than one portal on the system), use PAR mechanism (as opposed to directly editing files in communityTemplateBaseDir) so that the change of community templates can be applied across multiple portals. This will allow all the portals to have the same set of community templates. If you do not wish to have synchronized environment across portals, use the instructions outlined in To Create a New Template for Single Portal Environment.
Either use psadmin export --type desktop to export desktop data (which includes community templates) and then export it so the content can be edited or, create a new PAR structure from scratch with only the community templates and no other desktop data.
Follow instructions in To Create a New Template for Single Portal Environment to edit content.
Create a new PAR file which contains:
-+-- META-INF -- MANIFEST.MF | +-- pbfiles -+-- communityTemplateBaseDir -+-- template1 -+-- deleted.xml | | | | | +-- disabled.xml | | | | | +-- member.xml | | | | | +-- owner.xml | | | | | +-- visitor.xml | | | +-- template1.properties | | | +-- template1_en.properties | | | +-- template1_fr.properties | | | +-- ... | +-- static -- community -- images -- template1.gif
Edit or add content as needed.
Create a new PAR file.
Use psadmin import subcommand to import the PAR content across all portals.
If you exported all desktop data, note that psadmin export subcommand will export all desktop data; if you create a new PAR structure from scratch with only the community templates, the command will only export community templates.
For more information, see the psadmin export in Sun Java System Portal Server 7.2 Command-Line Reference.