Over the last month, since the general availability of the Siebel Innovation Pack 2012 (Patch 22.214.171.124 / 126.96.36.199), many posts and even entire new blogs have surfaced with more or less detailed information on the future user interface for Siebel CRM, namely Open UI.
Inspired by a very good article by Open UI development team member Chandan Das Gupta, I would like to take the opportunity of raised attentiveness in the Siebel community to discuss the role of browser scripting in Siebel Open UI.
With Siebel Open UI, developers have it in their hands to manipulate the browser UI in unprecedented depth. With this great opportunity to bend and hammer the UI to meet your user's perceived requirements comes great responsibility.
So let's reiterate what the role and reason of browser side scripting in enterprise class applications like Siebel CRM really is (and what it is not):
1. Never implement business logic in the UI layer
There is absolutely no justification for writing browser script that implements business logic. In Siebel CRM, we have business components, their fields and business services like Data Validation Manager to accomplish a centralized store for business logic.
For example, browser script is absolutely NOT the place to implement field level validation such as dates or email address validation etc.
If you really ask why, consider for a moment what Siebel CRM really is. It is always integrated with other systems and integration always happens on the business layer side (or database layer, when you use EIM). So you must implement business logic on the business layer to support the EAI interfaces. Let that be your reason number one for not writing business logic code in browser scripts.
2. Use UI layer scripting only to work with the UI
Browser scripting, be it in "traditional" Siebel clients or the brand new Open UI client, is intended to do whatever you think you need to do with the UI artifacts in the browser. Here are some (in my humble opinion) justified uses of browser-side scripting:
Conditionally modifying the appearance and behavior of forms, lists, fields and labels, etc. For example, changing the background color of a text box, changing column labels or hiding buttons can be accomplished easily with Open UI.
Displaying complex user dialogues. Sometimes, the server-side options for communicating with the user are not as bi-directional as we would like them. It should not be overdone, but a certain amount of custom dialogues can be implemented fairly easy with browser script. And I am not talking of a bunch of alert() calls in your script...
Enhance and enrich the user experience. With Open UI, we have full command over the physical renderer and therefore we have almost no limits when it comes to creating new user interface models such as carousels, hierarchy charts, draggable applets, etc. However, always ensure that these efforts have a solid business justification and are more than just showing off what you can do ;-)
3. Think twice but never code twice
Whenever you find you are copying code from one place to another, you should immediately take your hands off the keyboard and think again. Is it really worth to breach the re-usability mandate of good coding? Never forget, that in Siebel CRM, we have business services (which we can also call from the browser script). In addition, we can write browser script functions that we can call from various places.
4. What happens on the server stays on the server
I know the above post is a bit of a rant and may put off some people, for which I apologize up front should that be case. My intention was to provide some food for thought. Especially with a new framework such as Open UI there is a certain learning curve for all project team members. But just because we have a new UI framework, we should not forget our good manners and our responsibility we have as a programmer who has the privilege of extending an enterprise class software application.
have a nice day