You want to make enhancements to Siebel with a global reach? Depending on the type of implementation with Open UI you have several options:
1) You could use opt for a control plug-in wrapper, if the customization should affect functionality of controls. Examples could be enhancing the out-of-the-box functionality of check-boxes, text-area controls, turn a picklist control into a slider or adding placeholder text to the ‘search’ fields. The plug-in wrapper framework introduced in IP14 truly is an amazing gift as part of the Open UI extensibility portfolio.
2) Although with care and consideration, a postload solution could be appropriate. Postload as it implies is a piece of code which the OpenUI framework executes ‘post’ loading a view. Since Siebel is not a single-page application, postload executes on every view navigation (= HTTP Post). I used it to ‘fix’ a bug, create the pinnable views solution or to add a logout button.
3) Sure, you could opt to add your custom Presentation Model or Physical Renderer to all of your applets through standard Manifest Administration functionality. But well, that honestly is not what I mean by ‘global’.
4) The use of the SiebelHub’s Siebelhub.js ‘Overdrive‘ method. The Siebelhub.js arrived a few months ago on Github. Want to propose your enhancements, just make a first commit! Together it can be made even greater.
5) And well, option 5. That is the Manifest override of the ‘DEFAULT LIST APPLET’, ‘DEFAULT FORM APPLET’, ‘DEFAULT CHART APPLET’, ‘DEFAULT TREE APPLET’, ‘DEFAULT VIEW’ or ‘DEFAULT WEB PAGE’. And although I was happy to learn about this feature introduced a long with IP14, it has bitten me a couple of times. This option is not for the faint of heart. One tiny typo, and you might not even be able to login anymore. But that can be overcome, by ensuring an easy exit. Just employ an expression for the associated custom file, which disables the custom override for a particular user. Or just replace the defective file with an empty skeleton.
But most importantly, the Manifest override has a nasty side-effect. It overrides all (yes, all) seeded applet specific presentation models or physical renderers. If you like it or not. So in case a particular applet has a ‘seeded’ presentation model or physical renderer, your custom override will override that one to. Well – that is the status-quo for IP14/15.
For IP16 development choose to change the ‘evaluation’ order of global overrides. Such that it will not break the ‘seeded’ renderers. The image explains how it will work going forward. In effect a custom override will not override, once a specific seeded presentation model or physical renderer exists. So what global overrides would fit this model? Think of adding double-click behavior or adding the glyphified navigation buttons.
All said, development did earmark this option with the UAYOR label 🙂