| Siebel CRM Configuring Siebel Open UI Siebel Innovation Pack 2016, Rev. A E52417-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Configuring Siebel Open UI Siebel Innovation Pack 2016, Rev. A E52417-01 |
|
Previous |
Next |
View PDF |
This topic describes the development architecture that you can use to customize Siebel Open UI. It includes the following information:
"Differences in the Server Architecture Between High Interactivity and Siebel Open UI"
"Differences in the Client Architecture Between High Interactivity and Siebel Open UI"
Siebel Open UI uses objects to deploy each element that it displays in the client. You can customize each of these objects. 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:
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
Figure 3-1 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 Div Containers on Siebel Servers".
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".
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.
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.
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".
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".
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 3-2 outlines the class structure of plug-in wrappers.
Explanation of the elements in Figure 3-2:
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".
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".
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".
Siebel Open UI uses presentation models and physical renderers to bind data to the user interface.
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.
Siebel Open UI 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 an application so that a field is required or uses a hierarchical picklist. It also allows you to do the following customizations:
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.
Figure 3-3 illustrates how Siebel Open UI renders the Contact Form Applet.
Siebel Open UI does the following to render the Contact Form Applet:
The user attempts to navigate to the Contact Form Applet.
Siebel Open UI creates the view that displays this applet.
Siebel Open UI references the manifest to identify the files it must download to the client. For more information, see "Configuring Manifests".
Siebel Open UI downloads the JavaScript files it identified in 3 to the client.
A presentation model formats the data and applies application logic. For more information, see "Example of a Presentation Model".
A physical renderer registers itself with a corresponding object. A presentation model also does this registration. For more information, see "Example of a Physical Renderer".
A physical renderer fetches and incorporates plug-in wrappers for its applet controls. For more information, see "Example of a Plug-in Wrapper".
Siebel Open UI loads the cascading style sheets according to the manifest configuration that it referenced in Step 3.
Siebel Open UI uses a presentation model, physical renderer, and cascading style sheets to render the Contact Form Applet.
Figure 3-4 describes how the partialrefreshpm.js file does a partial refresh. It is recommended that you include this business logic in a presentation model so that more than one modeler can reuse it. To get a copy of this file, see Article ID 1494998.1 on My Oracle Support. To view an example that uses this file, see "Displaying and Hiding Fields".
The partialrefreshpm.js file includes the following sections:
Creates the JavaScript namespace.
Uses the Define method to make sure Siebel Open UI can identify the constructor. For more information, see "Define Method".
Creates the presentation model class.
Customizes a predefined presentation model to support partial refresh logic.
Includes the logic that Siebel Open UI runs if the user changes records.
Includes the logic that Siebel Open UI runs if the user modifies a field value in a record.
Figure 3-5 describes how the partialrefreshpr.js file does a partial refresh for a physical renderer. To get a copy of this file, see Article ID 1494998.1 on My Oracle Support. To view an example that uses this file, see "Displaying and Hiding Fields".
The partialrefreshpr.js file includes the following sections:
Creates the JavaScript namespace.
Uses the Define method to make sure Siebel Open UI can identify the constructor. For more information, see "Define Method".
Creates the physical renderer class.
Specifies the ShowJobTitleRelatedField property.
Includes the logic that Siebel Open UI runs if it modifies ShowJobTitleRelatedField.
Figure 3-6 describes how the ColorBoxPW.js file does a partial refresh for a physical renderer. To get a copy of this file, see Article ID 1494998.1 on My Oracle Support. To view an example that uses this file, see "Process of Customizing the Plug-in Wrapper".
The ColorBoxPW.js file includes the following sections:
Creates the JavaScript namespace.
Uses the Define method to make sure Siebel Open UI can identify the constructor. For more information, see "Define Method".
Creates the plug-in wrapper class.
Implements the Life Cycle and Interface Methods of a Plug-in Wrapper.
Implements events handlers and other methods specific to the given Plug-in Wrapper.
Wires the Plug-in Wrapper to the Physical Renderer (optionally) based on conditionals.
Siebel Open UI uses two JavaScript files to implement the presentation model and the physical renderer and plug-in wrappers that it uses to display an applet. For example, it uses the following files to display a carousel:
ListPModel.js for the presentation model
CarouselRenderer.js for the physical renderer
It uses the following files to display a grid:
JQGridRenderer.js for the physical renderer
ListPModel.js for the presentation model
It uses the following concatenated file for all applet controls:
pwinfra.js is a concatenation of all the plug-in wrapper objects used for all standard applet controls in the Siebel application
Siebel Open UI considers static and dynamic values as part of the presentation model that it uses. For example, a list applet includes columns and renders data in each column in every row. Metadata specifies the column name and other details for each column, such as required, editable, and so on. These values are static. Siebel Open UI does not modify them unless you configure it to modify them as part of a customization effort. A list applet can also include dynamic values. For example, a value that identifies the record that is in focus, or the total number of visible records. Siebel Open UI can modify the value of a dynamic value in reply to an external event according to the behavior of the model. For example, if the user clicks a field in a record, and if this record is not in focus, then Siebel Open UI modifies the property that stores the focus information to the record that the user clicked. You can implement this type of functionality in a presentation model. For more information, see "About the Presentation Model".
You can modify a presentation model to add a list column. For example, you can modify the SIS Product List Applet so that it displays a Select column that allows the user to choose more than one record, and then press Delete to delete them. You only modify a presentation model to implement this example. You do not modify a physical render. Siebel Open UI uses the JQGridRenderer physical renderer for the grid control. JQGridRenderer is sufficiently generic that it can iterate any list of columns that the presentation model returns. To view an example of this modification, see "Customizing List Applets to Render as Maps".
You can add behavior to a presentation model. For example, you can configure a presentation model to display or hide a set of fields according to the value of another field. You can configure Siebel Open UI so that the Job Title field on the Contacts form applet determines whether or not it displays the Work# field and the Main Fax# field of a contact. If the Job Title includes a value, then Siebel Open UI displays the Work# field and the Main Fax# field. A presentation model defines this conditional display. The physical renderer requires no configuration to implement this example. It queries the presentation model, and then renders these fields according to the instructions that it gets from the presentation model. You can implement this behavior on the client without modifying any configuration on the Siebel Server. For a detailed description of an example that uses this type of configuration, see Chapter 4, "Example of Customizing Siebel Open UI."
You can use a physical renderer to modify how Siebel Open UI renders an object. For example, Siebel Open UI displays the predefined Contact Affiliations list applet as a typical Siebel CRM list. You can modify this list to display as a carousel. You can modify how the user scrolls through a set of records, which is a physical aspect of the applet that a physical renderer defines. But this list is still a list of records that is a logical representation of the applet that the presentation model defines. You do not modify this logical representation. To view an example of this type of modification, see "Customizing List Applets to Render as Carousels". For more information, see "About the Physical Renderer".
You can use a plug-in wrapper to modify how Siebel Open UI renders an Applet Control object. For example, Siebel Open UI displays all fields with boolean values as Check Boxes. You can modify this to display them as flip switch controls. You can modify how the user sets and resets the value of the boolean field, which is a physical aspect of the applet control that a plugin wrapper defines. But this control is still a boolean field: the logical representation of the applet control that the presentation model defines. You do not modify this logical representation. To view an example of this type of modification, "Customizing a Plug-in Wrapper". For more information, see "About Plug-in Wrappers".
Figure 3-7 describes the stack that Siebel Open UI uses to render objects. It uses the applet object as an example.
The stack that Siebel Open UI uses to render objects includes the following items:
Physical layout and styling. Allows you to use HTML to display content, JavaScript to customize logic, and cascading style sheets to customize layout and styling in the client. You can position or hide controls to achieve almost any layout requirement.
Physical renderer. For more information, see "About the Physical Renderer" and "About Plug-in Wrappers".
Presentation model. For more information, see "About the Presentation Model".
Proxy objects. Includes object instances for the client proxy. Each of these instances represents an instance of a corresponding repository object that resides on the Siebel Server. Example objects include a view, applet, business object, or business component. A proxy object includes only enough logic to allow the client to use the same functionality that the server object uses, including the data and metadata that the server object requires. A proxy object exposes the interface for scripting in the client, but it does not allow you to significantly modify the physical user interface. You can customize only the information that flows from the Siebel Server to the client. You cannot customize how Siebel Open UI uses the metadata or data in the proxy object to render the physical user interface. In this example, proxy objects include the applet proxy and business component proxy that contain data and metadata from the Server Response property set. For more information, see "Browser Script Compatibility".
Siebel Property Set. A hierarchy that Siebel Open UI uses to communicate between objects that reside on the Siebel Server and the proxies that reside in the client.
SWE run-time applet object. Exposes scripting interfaces that allow you to modify the applet so that it can control the business component or business service that this applet references. The applet that resides on the Siebel Server gets a request from the proxy applet instance that resides in the client. If necessary, it sends the request to a business component or business service. Siebel Open UI does not currently include a scripting interface that allows you to modify the property set that the applet sends to the client.
Applet metadata. The applet object in the Siebel Repository File (SRF) that contains information that Siebel Open UI uses to bind the user interface to the business component. Siebel Open UI maps this information through business component fields. This binding can include only a one-to-one mapping between one applet control and one business component field. Siebel Open UI does not allow more complex bindings. You can configure Siebel Open UI to get data through a presentation model in the client to develop functionality that is similar to the functionality that a more complex binding provides. For more information, see "About Objects and Metadata".
This topic describes a typical example of how Siebel Open UI uses a presentation model and physical renderer for an applet that it displays in a view. Every object that Siebel Open UI renders uses this same object stack. You can customize objects in this stack to modify rendering and behavior. For example, you can customize the presentation model and physical renderers that implement view navigation to use tree navigation instead of the predefined nested tab navigation.
Figure 3-8 describes an example stack that Siebel Open UI uses to display a calendar applet.
Siebel Open UI uses the following items to display a calendar applet:
Jquery FullCalendar. The physical JavaScript control. A third-party typically provides this control.
jqfullcalrenderer.js. Binds the CallPresentationModel object that the calpmodel.js file contains with the third-party calendar control.
calpmodel.js. Describes the logical behavior for the calendar user interface that Siebel Open UI displays on top of a list applet.
Activity proxies. Includes proxies for the Activity HI Calendar Applet and the Activity business component.
Figure 3-9 indicates the predefined items in the development architecture that Oracle provides and the items that you can modify. It delineates areas where you can customize Siebel Open UI.
Table 3-1 describes some example client customizations you can do in Siebel Open UI. For detailed examples, see Chapter 6, "Customizing Siebel Open UI."
Table 3-1 Example Client Customizations
Figure 3-10 compares the server architecture between high interactivity and Siebel Open UI.
This comparison between the architecture that high interactivity uses and that Siebel Open UI uses includes the following items:
Rendering customization in high interactivity requires you to use a SWEFrame customization at the applet level.
Rendering customization in Siebel Open UI allows you to use SWEFrame customization, an equivalent customization, or to customize the physical renderer independently at any level of the object hierarchy, including at the subapplet level for an applet control.
High interactivity always starts rendering at the view level. It uses predefined code in the user interface hierarchy, from a request processing perspective.
Siebel Open UI uses objects, so rendering can occur at the screen, view, applet, or control level.
Figure 3-11 compares the ActiveX UI architecture that a high-interactivity client uses to the architecture that Siebel Open UI uses.
This comparison between high interactivity and Siebel Open UI includes the following items:
Client Environment. The Siebel Open UI client environment allows you to customize run-time configurable objects to meet a wide range of rendering requirements, from supporting more than one Web browser type to deploying to various client form factors.
Style sheets. The Siebel application or Web Server serves static style sheets.
Siebel Web Templates. The Siebel application or Web Server serves dynamic Siebel Web Templates.
