This section describes how to modify the Content Server interface:
This section provides information about available skins and layouts provided by default with your Content Server. Skins and layouts provide alternate color schemes and alternate navigation designs.
Several skins and layouts are provided by default with the Content Server. In addition, you can design custom skins and layouts. When users changes the skin or layout, they change the look and feel of the interface. They can select a skin and layout from the options provided on the User Profile page.
Note:Only administrators can create and make new or custom skins. See "Configuration Entries" for additional information on setting the default look and feel of the user interface.
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:
Important:This personalization functionality works with Internet Explorer 6+ or Mozilla Firefox 3+ and later versions.
To change the skin or layout, follow these steps:
On the Content Server Home page, click <your_user_name> in the top menu bar. The User Profile page displays.
On the Content Server User Profile page, select 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:
LmDefaultLayout: The name of the layout used by guests, and new users. The default is Trays, but it can be set to Top Menus.
LmDefaultSkin: The name of the skin used by guests, and new users. The default is Oracle.
The ExtranetLook component can be used to change the interface for users who log in as anonymous random users. An example of this is when a Content Server-based Web site must be available to external customers without a login, but you want employees to be able to contribute content to that Web site.
When running Content Server on an Oracle WebLogic Server, this 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 into the Content Server repository so it can be referenced by the Content Server templates.
The following files in the IntradocDir/data/users directory can be altered:
Use the following procedure to update the look-and-feel of the Web site based on user login:
Display the Web Layout Editor.
Select Options, then Update Portal.
Modify the portal page as you wish. You can use dynamic resource includes based on user login to customize this page.
Customize the ExtranetLook.idoc file as desired.
Check the ExtranetLook content item out of the Content Server.
Check the revised ExtranetLook.idoc file back into the Content Server.
You can modify layouts and skins by altering the template files provided with the Content Server or design new skins and layouts by creating components that can be shared with other users.
This section provides an overview of this process. It includes these topics:
When the 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 then merge a custom row which 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 the 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 used to create it did not have any access to the current service's DataBinder or any information about the current user.
This section describes the general steps needed to create and publish new layouts.
Merge a table into the
LmLayouts table in IdcHomeDir/resources/core/tables/std_resources.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_resources.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
PublishStaticFiles table in std_resources.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 they can be delivered as one, thus minimizing the number of page requests to the server. In addition, you can optimize file use by referencing published pages using Idoc Script.
This section discusses the following topics:
Static weblayout file contents are cached on client machines and on Web proxies, significantly lowering the amount of server bandwidth they use. Therefore, best practice indicates that these types of files should be used 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 this file. This occurs even if the file is cached. Therefore, as the number of these files grows, so does the number of pings to the server for each page request.
To help minimize the number of round-trips, Content Server can bundle multiple published files so they are delivered as one. This feature can be disabled by setting the following configuration in the server's IntradocDir/config/config.cfg file:
The columns in this table are as follows:
class: This refers to the same column in the
PublishedWeblayoutFiles table and is used to determine which files are placed in which bundle.
bundlePath: The eventual location where the bundle is published. This path is relative to the /weblayout directory.
loadOrder: The order in which this bundle should be loaded on Content Server pages. Bundles with a lower loadOrder are loaded first.
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.
class column in the
PublishedWeblayoutBundles tables is a colon-separated classification. In the following example, two different bundles overlap.
food accounts for all three published weblayout files, while
food:fruit accounts for two of the three and
food:vegetable accounts for the third.
Any given weblayout file can only be published into a single bundle, so
food:fruit contains both
food picks up the leftover
CARROT. The server checks each file to be published then looks for the most specific bundle in which to place it. If no bundle exists, it is published as a single file.
<@table PublishedWeblayoutFiles@> <table border=1><caption><strong> <tr> <td>path</td> <td>template</td> <td>class</td> <td>loadOrder</td> <td>doPublishScript</td> </tr> <tr> <td>resources/apple</td> <td>APPLE</td> <td>food:fruit:apple</td> <td>10</td> <td><$doPublish = 1$></td> </tr> <tr> <td>resources/pear</td> <td>PEAR</td> <td>food:fruit:pear</td> <td>20</td> <td><$doPublish = 1$></td> </tr> <tr> <td>resources/carrot</td> <td>CARROT</td> <td>food:vegetable:carrot</td> <td>10</td><td><$doPublish = 1$></td> </tr> </table> <@end@> <@table PublishedWeblayoutBundles@> <table border=1><caption><strong> <tr> <td>class</td> <td>bundlePath</td> <td>loadOrder</td> </tr> <tr> <td>food:fruit</td> <td>resources/fruit</td> <td>20</td> </tr> <tr> <td>food</td> <td>resources/food</td> <td>10</td> </tr> </table> <@end@>
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
This code fragment includes all
PublishedResources result set is sorted by
loadOrder so files and bundles with the lowest
loadOrder are included first. Files with a greater