Configuring Siebel Open UI > Architecture of Siebel Open UI > About the Siebel Open UI Development Architecture >

Overview of the Siebel Open UI Development Architecture

Siebel Open UI uses objects to deploy each element that it displays in the client. You can customize each of these objects in a way that is similar to how you customize each object in a high-interactivity client. You can customize each object separately. Each object resides in a layer that implements a particular area of customization. For example, you can customize each of the following items that you can also customize in high interactivity:

• Application
• Screen
• View
• Applet
• Applet Control
• Menu
  • Application menu
  • Applet menu
• Toolbar
  • Application toolbar
• Navigation object
  • Tabs at different levels
  • Visibility menu
• Predefined Query (PDQ) menu

Architecture You Can Use to Customize Siebel Open UI

Figure 6 illustrates the basic architecture that you can use to customize Siebel Open UI. For an overview of how Siebel Open UI uses the presentation model and physical renderer, see How Siebel CRM Renders Siebel Open UI Clients.

Figure 6. Architecture You Can Use to Customize Siebel Open UI

About the Presentation Model

The presentation model is a JavaScript file that specifies how to handle the metadata and data that Siebel Open UI gets from the Siebel Server, and then displays this information in a list applet or form applet in the client. It allows you to customize behavior, logic, and content. It determines the logic to apply, captures client interactions, such as the user leaving a control, collects field values, and sets properties. A presentation model can get the following items from the proxy, and then expose them for external use. These properties and methods are similar to the properties and methods that most software models use:

• Properties. Contains information about the current state of each user interface element. For example, if Siebel Open UI currently displays or hides a field.
• Methods. Implements behavior that modifies the state of an object. For example, if the user chooses a value, then a method can hide a field.

A presentation model can contain customization information that is separate from the predefined configuration information that Siebel Open UI uses for physical rendering. For example, it can display or hide a field according to a pick value.

For more information, see Example of a Presentation Model.

About the Template Manager

The template manager is a JavaScript object that provides HTML markup as requested by a physical renderer, a plug-in wrapper or any other active JavaScript object running in Siebel Open UI. A template manager ensures that each component of Siebel Open UI generates exactly the same markup, enhanced with a predefined classname, for similar type of UI controls that is independent of device, browser, and resolution. For example, if a text field is being rendered in Siebel Open UI, it must use same a classname, for example, "siebui-input, whether it is being rendered in a browser on a desktop, or a mobile device.

About the Template Manager in Responsive Web Design

One of the most crucial aspects of responsive web design is to have clean and virtually identical DOM elements within a specific classname for a control. For example, an anchor can also be styled in such a way that it appears similarly to a button in one context and in another might appear as a hyperlink.

You must, however, provide the same DOM element for a particular type consistently, coupled with a specialized classname, when required. The template manager then acts as an HTML content provider for all types of primitives controls.

How it Works

The template manager expects the caller, which in most cases would be renderers or plug-in wrappers, to provide certain information on what kind of control they need. For example, does the caller need to create input element? Depending on the type and other parameters specified by the caller, the template manager determines the control that is required, then builds an HTML string and returns that string to the caller. The template manager also provides the flexibility to add more DOM attributes which may or may not be standard, for example mobile specific "data-" attributes, or automation attributes.

For more information about the template manager class, see Template Manager Class.

About Event Helper Objects

Event helper objects facilitate event binding in a physical renderer or a plug-in wrapper. They consolidate events across platforms, most importantly standardize events such as touch and click. The differences required in rendered markup and the behavioral aspects, if any, can be handled internally by the template manager and the even helper object respectively.

For more information about the event helper objects, see About Event Helper Objects.

About Plug-in Wrappers

A plug-in wrapper is a complete and independent manager of an applet control and its life-cycle. It is entirely responsible for all actions of a control, including but not limited to its showing, value management, event handling. Plug-in wrappers cater to control level management. A plug-in wrapper allows the wrapper to handle the control of specific functionalities. Individual renderers will delegate the control-specific-functionalities to the wrappers. The wrappers handle the applet control level implementation.

Figure 7 outlines the class structure of plug-in wrappers.

Figure 7. Class Structure of Plug-in Wrappers

Explanation of the elements in Figure 7:

• Base Plug-In Wrapper. This is the base specification class. It defines the base properties and methods to which every plug-in wrapper must adhere. No functionality is implemented in this class and it is not recommended that any derivation or customization occur from this class.
• Field Plug-In Wrapper. This is the class that defines the default functionality of a control. All APIs have a definition, and this plug-in wrapper is a fallback class for all customizations. You may choose to derive a custom wrapper from this class if your intention is to write a new customization.
• Plug-In Wrapper 1, Plug-In Wrapper 2, Plug-In Wrapper 3, Plug-In Wrapper N. These are Siebel Open UI out-of-the-box customizations that are used to display specific types of controls. Examples of these are date pickers, drop-down menus, flip switches and signatures. You may choose to derive a custom wrapper from one of these classes if your intention is to slightly modify the functionality of an existing plug-in wrapper.

For more information about plug-in wrappers, including detailed instructions about creating and customizing a plug-in wrapper, see Process of Customizing the Plug-in Wrapper, and Plug-in Wrapper Class.

About the Plug-in Builder

The plugin builder wires the physical renderer to a plug-in wrapper for a given control and a given set of conditions. It also provides a decoupling between physical renderers, such as an applet, and plug-in wrappers for controls in that applet.

For more information see, About Plug-in Wrappers, and Plugin Builder Class.

About the Physical Renderer

A physical renderer is a JavaScript file that Siebel Open UI uses to render the user interface. It binds a presentation model to a control. It can enable different behavior between a desktop client and a mobile client. It allows the presentation model to remain independent of the physical user interface objects layer. It allows you to use custom or third-party JavaScript code to render the user interface. It can display the same records in the following different ways:

• List Applet
• Carousel
• Calendar
• Mind Map

For more information, see Example of a Physical Renderer.

How Siebel Open UI Uses the Presentation Model and the Physical Renderer and Plug-In Wrapper

A high-interactivity client allows you to use scripts, but it does not include a formal environment that binds data to the user interface. It customizes a controller instead of customizing a view. Siebel Open UI uses presentation models and physical renderers to meet this requirement.

A user interface object includes a combination of the following items:

• Physical presentation and interaction for a user interface element. For example, a grid, carousel, form, tree, tab, menu, button, and so on.
• Logical presentation and interaction that Siebel Open UI can physically display in more than one way. For example, Siebel Open UI can display a list of records in a grid or in a carousel. The logical representation of this data includes the metadata that Siebel Open UI uses to determine the Siebel CRM information that this list of records contains. It does not include information that Siebel Open UI uses to physically display this list as a grid or carousel.
• Presentation and interaction information. Includes application metadata, transaction data, and configuration information that determines client behavior. Siebel Open UI binds these items to the generic presentation. For example, it can determine whether or not a field is required, and then identify the data that it must display in a list column, or it can identify the business service method that it binds to a button.

A high-interactivity application can bind metadata, data, and logical behavior to a generic user interface in a highly configurable and declarative manner. It drives a fixed set of user interface presentation and interaction options. For example, you can configure a high-interactivity application so that a field is required or uses a hierarchical picklist. Siebel Open UI can use this configuration, but it also allows you to do the following customizations that you cannot do in high interactivity:

• Add a completely new presentation or interaction feature in the user interface. For example, display or hide a field according to a pick value.
• Create a new or modify an existing logical user interface object. For example, you can use Siebel Open UI to customize an object so that it displays a list of records in an infinite scroll list, which is an object that allows the user to view these records in a sliding window that displays records over a larger list of records that already exist in the client. It allows the user to do an infinite scroll in a mobile user interface. Note that, from a usability standpoint, it is almost always preferable to configure Siebel Open UI to use an interface that allows the user to page through sets of records rather than use a scroll list. This configuration reduces uncertainty regarding the records that Siebel Open UI has or has not displayed in the visible portion of the client.
• Modify the type of user interface element that Siebel Open UI uses to display information. For example, you can configure Siebel Open UI to display a list of records in a carousel instead of on a grid. You can also configure Siebel Open UI to display a check box control in a grid or a form as a flip switch.