Open UI: Mouseover Tool Tips - Part 1

Open UI: Mouseover Tool Tips - Part 2

Mouse over Tooltips was one of those unfortunately difficult features to implement in Siebel HI. List applets were one massive active control, which didn't expose mouse over events on the columns. Form applets were also littered with active controls, which left room for creative configuration around label controls, but on the whole it wasn't ideal.

With Open UI those road blocks are naturally not there anymore, so I set off to implement mouse over tooltips in Open UI and much to my surprise Open UI comes shipped with mouse over Tooltips out of the box!

1. Creating the Tooltip

Rather than implement our own Tooltip from scratch, we should leverage off community plugins that have already been built, and tested. Luckily Siebel includes qTip, a third party jQuery plugin as part of its distribution, but unluckily, it has an undesirable behaviour of displaying automatically, when the browser window is resized, so I suggest readers download and use qTip2.


2. Load qTip

To register this new tooltip JS, add a line in the custom_manifest.xml, to include it on application load.


3. Finding a handler

Instead of creating a physical render for every form and list applet in the application. It would be better if Tooltips could be rendered globally for every applet, which means that we face a similiar challenge that Alex at Siebel Essentials faced, when designing "See-Through Applets".

His challenge was to capture double clicks on every form applet globally, our challenge is to potentially load tooltips on every Applet globally.

Alex highlighted that while we could achieve this by modifying the vanilla ShowUI method of the "phyrenderer.js", he faced an eternal moral battle publicizing a how-to on modifying core siebel files, conveniently I do not work for Oracle, and do not face such a battle! But like Alex, I do have a moral obligation to steer readers from such a practice.

So are there any alternatives to modifying core vanilla framework files?

No doubt Siebel will provide official global handlers in future, but for the early Open UI pioneers, here are a couple of solutions.

a) Postload.js

Postload.js is fired on every view load. Readers of Siebel Essentials would be aware of this method, but isn't that also just another core vanilla file that we need to modify? Not necessarily.

The following line shows this undocumented part of the API, that Siebel uses to register the "OnPostload" function.
SiebelApp.EventManager.addListner( "postload", OnPostload, this );


The above command adds a new function to the list of functions that are called when SiebelApp.EventManager fires the "postload" event. We can copy this design without touching the core siebel files.

i) Copy the postload.js file, and rename it to GloablPostLoadRenderer.js

ii) Edit PostLoadRenderer.js, and rename the "SiebelAppFacade.Postload" to "SiebelAppFacade.PostLoadRenderer"

iii) Edit the custom_manifest.xml, and add the above JS file


To make it clear, “postload” is not equivelent to the “ShowUI” event of the Presentation Model. Firstly it is undocumented, “postload” only fires once per view load, while “ShowUI” fires once for every time an applet is rendered, "postload" also fires before "ShowUI", which is not suitable for attaching mouse over tooltips to Popup applets.

These differences are crucial to this design, as ideally we want the mouse over tooltips to display when the applets are rendered, and not before.

b) Over writing the ShowUI super class

This is trivially done by creating a custom object renderer, but how can this be done globally? As the title suggests, we can override the super class ShowUI method, but more accurately, we need to replace the superclass ShowUI method with our own method definition.

Before jumping into the solution, I must warn readers, that this code should not be blindly copied and pasted into production, you should understand what the code does, and the risks with its usage.

1) Modify the PhysicalRenderer class, and replace ShowUI with our own method


//Replace vanilla ShowUI with our own function

SiebelAppFacade.PhysicalRenderer.prototype.ShowUI=(function(){

To modify the "PhysicalRender" superclass globally, we need to alter its prototype as shown above.


//Cache the original function

var PRShowUI = SiebelAppFacade.PhysicalRenderer.prototype.ShowUI;
Rather than clobber or redefine the original ShowUI method, we cache the original function

//apply original ShowUI function, and add Pre/Post handlers
Global_PreShowUI.apply(this, arguments);
Next, we create a customised PreShowUI handler


PRShowUI.apply(this, arguments);




This line fires the original ShowUI method, that we cached earlier


Global_PostShowUI.apply(this, arguments);

Finally, we finish off with a custom PostShowUI handler

Heres what it looks like when put together, with some added logic to ensure we only perform this modification once.
//GlobalShowUI.js
//Modify PhysicalRenderer only if it hasnt been modified

if(typeof( SiebelAppFacade.PhysicalRenderer.prototype.bShowUIProxy ) === "undefined"){
    //Set flag to indicate that we have modified the PhysicalRenderer
    SiebelAppFacade.PhysicalRenderer.prototype.bShowUIProxy=true;
    //Replace vanilla ShowUI with our own function
    SiebelAppFacade.PhysicalRenderer.prototype.ShowUI=(function(){
        //Cache pointer to original function
        var PRShowUI = SiebelAppFacade.PhysicalRenderer.prototype.ShowUI;
        return function(){
            //apply original ShowUI function, and add Pre/Post handlers
            Global_PreShowUI.apply(this, arguments);
            PRShowUI.apply(this, arguments);
            Global_PostShowUI.apply(this, arguments);
        };
    }());  
}



//put Global Pre ShowUI logic here
function Global_PreShowUI(){
}


//put Global Post ShowUI logic here
function Global_PostShowUI(){
}




2) Load the above modification

Create a new JS file, and add it to the custom_manifest.xml.


We now have the capability to hook onto the ShowUI superclass, and have created two new artificial handlers PreShowUI, and PostShowUI.

The only caveat of loading it this way, is that the super classes are constructed before your customisations kick in, and there is a tiny window where vanilla methods will fire before the customisations can take effect. This means that the objects that load at the beginning of application start, such as the Application menus, will not have these handlers.

In the next article we will look into the design of an elegant Tooltip handler, and touch on an old favourite, using a script library.

Open UI: Mouseover Tool Tips - Part 2

The Harness

Siebel Development Lifecycle

Putting on my Siebel developer hat, I think to all the wonderfully painful hours spent, on all the small, yet numerous time consuming tasks that litter the life of a Siebel professional.

Compared to other software development tools, it is easy to over simply Siebel development by, using wizards, with a bit of drag and drop, sprinkling a few user properties here and there, we can build a basic application without a single line of code. But in the real world, things are much more complex, and it can take a multitude of steps, plus a bit (or a lot) of frustration to get a basic building block established

A simple example is testing Integration Objects. The following link from Siebel Bookshelf describes this process

http://docs.oracle.com/cd/E14004_01/books/EAI2/EAI2_IntObjs_CreatingMaint11.html

After creating your IO you must:

1. Create a Workflow
2. Create an EAI Siebel Adapter step with all the required inputs
3. Create an EAI XML Write to file step with required arguments
4. Launch a WF simulation session (and pray that that it starts)
5. Execute the WF steps
6. Open up windows explorer
7. Inspect the output file for the needed results

How about testing a Dot notation expression to retrieve a value from a SiebelMessage?

1. Create a Workflow
2. Create a property to store the result
3. Create an EAI Siebel Adapter step to query an IO
4. Create an Echo step and provide the Dot notation
5. Launch a WF simulation session
6. Execute the WF steps
7. Inspect watch window for the result

Another example, is testing eScript. A typical life cycle of a Siebel coder runs like this.

1. Find a suitable Event Handler or BS
2. Write code
3. Compile code
4. Re launch thick client
5. Trigger code
6. Inspect results
7. Goto step 2 and repeats until it works

Compiling, waiting, executing, and unit testing code iteratively is time consuming and also depressing.

These tasks provide a glimpse into the daily toils of a Siebel developer, and illustrates how many small tasks stack up, easily filling up a days work.

The Harness

Have you wondered if life can be better? Many developers over the years have come up with utilities that make life easier, tools that search the repository, tools that perform script or config reviews, tools that load LOVs, some experts have even come up with tools that generate browser script in 5 seconds!



The Harness, is the accumulation of years of pondering the Impossible in Siebel. It is a tool that aims to compliment Siebel Tools, and even fills in some of the shortfalls of the Siebel product.

The Harness comes packed with a suite of testing, troubleshooting and development capabilities rolled up into a UI with a modern interface. And where Siebel Tools is restricted to your local machine, the Harness was designed to be launched from any thick or thin client connection, which allows it to be useful in even in test and production environments.

The aim of The Harness is simple, to make every developer more productive.

Want to test some eScript that you just dream't of?

Just open up The Harness, start typing in the in-built code editor with, syntax highlighting, code indentation, and code hints, or choose from a defined set of templates, then click a button to execute the code and see the results immediately, without compiling.

Want to see what your newly created IO looks like in XML, Hierarchy or PS?

Just provide the IO name, Id, click a button, and see the preview in real time, with XML aware syntax highlighting.

Top 10 Features

1. Run 100% eScript without compiling
2. Run eScript locally, on the Server, or dispatch it to run on the Server Asynchronously without compiling
3. Simulate any BS any where in the Application with context!
4. Test Dot notation expression for any IO
5. Send/Recieve MQ messages on the fly
6. Generate XML/Hierachy/PropertySet output for any IO
7. Convert from XML to PS/Hierarchy/SiebelMessage on the fly
8. Run DOS commands from the browser
9. Advanced About View, with table information
10. Peek at runtime BusComp variables

In future articles, we'll go through the above list, and show how the Harness can make the lives of your developers more productive, and less depressing. We also take a look at the architecture behind the tool and delve into the design of its features.

For the time being, here's a sneak peek at one of the early alpha versions.

http://www.youtube.com/watch?v=hGYgHqT26rU

Note: The Harness was built for a client with custom integration requirements. It has since been expanded into a general developers tool.