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