Siebel IP14 – Enance Checkbox Behavior using Control Plugin-wrapper

A couple of previous posts have already demonstrated the good use of the IP14 Control Plugin-wrapper framework. Today again another simple use-case to demonstrate its potential.

In Open UI it turns out that selecting (or better changing) the value of a check box can be cumbersome. Especially if you want to quickly modify its value in a list applet. Form applets are just fine. Most important of all you need to quite correctly point your cursor on a relatively small area. Further the element containing the check box needs to have focus too, before you can change it.

Experimenting a bit I created a new control plugin-wrapper.


Of course starting-off some solid boiler plate code…!

Implementing the AttachPW event

The usual set-up of a PW requires the implementation of the AttachPW event. This event basically defines for what type of control such as a Dropdown, MVG or Link it should act upon. From the Bookshelf you can get the available controls including the constant value Siebel works with internally. For a Check box this appears to be “SWE_CTRL_CHECKBOX”.

The AttachPW conceptually acts like a bouncer in a bar. It decides if the control’s behavior will be overridden or not. The bouncer will return true, what will make the PW control events to execute. By returning false, well nothing will happen.

PWCheckboxFrom a development perspective, creating plugin-wrappers should be considered carefully, since they could have a widespread impact. A simple typo or a statement which throws an (unhandled) error could make your whole Siebel application could be negatively affected. Further, since the effect of a plugin-wrapper is more or less global, we should refrain from too heavy or process-expensive code.

The AttachPW event allows us to prevent execution of override code, in case this is either not required or would potentially not work at all given the context a certain control type is rendered within.

In this example, I just bluntly return “true”, it passes.

Implementing the ShowUI event

Next, the actual code. All within the ShowUI event.

To get the control’s element is simply done by using the GetEl() method on the object. Following that we need to find the gridcell in the list applet to which the Check box is tied. By testing whether we actually received a value element we select upwards the DOM the closest gridcell.

If that results in a valid element, we can attach a double-click even to it. Whether you use JQuery style or otherwise to bind an event to an element is irrelevant. I opted for JQuery style.

Finally, to make things not more complicated than necessary, I simply simulate and end-user click, again in JQuery style. For that one can use the “trigger” method.

The Out-of-the-box Siebel code will process the event further and “Bob’s you uncle”!


Enjoy and grab the full content here.

– Jeroen


Siebel IP14 – Plugin-wrapping your Text Area controls using popBox

In the “old” days of the high-interactivity client editing data captured within a text area was possible by means of a simple popup control. Clicking the ellipsis et voilá you got yourself a popup control to comfortably edit and save back your data.

With the introduction of the Open UI this feature ceased to exist. It was deemed by Siebel development staff unnecessary to have a like-for-like feature since browsers allow expansion of text area controls.  Well, this is not true for all browsers. Internet Explorer does not allow text area control expansion…

Personally – but I did get the same remark from different customers too – editing by means of a popup gives in many cases a better user experience. So, I started Googling for existing solutions out there in the wild. Pretty quickly I stumbled across popBox. A tiny JQuery based framework which does exactly that I was looking for. By injecting a bit of code associated with a TextArea control by simply clicking inside that same TextArea control it shows a more appealing “popBox” control. The popBox control displays again a re-sizable TextArea. The popBox comes at a default size, but of course that is adjustable. 

This is what it could look like:


And this is how it actually works:

Now, where did I start? First of all by trying to manually inject the sample code provided by the distributor of the code. That was quickly done, and functional. I just injected the code through the developer tools of my browser of choice. Just find any TextArea control in Siebel and identify it by its name attribute.


Next execute the JQuery selector followed by the popBox() JQuery function call.

popbox3Afterwards check what happened to the DOM. Hey, it did insert a couple of new <div>. Hooray!


So popBox did pass the initial test with flying colors. Well, flying colors? After clicking the control the popBox control displayed and was more or less functional. I say “more or less” because although the value entered in the popBox control was send back to the originating TextArea control, Siebel did not save it. Well, something to worry for at a later moment!

Next step, how to decently integrate it in Open UI. With the introduction of Innovation Pack 2014 “plug-in wrappers” have been introduced along. @lex spent some posts already explaining the backgrounds. Plugin-wrappers, which can be explained as the most narrow version of a physical renderer. The beauty is that you can attach a specific (control) plugin-wrapper and extent the behavior of the standard class for the given control, be it a plain text control, a dropdown or what have you more. And you can do so selectively using the “AttachPW” method of the plugin builder class.

Alright, it would be my first Plugin wrapper control – so it would not be bad to use some boilerplate code from @lex´s “Slider Control” example. I have to admit it was not that straight forward to get things working. First of all I was struggling to get the code loaded in the right order, such that the plugin base class would be available prior to extending it in the plugin wrapper renderer code.

Huh? Well, this line took me quite some time and collaboration with collegues:

define("siebel/MyPW", ["siebel/basepw"], function ()....

Until now I never had to use it as such, but in the define() statement you can pass other classes which are required. In this case “siebel/basepw”, the base plugin-wrapper class.

This is what the Bookshelf has to say about the Define method:

The Define method identifies the modules that Siebel Open UI uses to determine the location of the presentation model file or physical renderer file that Siebel Open UI must download to the client. It uses the following syntax:

define (module_name ,list_of_dependencies,function);

Defining the dependencies did the job.

The next challenge I faced was the fact that Siebel injects a lot of <span> throughout the DOM. But the moment it injects <span> elements is after any plugin wrapper code executes. That in itself should not have to be a big issue. But for the default popBox code it was. The popBox code is expecting that its sibling element is the TextArea element. But Siebel injects a <span> in between both just after the plugin wrapper code executes. Mmm… I changed the popBox code slightly for that matter. There might have been cleaner alternatives (I’m open for those).

Final challenge was to actually save back the data to Siebel. I more or less was able to re-use @lex code for that. What I needed to to was raise from the popBox code an “on close” event. That was pretty simple since I found the solution here. It meant just adding one more line of code to the popBox code.

Here is the final code I came up with:


Downloadable files can be grabbed here:

All together, the solution shows the power of the control plugin wrapper architecture again. Just a couple of lines of real code, leveraging what has already been developed by others. Enjoy!

– Jeroen