Thanks to Jan Peterson for this articleOracle Sales Cloud has made some significant progress in the past 18 months and has become a very compelling offering. Alex has posted a summary of the R8 release a while ago. Simplified UI is – in my humbled…
In continuation of our mini-series, we will today explore an example solution for a generic physical renderer extension for list applets in Siebel Open UI.
As discussed in the previous part, the solution we want to achieve is that we can define a list of fields which should be conditionally formatted if they are exposed as columns on a list applet. The implementation uses custom applet user properties which are exposed to the physical renderer by a custom presentation model extension.
Today, the focus is on the physical renderer. Before we start, let me reiterate that many ways lead to Rome and the solution presented below is purely educational and should you intend to use it in any environment, including production environments, you do so at your own risk.
Implementing a Physical Renderer for Conditional Formatting
We start with the usual procedure of creating a physical renderer extension file and registering it with a test applet (e.g. the Opportunity List Applet). Remember that the Oracle class for list applet PRs is JQGridRenderer, so this is the correct call for SiebelJS.Extend():
As the formatting takes place when the data is present in the applet, the BindData method is the one we must override, as this method populates the grid cells with the actual data and is called frequently enough (e.g. after a record is updated or during scrolling) for a first prototype.
The following shows the example implementation of the BindData method:
|Click to enlarge.|
The code accomplishes the following:
- Initialize variables with the values of the applet user properties by using the PM’s Get method.
- Verify that a list of fields is actually defined for the applet. If yes, the code continues. If not, the else block is reached and a console message is logged.
- Split the comma separated lists into arrays using the split function.
- Use the GetColMap method of the object returned by the GetColumnHelper method to get a list of columns and their respective business component field names. Note that the two methods used here are specific to physical renderers for list applets and are not documented.
- Iterate through the array of fields. For each field, a second loop iterates through the column list and tries to locate a column associated with that field. When a column is found, the ConditionalFormat method (to be implemented below) is invoked and the name of the column as well as the accompanying threshold value are passed as arguments.
The following is the first part of the custom ConditionalFormat function which actually handles the formatting.
|Click to enlarge|
- Get the current record set from the GetRecordSet property, i.e. all records currently visible in the list applet.
- Get the applet placeholder which will be used to identify the applet and its child elements.
- Get the column map for the applet.
- Retrieve the business component field name for the current column from the column map.
- Access the column header using the jQuery $() function.
- Use the jQuery click() event handler to specify a function which is executed when the end user clicks the column header. This function uses the event object to determine whether the CTRL key has been pressed while clicking. If this is the case, the click event handler function uses the stopImmediatePropagation() method to prevent the click event from “bubbling”, i.e. attracting other event handlers.
- For demonstration purposes, a simple prompt() dialog is used to solicit the new target value from the end user. This could be replaced by a more comfortable jQuery dialog or similar in a real production setting. Finally, the click event handler function invokes the ConditionalFormat method (recursively) to refresh the formatting.
- By adding an img tag to the existing column header HTML code, the function effectively provides a visual cue to the end user that the column and its header have a special purpose. The example code also modifies the title attribute to produce a tooltip message.
|Click to enlarge.|
- Retrieve the pseudo row identifier (1,2,3 and so forth).
- Select the current row using the jQuery find method.
- Select the grid cell for the column.
- Retrieve the cell’s value, which is actually the formatted and localized value.
- Use the replace function to remove characters like $, % or commas from the value string (watch out for localization issues here, the example is for the ENU locale).
- Convert the string to a floating point number.
- Calculate the share of the current value in percent of the target (threshold) value.
- Calculate the green and red color components for the current share. The algorithm increases the green value until the share reaches 50% and then reduces the red value. This results in a red/yellow/green color gradient.
- Use the calculated color to set the background of the cell with the jQuery css() method. For compatibility reasons the example code shows how to set a solid background as well as use the vendor specific linear-gradient CSS rules. A browser which understands the linear-gradient rule will apply it, other browsers will show a solid background.
|Click to enlarge.|
In an attempt for a real-life scenario of customizing the appearance of all list applets in a Siebel Open UI enabled application, I would like to introduce you to a coding experiment for conditional formatting of list columns.As usual, let’s see what w…
It is not without some parental joy that we announce a new Siebel CRM book to be published this winter.Together with three of the most distinguished Siebel Open UI experts, this humble writer is currently working on putting together useful informa…
Time for another Open UI adventure. In this article, I would like to show you the results of an experiment.If you watch the Siebel Open UI space attentively, you are sure aware of the introduction of presentation models and physical renderers for views…
Using a global override is superior to using the postload event handler which might soon become bloated with all the stuff you want to achieve on non-specific objects.
Recently, I had some time to investigate this feature a bit more closely. Some of my dear readers might remember the “See-Through Applets” which involves a double-click event handler. When a form applet is double-clicked, the labels are replaced with metadata from the business component layer. Another double click reveals the table and column names where the data is stored. The final solution I presented used a postload event handler.
|Siebel form applet in “see-through” mode 😉|
So let’s see how I adjusted the see-through applet code to work with a global override. The goal was again to enable the functionality on every form applet with a minimum effort.
1. Create a physical renderer extension
The first thing I did was to create a physical renderer extension file. Just the “normal” thing
2. Register the custom file as a default entry
Next, I followed the usual steps to register the file in the Manifest Files view of the Administration – Application screen.
In the Manifest Administration view, the big difference was to query for the seeded DEFAULT FORM APPLET entries in the UI Objects list and copy the existing entry for the Physical Renderer usage type.
Then I proceeded to add an expression and my custom file (as usual). Here is the result:
|Click to enlarge|
The Open UI framework will read all entries and ensure that the as-delivered files and the custom overrides are loaded whenever a form applet needs to be renderered.
3. Implement the double-click handler
Now I was able to migrate the code which defines the double-click functionality from my custom postload event handler to the new default physical renderer extension’s ShowUI method. In fact I could comment out some lines as it was no longer necessary to establish a “connection” to the form applet. Another benefit of staying inside the framework 😉
|The ShowUI method of the override physical renderer. Click to enlarge.|
I retired (i.e. commented out) the code in the postload event handler and reloaded the browser cache and voilá, the same as before but without extraneous code in the postload event handler.
have a nice day
Among the uncountable browser extensions for Google Chrome, there are many which prove useful for the weary Siebel Open UI developer.One of these extensions should stand representative for them all, and I really use it a lot.The extension is simply cal…
The following post does not go without a hat-tip to fellow Siebelian Slava who found an easy way to introspect variables, call functions etc, while debugging a Siebel Open UI application in Google Chrome.If you are familiar with the Chrome developer to…
If you have applied the monthly patch set 188.8.131.52.4 or later, you would expect to be able to manage activities in the Calendar views by dragging and dropping them onto the calendar applet.However, to achieve this state of bliss there are a view steps …
Earlier this month, Oracle has published a statement of direction (SOD) document for Siebel Open UI on the My Oracle Support portal. The document with the Id 1643468.1 lays out the features planned for release with Siebel CRM Innovation Pack …