Next in series >>
Luckily I got a chance to work on a Siebel Open UI project (now you know the reason for my absence). As we already know there is lot of difference in doing a POC and implementing real business requirements. When I came to know about the requirements for this project, I knew it is something that has never been done before and if successful Open UI would have crossed a major milestone at least in my eyes i.e from a Concept to a real technology that can be used for real projects.
As expected with new technology there were lot of issues and limitations that we came across but also found the areas where Open UI excels and delivers a WOW experience (jQuery plugins). I would say that Open UI has still some way to go but it is definitely moving in right direction. It is not as stable as I would have liked it to be. Next few posts are aimed at exposing the limitations/issues that we faced with Open UI and also displaying some of the features that we implemented displaying the power and capability of Open UI.
I will start with limitation that I think is the costliest mistake/limitation Open UI has i.e Themes.
When Siebel Open UI was introduced Themes were displayed as a great feature show casing the Open UI flexibility of allowing users to change the look and feel of Siebel completely by changing a value from a drop down but I feel it is an incomplete solution and was not thought through before implementation. Here are the major issues with Themes feature.
JS File: With 22.214.171.124 Oracle saved us a major headache of dealing with XML and manifest files by moving them to Tables and providing us with Manifest Administration view but they forgot themes. Although I think it will be addressed in future (there is a dropdown for themes in Manifest Administration) but you still have to go and change JS files, Add LOV to add new themes.
Default Theme: This is one of the biggest limitation of themes. There is no way to set the default theme other than going to User Preferences Screen and choosing from drop down. Imagine this, You create a brand new theme for you application and you want every user to use as default. So how do you do it? Request every user to go and change preference manually.
Sure, you can implement an elaborate work around of going to personalization BC and create calculated field to set default theme but unfortunately that doesn’t work in multi lingual application and it takes away the flexibility of changing themes or you can always hire Oracle Expert Services 😉 .
One Look for all: There is no way to set different themes for different object managers/applications since there is just one themes.js file and only one user preference.
Real life scenario: I have customer facing portal and internal application. I want both of these applications to use different default themes.
No Documentation: There is no proper documentation explaining addition of themes in 126.96.36.199. They have introduced custom theme.js that should be used to include new themes but there are not clear steps or instruction on how to go about this process.
Now to answer the question that might have popped up in your mind, Why is this such a big Limitation?
These limitations caused us to duplicate the Web Templates for different applications and override default theme thus increasing the effort required to maintain the application and make changes. It also impacting ability to have seem less upgrades to a different patchset as the JS files are modified and changed with every patchset.
Oracle needs to give a simple way to set Themes at object manager or application level without any need to modify the JS files. If you are in process of implementing a theme for you application keep these things in mind.
Stay tune! More coming soon
Next in series >>