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:
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 "Customizing Repository Fields and Metadata" and "Managing Content Profiles" in Oracle Fusion Middleware Managing Oracle WebCenter Content.
Skins and layouts provide alternate color schemes and alternate navigation designs.
Some skins and layouts are provided by default with 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.
Only administrators can make new or custom skins. For more information about setting the default look and feel of the user interface, see Section 5.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.
This personalization functionality works with Internet Explorer 7+ or Mozilla Firefox 3+ and later versions.
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
/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.
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
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
/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.
The ExtranetLook component can be used to change the interface for anonymous, random users. An example of this is when a website 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 website.
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.
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 website by altering the following files in the
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.
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.
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.
Confirm the path to the deployment plan on the Save Deployment Plan Assistant page, or change the path.
In a text editor, add lines at two places in the deployment plan:
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>
<module-descriptor> element of
cs.war file, add two
<variable-assignment> elements that assign the following values to the
original_loginerror_path variables, respectively:
<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
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
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
/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
/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
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.
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.
yuiBundle.js, which contains script provided by the third-party Yahoo User Interface library, and
bundle.js, which contains the rest of the resources.
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.
The bundling has changed since Oracle Universal Content Management 10g, which used a different table and had a
loadOrder value that determined the order of resources in each bundle.
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
Bundling is accomplished by using the
PublishedBundles table in the
std_publishing.htm file, which Example 5-1 shows.
The columns in this table are as follows:
bundlePath: The eventual location where the bundle is published. This path is relative to the
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.
In the previous example, files of the
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
Example 5-2 shows Idoc Script code, within the
HEAD section for a page, to correctly include these files on the page.
This code fragment includes all
PublishedResources ResultSet is sorted by
loadOrder, so files and bundles with the lowest
loadOrder are included first. Files with a greater