Understanding PeopleTools Branding
This topic provides an overview of PeopleTools branding features.
PeopleTools provides branding features that are powerful and flexible, allowing you to manage the look and feel of any PeopleSoft application. With PeopleTools, many common branding tasks, including managing definitions and objects associated with the overall site style are performed online. In addition, other tasks such as maintaining style sheets, images, and other objects can be performed either online or by using Application Designer.
With PeopleTools branding, you can apply branding definitions to:
The entire system.
Individual portals.
Users by role or permission list.
Individual classic components.
Fluid components by node.
The key branding definition is the theme, which can be applied system wide, to specific portals, and by specific user attribute. A theme definition includes:
Homepage header, footer (optional), and target page header (optional).
Note: These header and footer definitions apply to classic homepages and classic pages only.
Theme macro set (optional).
Default theme style sheet for classic components (optional) if necessary to override the style sheet of the theme family.
List of additional skins for classic components (optional).
Mapped theme style sheets for fluid components by node (optional).
Global theme style sheet for fluid components if necessary to override the style sheet of the theme family (optional).
At the system level, branding settings include:
Selection of the default theme family (which includes the default theme and compatible default style sheet for classic components)
Selection of a navigation collection for custom homepage tabs (optional).
Additional style sheets and JavaScript objects for all classic components (optional).
A default style sheet for all fluid components (optional).
The branding framework application package and class.
At the portal registry level, additional settings can be specified, some of which override the system settings:
Default theme.
Default skin style sheet (optional).
Default custom tabs collection (optional).
Default custom homepage tab (optional).
Default fluid homepage (optional).
At the user attribute level, additional settings can be specified, some of which override the system settings and the portal registry settings:
Theme.
Skin style sheet (optional).
Custom tabs collection (optional).
Default custom homepage tab (optional).
Default fluid homepage (optional).
In addition to these system, portal, and user attribute settings, different branding can be applied to individual classic components. In Application Designer, the component’s developer can specify style sheets and JavaScript objects as component properties. Through the browser, the portal administrator can specify additional custom style sheets and JavaScript objects as component properties. (These capabilities are in addition to existing features in Application Designer that allow the component’s developer to apply a style sheet to each page definition, and to apply style classes to fields and field labels.)
PeopleTools allows you to maintain the following definitions used with branding:
Branding system options for system-wide settings.
Branding objects: HTML, JavaScript, style sheets, and images. (Definitions for these branding object types can also be created and maintained in Application Designer.)
Pagelet branding, which allows you to modify display attributes of individual pagelets.
Component branding, which allows you to add custom style sheets and JavaScript objects to individual classic components. These custom objects are in addition to any objects specified by the component’s developer in Application Designer.
Macro sets and macros that define the values for customizable branding elements such as colors, images, and so on.
Header and footer definitions for classic pages, which are incorporated in theme definitions.
Theme definitions, which include headers, a footer, and theme style sheets for classic and fluid components.
Theme assignments, which allow you to specify themes and other options at the portal level and by user attribute.
Branding system element types, which allow you to define the elements that can be used to construct header and footer definitions for classic pages.
Branding user attribute types, which allow you to define the user attributes that can be used for theme assignments.
Navigation collections designed for use as custom homepage tabs.
Levels at Which Style Sheets Can Be Applied
Style sheets are associated with different definitions throughout the system. Certain definitions require a style sheet, whereas one or more style sheets are optional for others. Moreover, different style sheet types are allowed with different definitions.
The following table summarizes the locations where style sheets can be attached for classic components:
|
Level |
# |
Comments |
|---|---|---|
|
System default |
1 |
Standard or free form. Practically speaking, the system default style sheet should be a standard style sheet that is compatible with the selected theme family. The system style sheet should be comprehensive and define both layout and style aspects of all user interface elements. Typically, you would select one of the three delivered layout style sheets:
|
|
Additional system style sheets |
0 – n |
Standard or free form. |
|
Component |
0 – n |
Standard or free form. Component-level style sheets can be added by the component’s developer, by the portal administrator, or both. |
|
Page |
0 or 1 |
Standard or free form. Page-level style sheets can be specified by the component’s developer only. |
|
Theme |
0 or 1 |
Free form only. |
|
Skin |
0 – n |
Free form only. While multiple skins can be associated with a theme definition, only one skin (or no skins) can be in effect per assignment (portal or user attribute). |
The following table summarizes the locations where style sheets can be attached for fluid components:
|
Level |
# |
Comments |
|---|---|---|
|
System default* |
0 or 1 |
Standard or free form. If no style sheet is defined at the system level, PSSTYLEDEF_FMODE is used by default. |
|
Component* or page* |
0 – n |
Standard or free form. Component-level and page-level style sheets can be added by the component’s developer through PeopleCode. |
|
Theme (global override) |
0 or 1 |
Standard or free form. |
* Theme definitions include the optional capability to associate mapped theme style sheets to base style sheets on a per node basis. You can create 0 – n mappings. If a base style sheet with a mapped theme style sheet is specified, then the mapped theme style sheet will be loaded directly beneath the base style sheet where the base style sheet is used.
Loading Sequence
At run time, the generated HTML includes style sheets and JavaScript objects in a specified sequence. Style sheets (or more specifically, the specific style classes defined in those style sheets) override any style class definitions of the same name loaded earlier in the sequence. Therefore, you can use theme and skin style sheets to overlay your branding look on top of styles defined at the system or component level.
Classic Components
For classic components, style sheets and JavaScript objects are loaded in the following order:
PSSTYLEDEF_REQ (automatically loaded by default for all classic components).*
System default style sheet.*
Additional system-level style sheets in the order defined.
Additional system-level JavaScript objects in the order defined.
Component-level style sheets in the component developer list in the order defined.
Component-level style sheets in the portal administrator list in the order defined.
Component-level JavaScript objects in the developer list in the order defined.
Component-level JavaScript objects in the portal administrator list in the order defined.
Page-level style sheet.
Theme style sheet.
Skin style sheet.
* A required style sheet that is always loaded. All other style sheets are optional.
Fluid Components
For fluid components, style sheets and JavaScript objects are loaded in the following order:
System default style sheet* (and its mapped theme style sheet if specified).
Component-level or page-level style sheets (and their mapped theme style sheets if specified) added by the component developer through PeopleCode.
Component-level JavaScript objects added by the component developer through PeopleCode.
Theme-level global override style sheet.
* A required style sheet that is always loaded. All other style sheets are optional.
Branding tasks require certain PeopleTools roles. The following list indicates which role provides access to which branding pages or additional branding features:
Portal Administrator – Provides access to all of the menu items (pages) under the menu folder.
Portal Manager – Provides access to all of the menu items (pages) under the menu folder except for those under the Theme Macro Set menu item.
-
Secure Branding Administrator – Provides access to the Branding Objects pages and the Define Headers and Footers page. In order to use these pages, this role is required in addition to either Portal Administrator or Portal Manager.
-
Company Info Administrator – Provides access to add and configure the CompanyInfo element, which can be added to a header definition on the Define Headers and Footers page. In order to add and configure the CompanyInfo element, this role is required in addition to Secure Branding Administrator and either Portal Administrator or Portal Manager. See Configuring a Custom Banner for more information.
-
PeopleTools SVG Administrator – Grants permission to upload SVG images via the rich text editor.
Use the following process when developing and applying your own branding:
Determine your branding requirements in collaboration with your marketing organization and your portal branding administrator.
Create new objects (images, style sheets, HTML objects, and JavaScript) as required to fulfill the branding requirements.
See Understanding Branding Objects for more information.
(Optional) Create any new branding element type definitions to support your requirements.
See for Creating a New Branding Element more information.
(Optional) Create and customize a macro set.
Create new header and footer definitions (for classic homepages and classic pages only) combining delivered and new branding elements. Typically, it is easier to clone an existing definition and modify it to suit your needs.
See Defining Headers and Footers for more information.
Create a branding theme definition using your new macro, header, footer, and theme style sheet definitions.
See Assembling Branding Themes for more information.
(Optional) Generate mapped theme style sheets for fluid components.
See Generating Theme Style Sheets for Fluid Components for more information.
(Optional) Create a navigation collection for custom homepage tabs.
See Creating and Maintaining Navigation Collections for Custom Homepage Tabs for more information.
Specify branding system-wide settings.
See Configuring Branding System Options for more information.
(Optional) Create any new user attribute type definitions to support your requirements.
See Creating a New User Attribute Type for more information.
(Optional) Make any portal- or user attribute-specific theme and branding assignments.
See Assigning Branding Themes for more information.
(Optional) Apply any component-specific branding to classic components.
See Branding Classic Components for more information.
(Optional) Apply an pagelet-specific branding to pagelets.
See Maintaining Pagelet Branding Attributes for more information.