Starting with his post PeopleTools 8.55.x - Branding - Part I - What has changed, Sasank Vemana provides a series of articles describing how to brand Fluid. If your organization supports multiple branding themes, then the PeopleTools delivered branding module and branding macros concept described by Sasank are a perfect fit. Although a fair amount of effort to configure, I didn't mind the macro concept provided in PeopleTools 8.55. But when PeopleTools delivered 8.56 with a brand new macro set and guidance suggesting we either start over with the new macro set or update ours with their new macros (which included evaluating all of our other macro changes), I folded. The scale had tipped. I realized that branding macros were not a "once and done" proposition. It was clear that maintaining branding macros would be more time consuming than injecting a little CSS into Oracle delivered stylesheets. I have this rule: If a configuration alternative exists, but that configuration alternative requires significantly more ongoing maintenance effort than customizing, I will choose the customization. Why? the point of configuration is to simplify Lifecycle Management. If the configuration alternative is more effort, complicating Lifecycle Management, then it is not a good alternative. It is counterproductive. PeopleTools includes very good compare tools for managed definition customizations. It is these great compare tools that sometimes make customizations simpler to maintain than configuration alternatives. This is not the case (yet -- I say "yet" because I believe this will change in the future) for configuration options that may become invalid (or broken) during an update/upgrade/selective adoption.
If your organization has just one global branding theme, you may find this approach much simpler. This is the approach I used with PeopleTools prior to the attribute-based branding module:
- Open a Fluid homepage.
- Using your browser's developer tools, mock up the changes desired.
- Be sure to make your selector more qualified than Oracle's. I suggest including the ID of a higher level element, but do NOT use an ID that starts with win0div as these IDs change with every New Window launched from the base PeopleSoft window.
- Copy these changes into a new PeopleSoft free-form sub stylesheet.
- Add this new stylesheet to PSSTYLEDEF_FMODE.
- Test.
- Visit a Fluid transaction page to identify further changes required to finalize the Fluid branding theme.
Here is some sample CSS to get you started:
How does this work? Unlike the branding module, which replaces and/or changes Oracle-delivered CSS, we allow Oracle's CSS to be sent to web browsers unchanged. Just as before the customization, a user's web browser will parse Oracle's CSS, building a list of rules. But when the browser reads our rules injected at the very end, the browser will ignore Oracle's rules because ours will be both more specific and interpreted last.
What about Classic and Classic Plus? Same principle, just a different stylesheet. Classic uses PSSTYLEDEF_TANGERINE and DEFAULT_THEME_FLUID. I prefer PSSTYLEDEF_TANGERINE because it is a structured stylesheet, allowing us to inject one object, very minor customization.
What about Lifecycle Management? When applying PeopleTools patches and updates, it is very likely Oracle will replace PSSTYLEDEF_FMODE, erasing your one-line customization. Restoring the customization, however, is trivial. Just re-insert the free form sub stylesheet. It is possible that Oracle may change the HTML structure of Fluid and Classic pages resulting in CSS selector modifications, etc. We, therefore, must test after every update and be prepared to modify accordingly. However, I have used this approach with Fluid from 8.55 through 8.57 with no updates necessary.
Did you find this article helpful? Are you interested in learning more about PeopleTools, including productivity shortcuts such as this one? Take your PeopleTools skills to the next level by registering for one of our courses at jsmspros.com
