Welcome back to this 3 Tip series! Now that you’ve implemented Pro Tip #1 and your Java libraries are all customized, we’ll show you how you can set your XMLs and JSPs ONCE and have your customizations remain intact and safe from future Oracle upgrades and patches.
The significant amount of customization requests that you receive from businesses is centered around the Contributor UI, where the business users or content authors work to perform their day-to-day activities. Therefore, the customization needs are centered around the ease of creating and editing assets of various types, workflow assignments, approval, and publishing mechanisms.
Requests might also pop up from administrators to build sophisticated Utilities or Tools that are helpful to review, audit, and automate certain administrative tasks ranging from Workflow reviews to content lifecycle reports.
In both of the above cases, OWCS developers end up tracking corresponding sets of elements, for example XML or JSP (usually referred to as Core Elements), which are responsible for a particular functionality to be customized for enhancement or sophistication. This blog will show you how to customize the XMLs and JSPs so they can be safe from future product upgrades and patches.
CustomElements
Once the responsible core element(s) is found, it is highly recommended not to tamper with it. Instead, create your own custom element and store it under CustomElements of the ElementCatalog to ensure its preservation during upgrades. The OWCS engine is designed to always execute the element from the “CustomElements” path over the actual core element.
For example, let’s say we have a core element like Folder1/Folder2/File.jsp that displays “Hello U.S.A!” If we create a custom element for it, along with its fully qualified path inside “CustomElements” (for example CustomElements/Folder1/Folder2/File.jsp which is customized to display “Hello World!”), then in the eventuality of the Folder1/Folder2/File.jsp element being called/invoked from anywhere in the product, OWCS always prefers to deploy and compile the element from the CustomElements path, ending up displaying “Hello World!” as the final result, always (!)*.
Though the customization for elements related to Administration application is straight forward (for example CustomElements/<followed by fully qualified root element path>), for most of the Contributor UI customizations involving DOJO, here is the practice to follow:
1. The UI Controller first looks for the customized version of the element by traversing all paths under CustomElements in the following order:
a. Site-specific and AssetType-specific paths:
Customization is applicable only when it relates to SampleAssetType belonging to SampleSite.
Example: CustomElements/SampleSite/SampleAssetType/UI/Layout/CenterPane/Search/View
b. AssetType-specific paths:
Customization is applicable only when it relates to SampleAssetType belonging to any Site.
Example: CustomElements/SampleAssetType/UI/Layout/CenterPane/Search/View
c. Site-specific paths:
Customization is applicable only when it relates to SampleSite, irrespective of any AssetType
Example: CustomElements/SampleSite/UI/Layout/CenterPane/Search/View
d. Global paths:
Customization is applicable, always irrespective of Site and AssetType
Example: CustomElements/UI/Layout/CenterPane/Search/View
2. If the custom element is not found, the UI Controller uses the system-defined element.
How to create a customized element under the ‘CustomElements’ path
Example: If there is a requirement to customize the Search View behavior where the following element is responsible: UI/Layout/CenterPane/Search/View, you can customize it like this:
-
-
- Login to OWCS console
- Go to Admin application and choose an appropriate Site
- Go to New -> CS Element
- Create a new CS Element with the name and RootElement as CustomElements/UI/Layout/CenterPane/Search/View.
-
So, what happens when there is an update to the core element that has been customized using the CustomElements pattern?
The new updated core element and the customized element (remember, it’s customized against an old version) should be compared and merged manually, making sure the customization is compatible and working.
*What if you have a scenario to call the original core element?
Here is our Pro Tip #2, which is undocumented by Oracle. If a scenario arises where you may need to call the actual/original core element, you can “trick” the system by putting the element name inside square braces.
Let’s look at various ways of calling the Core/Customized element(s):
<ics:callelement element=”CustomElements/Folder1/Folder2/File”>
</ics:callelement>
Result: Hello World!
Reason: This is straight-forward. The custom element is written to display “Hello World!” in itself.
<ics:callelement element=”Folder1/Folder2/File”>
</ics:callelement>
Result: Hello World!
Reason: As the elements already have an entry into the “CustomElements” path, the system always picks up the customized element over the actual element.
<ics:callelement element=”[Folder1/Folder2/File]”>
</ics:callelement>
Result: Hello U.S.A!
Reason: Putting the element name in square braces is a trick to request the system to execute the actual/core element without checking for its customized counterpart, even if it exists in the system.
*Note: Since this is undocumented, this could also be unsupported by Oracle. So, please use this very useful trick judiciously.
Stay tuned! Pro Tip #3 in this series is coming soon. And remember—the December Premier Support deadline is fast approaching. You don’t have to do the upgrade alone! Contact us at Inspired ECM to let our experienced consultants upgrade your Oracle WebCenter Sites environment from 11g to 12c so you can start enjoying all the new features and benefits today.
