Architecture of Siebel Open UI

This chapter describes the architecture that you can use to customize Siebel Open UI. It includes the following topics:

About the Siebel Open UI Development Architecture

This topic describes the development architecture that you can use to customize Siebel Open UI. It includes the following information:

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. 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

Architecture You Can Use to Customize Siebel Open UI

The following figure 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.

About the Presentation Model

The presentation model is a JavaScript file that specifies how to handle the metadata and data thatSiebel 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 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.

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.

The following figure outlines the class structure of plug-in wrappers.

Explanation of the elements in the previous figure:

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 Context Renderers

A context renderer is a JavaScript object that Siebel Open UI optionally uses to enhance the user interface for generic functionality. It is an extension to the physical renderer and provides loose coupling for specific UI operations. A physical renderer can have one or many context renderers. In an ideal scenario, a context renderer should always be limited to user interface operation.

For example, if all Applets in a view needs to be rendered as Accordion Panel, it can be implemented as context renderer. Also, the context renderer can be attached to view physical renderers without any impact on the View PR functionality.

How Siebel Open UI Uses the Presentation Model and the Physical

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.

Example of How Siebel Open UI Renders a View or Applet

The following figure illustrates how Siebel Open UI renders the Contact Form Applet.

Explanation of Callouts

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 Step 3 to the client.
A presentation model formats the data and applies application logic. For more information, see About the 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.
One or many context renderers register themselves with a corresponding object. For more information, see Example of a Context Renderer.
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, context renderer (optional), and cascading style sheets to render the Contact Form Applet.

Example of a Presentation_Model

The following figure 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.

Explanation of Callouts

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.

Example of a Physical_Renderer

The following figure 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.

Explanation of Callouts

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.

Example of a Plug-in_Wrapper

The following figure 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.

Explanation of Callouts

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.

Example of a Context Renderer

The following figure describes how the controlsmenuCR.js file does the UI transformation of button controls in a menu. When configured as a context renderer for Contact Form Applet via Manifest, it displays the Applet Button Controls in Menu instead of displaying them inline.

Explanation of Callouts

The controlsmenuCR.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 context renderer class.
Implements the Life Cycle and Interface Methods of a context renderer.

Customizing the Presentation Model and Physical Renderer

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

Customizing the Presentation Model

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.

Example of Customizing the Static and Dynamic Values of a 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.

Example of Customizing the Behavior of a Presentation Model

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 Example of Customizing Siebel Open UI

Customizing the Physical Renderer

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.

Customizing a Plug-in Wrapper

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.

Stack That Siebel Open UI Uses to Render Objects

The following figure describes the stack that Siebel Open UI uses to render objects. It uses the applet object as an example.

Explanation of Callouts

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 runtime 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 Runtime Repository 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.

Example Stack That Siebel Open UI Uses to Render Objects

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.

The following figure describes an example stack that Siebel Open UI uses to display a calendar applet.

Example Stack That Siebel Open UI Uses to Render Objects

Explanation of Callouts

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 a list applet.
Activity proxies. Includes proxies for the Activity Calendar Applet and the Activity business component.

Items in the Development Architecture You Can Modify

The following figure 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.

Example Client Customizations

The following table describes some example client customizations you can do in Siebel Open UI. For detailed examples, see Customizing Siebel Open UI.

Table Example Client Customizations

Customization	Work You Must Do
Customize a list applet or form applet.	You can use Siebel Tools to customize a list or form applet in the Siebel Repository. This work completes the basic binding to the Siebel object layer and displays a list or form in the client. No client customization is required. For more information, see Using Siebel Tools.
Add custom client behavior.	You modify a presentation model. For example: Display or hide a control. For example, show a control if the user chooses a value from a drop down list. You add the required logic to a presentation model. You add or remove the control from the set of controls that Siebel Open UI already displays in the applet proxy in the client. For example, to add a local control in the client, you add this control in the presentation model to the set of controls that the proxy already contains. Some configuration requirements do not require you to modify the physical renderer. For example, it is not necessary to modify the physical renderer to display a control because the predefined implementation for getting all fields from the client is already available. Modify the theme of a page. For example, you can configure Siebel Open UI to modify the theme of a page if the user changes the orientation of a tablet device. You add the logic that modifies styles that the user interface elements use when Siebel Open UI modifies the orientation state in the presentation model.
Add generic client behavior.	You use a control to render the presentation model. For example, to render a list applet as a carousel, you use the appropriate third-party control.
Add specific applet control-level behavior and rendering.	For example, you can customize plug-in wrappers to make a boolean field render and behave like a flip switch, rather than a check box.
Position controls and customize style.	You modify CSS files.

Differences in the Server Architecture Between High Interactivity and Siebel Open UI

The following figure compares the server architecture between high interactivity and Siebel Open UI.

Comparing Server Architecture Between High Interactivity and Siebel Open UI

Explanation of Callouts

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.

Differences in the Client Architecture Between High Interactivity and Siebel Open UI

The following figure compares the ActiveX UI architecture that a high-interactivity client uses to the architecture that Siebel Open UI uses.

Comparing Client Architecture Between High Interactivity and Siebel Open UI

Explanation of Callouts

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 Application Interface serves static style sheets.
Object Definition Htmls. The Siebel application serves dynamic Object Definition Htmls.

Life Cycle of User Interface Elements

This topic describes how Siebel Open UI uses presentation model methods and physical renderer methods, and the methods that the presentation model and physical renderer calls during the life cycle of a user interface element.

The presentation model uses the following sequence of methods:

Init
Setup

The presentation model processes the events that it receives from the physical renderer during the life cycle. It also processes the replies for requests that the Siebel Server sends. Siebel Open UI can make the following calls to the presentation model during a life cycle:

Call from the physical renderer because of a user action.
Notification that the Siebel Server sends. For more information, see Notifications That Siebel Open UI Supports.
Process property set that the Siebel Server sends.
Completion request to get a follow-up request after the proxy finishes processing a reply from the Siebel Server.

The physical renderer continues to render each modification that occurs in the presentation model, and the AttachPMBinding method binds each of these modifications during the Init call to the physical renderer. One of the following items then signals these modifications:

Siebel Open UI runs a presentation model method.
Siebel Open UI modifies the value of a presentation model property.

For more information about the methods that this topic describes, see Application Programming Interface.

Summary of Presentation Model Methods

This topic summarizes some of the methods that a presentation model uses during the life cycle of a user interface element.

How Siebel Open UI Uses the Init Method of the Presentation Model

The Init method uses the following methods to configure the properties, methods, and bindings of the presentation model. For an example that uses Init, see Creating the Presentation Model:

AddProperty. Adds a property to a presentation model. This property can be simple or derived. If you use AddProperty to define a derived property, then Siebel Open UI uses the Get method on the presentation model to calculate and return the property value. For more information about deriving values, see Deriving Presentation Models, Physical Renderers and Plug-in Wrappers. For more information, see Get Method.
AddMethod. Adds a method to the presentation model. For more information, see AddMethod Method.
AttachEventHandler. Attaches a method that handles the logical event. Siebel Open UI calls this method when it sends an event to the presentation model through the OnControlEvent method. For more information, see OnControlEvent Method and AttachEventHandler Method.
AttachNotificationHandler. Attaches a method that handles the notification that Siebel Open UI calls when the Siebel Server sends a notification to an applet. A notification is a message that Siebel Open UI sends to the client when this client requests Siebel Open UI to modify a business component. For example, to create or delete a business component record. For more information, see Notifications That Siebel Open UI Supports.
AttachPSHandler. Handles other incoming property sets that the Siebel Server sends to the client. It can extract the values that a property set contains to individual properties or do other processing.
AttachPreProxyExecuteBinding. Attaches a method to the presentation model. Siebel Open UI calls AttachPreProxyExecuteBinding before it processes the reply that it receives from the Siebel Server, but after it receives a reply from this server to the method that Siebel Open UI supplies as an argument. For more information, see Customizing Events.
AttachPostProxyExecuteBinding. Attaches a method to the presentation model. Siebel Open UI calls AttachPostProxyExecuteBinding after it processes the reply from the Siebel Server.

The physical renderer calls the following presentation model methods:

Get. Gets the value of a property that resides in a presentation model.
ExecuteMethod. Runs a method that the AddMethod method calls. For more information, see ExecuteMethod Method.
OnControlEvent. Calls an event. The physical renderer uses the OnControlEvent method to call the presentation model and send an event. To call the method, the presentation model uses a binding that exists between the event and the presentation model method and the AttachEventHandler method. For more information, see OnControlEvent Method and AttachEventHandler Method.
SetProperty. Sets the value of a presentation model property. The physical renderer can set this value directly in some situations. For more information, see SetProperty Method.

How Siebel Open UI Uses the Setup Method of the Presentation Model

The Setup method extracts the values that a property set contains. If Siebel Open UI creates an object on the Siebel Server, such as a frame, then this server sends the property set that describes this object to the client. Siebel Open UI uses this property set to set up the presentation model properties in the client. The Setup method uses the AddProperty method to extract this property set into presentation model properties. It does this work the first time Siebel Open UI creates the user interface object in the client. For more information, see Methods That Manipulate Property Sets. For an example that uses Setup, see Customizing the Setup Logic of the Presentation Model.

Life Cycle of a Physical Renderer

The following figure illustrates the life cycle of a physical renderer. For examples of various life cycle flows, see Life Cycle Flows of User Interface Elements.

Explanation of Callouts

The physical renderer uses methods in the following sequence:

Renderer. Creates the renderer.
Init. Initializes and sets up the AttachPMBinding method. For more information, see Init Method.
Open UI framework makes a call to CR's Init function after instantiating it. OpenUI adds the corresponding physical renderer's instance to this function and the implementation can use the physical renderer or presentation model's interface.
ShowUI. Displays a physical control that corresponds to an applet control. It renders the container for the metadata, data, and event bindings. For example, when Siebel Open UI renders a list applet as a grid, ShowUI renders the third-party grid control that it uses for the applet. Also, ShowUI calls all of the plug-in wrappers of the associated applet controls. For more information, see ShowUI Method.
BindEvents. Sets up the user interface binding of events to the physical user interface, represented as HTML elements. It captures the user actions, and then translates these actions to logical events in the physical renderer before Siebel Open UI sends them to the presentation model for processing. Also, BindEvents calls all of the plug-in wrappers of the associated applet controls. For more information, see BindEvents Method.
BindData. Downloads metadata and data from the Siebel Server to the client proxy, and then binds this data to the user interface. The list columns that a list applet uses is an example of metadata, and the record set that this list applet uses is an example of data. Also, BindData calls all of the plug-in wrappers of the associated applet controls. For more information, see BindData Method.
CR's Execute method will be called by the framework immediately after the physical renderer's lifeCycle method execution, that is, after the ShowUI, BindData, BindEvents functions. OpenUI also adds the corresponding physical renderer's instance to this function and the implementation can use the physical renderer or presentation model's interface.
AttachPMBinding. Attaches handlers to notifications that occur during the life cycle. For more information, see AttachPMBinding Method. For more information about notifications that can occur during the life cycle, see Notifications That Siebel Open UI Supports.
GetPM. Calls a method that the presentation model contains. It is recommended that you use GetPM only to call the following presentation model methods:
- ExecuteMethod
- OnControlEvent
- Get
- SetProperty
You can use ExecuteMethod or OnControlEvent to call a method that modifies the state of the presentation model or to call a method that reads this state. You can use the Get method to get the value of a presentation model property. You can use SetProperty to set the value of a presentation model property.
For more information, see GetPM Method for Physical Renderers and OnControlEvent Method.
EndLife. Ends the life of the physical renderer. For more information, see EndLife Method.

Life Cycle of a Plug-in Wrapper

The plug-in wrapper uses methods in the following sequence:

ShowUI. Performs show related activities for a control. For more information see ShowUI Method.
BindEvents. Attaches events to the DOM instance of the control. For more information see BindEvents Method.
BindData. Initializes data to the DOM instance of the control. For more information see BindData Method.
EndLife. Ends the life of the Plug-in Wrapper. For more information see EndLife Method.

Example of the Life Cycle of a User Interface Element

The following figure describes the life cycle of the calendar user interface element.

Explanation of Callouts

The following sequence occurs during the life cycle of a calendar user interface object:

The user clicks a button that refreshes the calendar.
The Init method adds the following items to the physical renderer:
```
AttachPMBinding ("ProcessCalendarData", RefreshUI)
```
The physical renderer sends the following method to the presentation model:
```
OnControlEvent("Refresh_Calendar",RequestCalendarData)
```
For more information, see OnControlEvent Method.

The Init method adds the following items to the presentation model:

AddProperty (MeetingDates, list of dates)
AddMethod (RequestCalendarData, implementation)
AttachEventHandler ("Refresh_Calendar", RequestCalendarData)
AttachNotificationHandler ("GetCalendarOUIData", ProcessCalendarData)
AttachPostProxyExecute ("GetCalendarOUIData",SetDefaultFocus)

For more information, see AttachEventHandler Method.

The presentation model sends the RequestCalendarData method to the Activity Calendar Applet proxy.
The Activity Calendar Applet proxy sends a request to the Siebel Server to call the RequestCalendarData method.
The Siebel Server gets metadata from the Activity Calendar Applet that resides on this server, and then sends the GetCalendarOUIData notification method to the presentation model. For more information, see About Objects and Metadata.
The presentation model does the following:
1. Runs the ProcessCalendarData method and the SetDefaultFocus method.
2. Sends the RefreshUI method to the physical renderer. This method gets the relevant properties from the presentation model.
The physical renderer refreshes the calendar.