The most frequently mentioned features of Open UI are
- W3C Standards Compliant and available on any standards compliant browser
- Available across multiple form factors
In this post we will dissect that last bullet. Nothing is unlimited, so it would be unreasonable to expect Open UI to be an exception. :)
Let us start with a recap of the UI customization capabilities of pre Open UI Siebel.
- UI composition using SWE (Siebel Web Engine) Tags in SWE Templates. The following edited screenshot illustrates "containers" that are rendered by the Siebel Server after processing SWE Templates, to accommodate each of the different pieces of the UI. In the following sections, we will refer to the "contained" UI elements (Menus, Toolbars, Grids, Combos etc) as "controls".
- Layout of controls using HTML fluff in SWE Templates. This fluff most commonly includes HTML tables (used only for layout, not for data) and space holder characters and images.
- Rudimentary styling (Color, Font etc) of HTML elements in the UI using CSS. The word "HTML" is significant as this styling does not apply to the UI portions rendered by ActiveX controls e.g. the entire List Applet in HI (High Interactivity) applications.
- Custom Composition of the UI and Layout of UI controls via SWE Templates only allowed up to the level of granularity offered by SWE Tags. e.g. in HI applications, a List Applet can be added to or removed from a View, but the composition of UI elements inside the list applet cannot be changed to render, say, a carousel. This is because the View Web Template is only composed up to the granularity of an Applet, not anything inside an Applet. One the other hand the ActiveX controls that render the more granular UI elements are not open to customization (even though one can write brand new ActiveX controls).
- Most SWE Tags create placeholders for either of two types of controls in the UI
- Menus, Toolbars, Tabs etc for submitting commands to the Siebel Server, Navigation etc.
- The Main View that contains Applets for displaying CRM Data
Each instance of the Controls mentioned above - Menus, Toolbars, Applets etc have concrete configuration in Siebel Tools. Instances of these Objects in tools contain specification of binding of UI controls to the Siebel Business Layer. e.g. the Command Invoked by a Menu Item or a Toolbar Button, or the Business Component and Fields from which an Applet displays data.
- Both Server and Client side scripting facilities are available, but these scripts mainly allow for custom processing of requests from the UI, not custom rendering.
Let us call out a few more details and constraints about the UI customization facilities described above.
- There is no (standard) custom rendering capability available on the client. The client side rendering of control(s) corresponding to each SWE Tag is a black box implementation. Only Binding can be customized in Siebel Tools.
- Since Siebel Repository Applets are directly placed onto the UI via SWE Templates, each Applet is bound to a Business Component (ignoring exceptions where an applet is not bound to a Business Component at all) and customization of Applet rendering is not possible, therefore there is no facility for distributing data from a particular repository Applet across multiple panes in the Siebel Screen e.g. displaying the Address of a Contact in a pane separate from the other details of the contact.
- Purely Interactive Controls (i.e. Menus, Toolbars etc) aside, there is only one Main View area in a Siebel Screen for displaying content. Extra Views are not provided for by an means of configuration.
- There is no way to introduce new UI paradigms that require alternate schemes of binding to the Siebel Business Layer other than what is provided by the Siebel Tools Objects shipped by Oracle.
Siebel Open UI aims to change all these shortcomings. In a nutshell, the aim is to provide for creation of any UI paradigm with any structure of binding to the Siebel Business Layer. A more complete description of the architecture aimed at achieving this vision may be described in a future post. This architecture is still a work in progress. For now, let see which of the above shortcomings have already been overcome and are no longer constraints to Siebel UI development in Innovation Pack 2012.
As the first step of UI creation, server side rendering against SWE Tags in SWE Templates remains unchanged in Open UI.
As we move on to the controls within server rendered containers - we quickly acquaint ourselves with the terms "Presentation Model" and "Physical Renderer". These are central to our understanding of the Open UI client side customization framework. For more details - they are described at length in the Siebel Open UI Configuration Guide.
- A Presentation Model is a client side object that implements the logical model of a particular piece of the UI. Open UI has Presentation Models for every significant piece of the UI - the Application Menu, Toolbar, Visibility Dropdown, Applet Menu, Tabs, different types of Applets etc. The Presentation Model is purely a logical abstraction of the Metadata, Transactional Data and Behavior for part of the UI in question. It does not do the actual rendering of the UI HTML.
- A Physical Renderer sits on top of a Presentation Model and binds to the Metadata, Data and Behavior in the Presentation Model to render the actual HTML and/or interface with third party controls that do the heavy lifting of HTML rendering and event binding.
With that understanding of the client side stack of any given control, we move onto the capabilities of OpenUI
- Given the decoupling between the logical UI model and the actual rendering of the UI via the separation of the Presentation Model and the Physical Renderer, the actual rendering of the UI can be easily changed, without having to re-implement the logical structure and behavior. By now, most people with an active interest in Open UI are aware of the example of the List Applet being displayed as a carousel. This is an example of only the Physical Renderer being changed, along with the usage of a different third party control (grid to carousel), but without changing the generic implementation of a List Presentation Model.
- Logical Behavior of the UI can also be changed, without changing the Physical Renderer e.g. addition of a list column that is local to the client (no representation of the server) in a List Applet can be done via a Presentation Model extension, without having to change the rendering implementation, which is generic enough to iterate through any list of list columns and rendering them.
- Most (and in the long run all) of the UI (comprised of the control containers rendered from the server side Siebel Web Engine as well as the controls rendered by client side Physical Renderers) markup is standards compliant semantic HTML. Thus full blown modern CSS can be applied to it, allowing for extremely high flexibility in customizing the look and feel of the UI. Given this improvement, determining Layout via HTML tables or placeholder images that have no semantic value (and only enforce physical layout) should no longer be practiced. While it may take some time for Oracle to clean up the entire set of SWE Templates in this regard, new customization should absolutely avoid this practice. In short, adding HTML fluff in SWE Templates can be discontinued, with all layout related concerns addressed via modern CSS.
It is easy to see that the customization methods described above provide for nearly unlimited rendering customization of any part of the Siebel UI that implements the Presentation Model and Physical Renderer. Indeed most parts of the Siebel Open UI screen do so, with the Applets being the most notable and rich in terms of the Presentation Model API.
The Physical Renderer of any control offers an unrestricted way to render anywhere on the browser real estate and in any way desired (of course one should be careful not to step on valid markup and event bindings owned by a different control). This offers a solution to the problem of showing different parts of the same applet as different physical panes on the Siebel screen. For those familiar with the example of the temporary recycle bin in the Open UI Configuration Guide, the temporary recycle bin is an example of certain data from the Presentation Model being rendered in a pane that is physically separate from that of the main list applet.
However, there are parts of the UI that do not have a Presentation Model. Typically these are the parts that do not require a Presentation Model or Physical Renderer on the Client. The View is an example of this that deserves special mention. Being just an aggregation of Applets, with the aggregation being rendered from the server as an outer HTML container (a <div> element) containing containers for each constituent Applet, there is no requirement (in the base Siebel Applications) for any rendering or interactivity of the View itself on the client. Unfortunately, without a base Presentation Model being provided by Oracle, there is no way for UI customization to be done on the View via Presentation Model extension. An example of such a requirement could be buttons in the View area, next to the Applets, for expanding and collapsing Applets. This is indeed a shortcoming that has already been pointed out by early adopters of the framework.
The final vision of the Open UI framework aims for all controls that are composed into the UI via SWE Template configuration, to have a Presentation Model and Physical Renderer. In case of a part of the UI such as the View which has no real requirement for a Presentation Model in the base (un-customized) application, the Presentation Model would be a default base Presentation Model.
The Siebel View is further shortchanged, by being deprived of any real identification on the Client. This design is a legacy of pre Open UI Siebel. This was not a problem earlier, because before Siebel Open UI, there was never any thought of allowing the addition of any custom content pane to the Siebel Screen, outside the Main View. But the moment that becomes a requirement, more than one view needs to be identifiable and maintainable by the Client Framework. While there are instances of such Views in the base Applications, such as the Task Pane used by Task Based UI or the iHelp Pane, these are implemented using a not so elegant Oracle internal mechanism that will be deprecated as soon as the Open UI framework becomes capable of accommodating multiple Views in a Siebel Screen.
So, in summary, for Innovation Pack 2012, we have
- Virtually unlimited customization capability of Applet UI
- Ability to spread the content from a logically single Siebel Applet into multiple physical panes in the Siebel Screen
- Ability to apply full fledged modern CSS rules to the UI allowing for powerful customization to look and feel of the UI.
There are also limitations that we should be aware of, in order to know when we are overstepping the boundaries of the framework (and therefore may need to change revisit implementation when the framework gaps are plugged).
- The View has no Presentation Model and therefore the framework does not provide for custom UI at the View Level (inside the View but outside the Applets)
- The Framework does not allow for configuring more than one View. Thus this fundamental limitation in Siebel will remain for some more time
- Parts of the Siebel Screen other than the Applet have respective Presentation Model and Physical Renderer stacks, but the Presentation Models may not be designed well enough for extension, and documentation for the same is not exhaustive as yet.
Another significant change to Open UI is the removal of SI (standard interactivity) rendering. Apart from SI Applications themselves, even HI (high interactivity) applications had SI applets. Notable examples were homepages for most of the CRM objects (Account, Contacts etc) and the popup applets that were invoked on actions on Application Menu Items. Any configuration of SI Applets is no longer supported in Open UI. Where ever the following message is displayed, it signifies the presence of an SI Applet in the Siebel Repository.
How these are to be re-engineered, and indeed a more detailed explanation of SI rendering versus the rendering mechanism in Open UI is the topic of a different post.
That is all for today folks! This post has already consumed more its rightful space.There is much more say about Open UI, and we will be back with more very soon!