This chapter provides information about the several different methods that you can use to customize the look and feel of the Oracle WebCenter Content Server interface. You can use skins and layouts to change the appearance of the user interface and dynamic server pages to change the navigation.
This chapter includes the following sections:
Tip:
In addition to using the methods discussed in this chapter, you can alter the metadata fields that are presented to users and modify the types of presentations used for check-in pages, search pages, and other user interfaces. For information about creating and modifying metadata fields and creating content profiles, see "Managing Repository Content" in the Oracle WebCenter Content Application Administrator's Guide for Content Server.Skins and layouts provide alternate color schemes and alternate navigation designs.
Some skins and layouts are provided by default with Oracle WebCenter Content Server. In addition, you can design custom skins and layouts. When you change the skin or layout, you change the look and feel of the interface. You can select a skin and layout from the options provided on the User Profile page.
The only skills required to create and modify skins or layouts is an understanding of HTML, Cascading Style Sheets, and JavaScript. After altering the appearance, the edited layouts and skins are published so that others in your environment can use them.
Note:
Only administrators can make new or custom skins. For more information about setting the default look and feel of the user interface, see Section 3.3, "Configuring a Default Skin and Layout for New Users and Guests."Skins define the color scheme and other aspects of appearance of the layout such as graphics, fonts, or font size. (the default skin is Oracle). You can design custom skins or modify the existing skins.
Layouts define the navigation hierarchy display (the default layout is Trays) and custom layouts can be designed. Custom layouts change behavior and the look-and-feel systemwide. If you want your changes to apply only in limited situations, you might want to consider dynamic server pages.These layouts are provided:
You can choose a different skin to provide an alternate color scheme or a different layout to provide an alternate navigation design, or both.
The User Personalization settings available on the User Profile page enable users to change the layout of Content Server or the skin.
Important:
This personalization functionality works with Internet Explorer 7+ or Mozilla Firefox 3+ and later versions.To choose a different skin or layout:
On the Content Server Home page, click your_user_name in the top menu bar.
The User Profile page appears.
Choose the desired skin and layout.
Click Update, and view the changes.
These values can be placed in the IntradocDir/config/config.cfg file to alter the default behavior for the Content Server instance:
LmDefaultSkin: The name of the skin used by guests, and new users. The default is Oracle.
LmDefaultLayout: The name of the layout used by guests, and new users. The default is Trays, but it can be set to Top Menus.
The Top Menus and Trays layouts are included by default with the system. The two layouts have two skin options (Oracle and Oracle2). The layouts are written in JavaScript, and the look of the skins is created using Cascading Style Sheets.
You can modify skins and layouts by altering the template files provided with Content Server or design new skins and layouts by creating components that can be shared with other users.
When Content Server starts, or when the PUBLISH_WEBLAYOUT_FILES service is run, the PublishedWeblayoutFiles table in the std_resource.htm file is used to publish files to the weblayout directory. To have your custom component use this publishing mechanism, create a template, and then merge a custom row that uses that template into the PublishedWeblayoutFiles table.
Other users who want to modify or customize your file can override your template or your row in the PublishedWeblayoutFiles table. If your template uses any resource includes, other users can override any of these includes or insert their own Idoc Script code using the standard super notation. When your component is disabled, the file is no longer published or modified and Content Server returns to its default state.
In addition to giving others an easy way to modify and add to your work, you can also construct these former static files using Idoc Script. For example, you can have the files change depending on the value of a custom configuration flag. You can use core Content Server objects and functionality by writing custom Idoc Script functions and referencing them from inside your template.
Because this Idoc Script is evaluated once during publishing, you cannot use Idoc Script as you would normally do from the IdcHomeDir/resources/core/idoc/std_page.idoc file. When a user requests that file, it has already been created, so the script that was used to create it did not have any access to the current service's DataBinder object or to any information about the current user.
This does limit the type of Idoc Script you can write in these files. If you are writing CSS or JavaScript that needs information that dynamically changes with users or services, consider having the pages that need this code include the code inline. This increases the size of pages delivered by your web server and so increases the amount of bandwidth used.
The ExtranetLook component can be used to change the interface for anonymous, random users. An example of this is when a web site based on Content Server must be available to external customers without a login, but you want employees to be able to contribute content to that web site.
When Content Server is running on Oracle WebLogic Server, the ExtranetLook component alters privileges for certain pages so that they require write privilege to access. The component also makes small alterations to the static portal page to remove links that anonymous, random users should not see.
Note:
The ExtranetLook component does not provide form-based authentication for Oracle WebLogic Server or provide customizable error pages.The ExtranetLook component is installed (disabled) with Content Server. To use the component, you must enable it with the Component Manager.
You can customize your web pages to make it easy for customers to search for content, and then give employees a login that permits them to see the interface on login. To do the customization, modify the ExtranetLook.idoc file, which provides dynamic resource includes that can be customized based on user login. The IDOC file is checked in to the Content Server repository so it can be referenced by the Content Server templates.
You can update the look and feel of the anonymous user interface for the Content Server web site by altering the following files in the IntradocDir/data/users directory:
prompt_login.htm
access_denied.htm
report_error.htm
To alter the anonymous user interface:
Display the Web Layout Editor.
From the Options menu, choose Update Portal.
Modify the portal page as you want to. You can use dynamic resource includes to customize this page.
Click OK.
Customize the ExtranetLook.idoc file as you want to.
Check out the ExtranetLook content item from Content Server.
Check in the revised ExtranetLook.idoc file to Content Server.
You can change the URL of the Login page for Content Server by changing its context root, which is normally /cs/. You cannot change the URL by setting a relative context root with the HttpRelativeWebRoot property because the value of this property does not apply to the Login page. If you need to change the web location where users log in, you can redeploy the WebCenter Content application with a deployment plan.
To change the URL of the Login page:
Log in to the Oracle WebLogic Server Administration Console as the administrator of the domain where WebCenter Content is deployed.
Click Deployments under the name of your domain, in the Domain Structure area on the left.Click Oracle WebCenter Content - Content Server in the Deployments table on the Control tab of the Summary of Deployments page.
This application may be on the second or third page of the table.
Note the path to the deployment plan.
If no plan is specified for your WebCenter Content instance, you can create one:
Click Configuration on the Settings for Oracle WebCenter Content - Content Server page.
Change the value of any parameter on the Configuration tab.
Click Save.
Confirm the path to the deployment plan on the Save Deployment Plan Assistant page, or change the path.
Click OK.
In a text editor, add lines at two places in the deployment plan:
Add the original_loginpage_path and original_loginerror_path variables, each in a <variable> element of a <variable-definition> element, as in this example:
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan
http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
<application-name>ServletPlugin</application-name>
<variable-definition>
<variable>
<name>original_loginpage_path</name>
<value>/content/login/login.htm</value>
</variable>
<variable>
<name>original_loginerror_path</name>
<value>/content/login/error.htm</value>
</variable>
<variable>
<name>SessionDescriptor_timeoutSecs_12996472139160</name>
<value>3600</value>
</variable>
In the <module-descriptor> element of web.xmlin the cs.war file, add two <variable-assignment> elements that assign the following values to the original_loginpage_path and original_loginerror_path variables, respectively:
/web-app/login-config/form-login-config/form-login-page
/web-app/login-config/form-login-config/form-error-page
For example:
<module-override>
<module-name>cs.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
</module-descriptor>
<module-descriptor external="false">
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
<variable-assignment>
<name>original_loginpage_path</name>
<xpath>/web-app/login-config/form-login-config/form-login-page</xpath>
</variable-assignment>
<variable-assignment>
<name>original_loginerror_path</name>
<xpath>/web-app/login-config/form-login-config/form-error-page</xpath>
</variable-assignment>
</module-descriptor>
</module-override>
<module-override>
Stop the WebCenter Content Managed Server (UCM_server1 by default), with the stopManagedWebLogic script.
UNIX script:
DomainHome/bin/stopManagedWebLogic.sh UCM_server1
Windows script:
DomainHome\bin\stopManagedWebLogic.cmd UCM_server1
In the Administration Console, click Deployments under the name of your domain.
Select Oracle WebCenter Content - Content Server in the Deployments table, and click Update.
Select Redeploy this application using the following deployment files, make sure the path to the deployment plan is correct, and then click Finish.
After the redeployment completes successfully, click Apply Changes.
Start the WebCenter Content Managed Server with the startManagedWebLogic script.
UNIX script:
DomainHome/bin/startManagedWebLogic.sh UCM_server1
Windows script:
DomainHome\bin\startManagedWebLogic.cmd UCM_server1
In the Administration Console, click Deployments.
Select Oracle WebCenter Content - Content Server in the Deployments table, and from the Start menu, choose Servicing all requests.
After the WebCenter Content application is launched, verify that the URL of the login page has changed.
The following general steps are necessary to create and publish new layouts:
Merge a table into the LmLayouts table in IdcHomeDir/resources/core/tables/std_publishing.htm to define the new layout. Define the layout ID, label, and whether it is enabled (set to 1) or not.
Merge a table into the PublishedWeblayoutFiles table in IdcHomeDir/resources/core/tables/std_publishing.htm. This new table describes the files that are created from Content Server templates and then pushed out to the weblayout directory. Specify the necessary skin.css files to push out to each skin directory.
Merge a table with the PublishedStaticFiles table in std_publishing.htm. This lists the directories that contain files, such as images, that should be published to the weblayout directory.
You can direct Content Server to bundle published files so that they can be delivered as one, minimizing the number of page requests to the server. In addition, you can optimize file use by referencing published pages using Idoc Script.
Multiple resources may be packaged together into units called bundles. A bundle is a single file containing one or more published resources. Only JavaScript and css resources should be bundled and only with other resources of the same type. Bundling helps reduce the client overhead when pages are loaded but increases client parse, compile, and execute overhead. Generally, it is recommended to bundle resources that have some thematic similarity or are expected to be included at similar times. For example, if you know that resources A, B, and C are needed on every page, and resources D, E, and F are needed rarely but are all needed together, it is recommended to bundle A, B, and C together and to put D, E, and F into a separate bundle.
Almost all JavaScript resources for the Content Server core are bundled into one of two bundles: yuiBundle.js, which contains script provided by the third-party Yahoo User Interface library, and bundle.js, which contains the rest of the resources.
The PublishedBundles table is used for determining how resources are bundled. Essentially a bundle is identified by its target bundlePath, which is the path name to the bundle (relative to the weblayout directory), and a list of rules detailing which resource classes are included or excluded. A loadOrder value in this table applies only to the order in which the filtering rules are applied, not the order in which the resources appear in the bundle.
Note:
The bundling has changed since Oracle Universal Content Management 10g, which used a different table and had aloadOrder value that determined the order of resources in each bundle.Static weblayout file contents are cached on client machines and on web proxies, significantly lowering the amount of server bandwidth they use. Therefore, the best practice is to use these types of files wherever possible.
However, each static weblayout file requested by the client's browser requires a round-trip to the server just to verify that the client has the most up-to-date version of the file. This occurs even if the file is cached. As the number of these files grows, so does the number of downloads from the server for each page request.
To help minimize the number of round-trips, Content Server can bundle multiple published files so that they are delivered as one. You can disable this feature by setting the following configuration in the server's IntradocDir/config/config.cfg file:
BundlePublishedWeblayoutFiles=false
Bundling is accomplished by using the PublishedBundles table in the
std_publishing.htm file, which Example 3-1 shows.
Example 3-1 PublishedBundles Table in std_publishing.htm File
<@table PublishedBundles@>
<table border=1><caption><strong>
<tr>
<td>bundlePath</td>
<td>includeClass</td>
<td>excludeClass</td>
<td>loadOrder</td>
</tr>
<tr>
<td>resources/bundle.js</td>
<td>javascript:common</td>
<td></td>
<td>128</td>
</tr>
. . .
</table>
<@end@>
The columns in this table are as follows:
bundlePath: The eventual location where the bundle is published. This path is relative to the weblayout directory.
includeClass: This is used to determine which resources to include in a bundle.
excludeClass: This is used to determine which resources to exclude from a bundle.
loadOrder: The order in which the includeClass and excludeClass filters are applied.
In the previous example, files of the javascript:common class are published to a single bundle located at resources/layouts/commonBundle.js. The contents of all bundled files that match this class are appended to form a single file to be stored at that location.
Most published files (both bundled and unbundled) must be directly referenced from within HTML to be included in a page. It can therefore be difficult to know exactly which files to include for a given situation, especially when bundling can be enabled or disabled by server administrators. A simple Idoc Script method can be used to easily and transparently include all of the files you need on a given page.
For example, if you write a page that includes all files associated with the javascript:common bundle (as described previously), then do not write HTML that includes all of the files mentioned in the first table in addition to the bundle mentioned in the second, the server is asked for each file. This negates the purpose of bundling because the server is pinged for each file whether it actually exists or not.
Example 3-2 shows Idoc Script code, within the HEAD section for a page, to correctly include these files on the page.
Example 3-2 Idoc Script to Reference a Bundle of Files
<$exec createPublishedResourcesList("javascript:common")$>
<$loop PublishedResources$>
<script language="JavaScript" src="<$HttpWebRoot$><$PublishedResources.path$>" />
</script>
<$endloop$>
This code fragment includes all javascript:common files even if bundling is switched off. If javascript instead of javascript:common is passed, all files whose class starts with javascript are included.
This PublishedResources result set is sorted by loadOrder, so files and bundles with the lowest loadOrder are included first. Files with a greater loadOrder can override JavaScript methods or CSS styles that were declared earlier.