The best place to validate user input is at the source. If you can keep field validations in the browser, you can avoid unnecessary server requests and provide immediate user feedback while reducing the amount of bad data being submitted. This can be especially useful in the standard interactivity client because it can perform validations immediately, without waiting for the user to attempt to commit the record.
A Siebel form applet is an HTML form, and the controls are input elements on those forms. The HTML Attributes property of a Control object provides an opportunity to insert a JavaScript event to the input element.
For example, I recently implemented a query applet with a field validation on the Social Security Number control. To do so, I updated the HTML Attributes property of the control to
onkeyUp="if(/[^0-9\-]/.test(this.value) ){ alert('The Social Security Number field accepts only numeric data.'); this.value='';}"
The above validation intercepts the onkeyUp event of the input element, and uses a regular expression test to detect if the key pressed was any other besides a number or a hyphen. If an errant character is found, the applet displays a message and clears the control. This validation occurs entirely on the browser, but without adding any browser scripts to the applet.
Here's another example of a date validation on another control on the same applet:
onBlur="if(/^( *)((0[1-9]|[1-9]|1[012])[/](0[1-9]|[1-9]|[12][0-9]|3[01])[/](18|19|20)\d\d)( *)$/.test(this.value)||this.value==''){}else{alert('The Date of Birth field accepts date input in the M/D/YYYY or MM/DD/YYYY format');this.value='';}"
A somewhat more complex regular expression tests the format of a date. In this case, the expression doesn't test the input until the focus moves out of the field.
The HTML Attributes property of the Control object provides a clean, declarative approach for input validation.
Elastic List Applets @ IP 2015
-
Before you start wondering, I have not accidentally written 2016 as 2015 in
the title. If you are following the Siebel Updates then you would by now
know t...
8 years ago
Posts
11 comments:
Hi Jim,
nice post and creative solution, but I am a bit concerned that your business logic is in the presentation layer in browser script.
The UI is the most volatile layer in software, so changes to it (upgrade, new browser version or vendor or a shift to a different UI rendering engine such as ADF) can lead to a high level of effort to reimplement the logic.
IMHO, the Siebel business logic layer (BC, Field, Business Service) or OPA (Oracle Policy Automation) are more secure places to store validation logic.
have a nice day
@lex
Thanks for your input @lex.
Of course, different techniques are appropriate for different situations.
I think that this type of validation should really be thought of as suitable for formatting rather than business rules. For security and data integrity requirements, for example, the business layer would be more suitable. Lightweight validations such as these can be backed up on the business layer, much as business layer validations are often also enforced by database constraints.
The point of this type of validation is providing immediate user feedback to improve the user experience, which has the added benefit of reducing the number of unnecessary server calls. Both of these goals are more important with the SI client.
Because it is so easy to bypass client functionality, it should not be used for critical validations such as security controls or to prevent system crashes.
Although this technique is on the presentation layer, it is not "browser script" as we normally think of Siebel browser scripting. It is declarative, in the Applet Control object, and although it uses JavaScript events, these are attributes of the INPUT tag, not stand-alone scripts.
The HTML Attributes property is not deprecated in any current version of Siebel, and I doubt that HTML will be discontinued for rendering Siebel applets in the near future.
We can never tell what will happen in future releases, and upgrades always involve repository object property conflicts, but if any conflicts occur with HTML Attribute they will be relatively easy to resolve. The "logic" implemented with this technique is a simple regular expression test, and would therefore require very little effort to re-implement in the unlikely event that an upgrade problem occurs.
Hey Jim,
Very creative indeed. Thanks a lot for sharing this.
-Ryan
I agree with the prior commentary on creativity of this solution: it's a good one, and not one I've seen within a Siebel implementation before, and validation as close to the source of error is always the best to implement. There are just a couple of additional considerations which I think are worth considering:
1. Does the validation need to be applied for updates through other channels?
2. What is the strategy for business logic vs. UI (always a grey area...but worth considering - just because it can be done and is technically superior doesn't make it the most maintainable or supportable)?
As an aside, I'd probably implement the code a little differently also: such that it doesn't clear a users entry as soon as they hit an incorrect character: I imagine this could be both frustrating and/or confusing; but the approach itself has many merits if used with slightly different patterns. (now I'm starting to wonder whether this could be encapsulated in the web template or other reusable components?)
at the end of the day however, I wonder how much ultimately ie gained in avoiding the server round-trip: given it only really matters for exception conditions, and in more cases than not this is a minor time lag?
Hi Jim,
I am new in siebel
I have use form applet control's HTML Attributes property and put onkeyUp="alert('A key was released up')" in that and compile but it not working ,so please tell exact step by step way to do it
thanks
Hi Anonymous,
Can you please provide the following information:
* the applet Class
* the control HTML Type
* the control HTML Display Mode
Regards,
Jim
It seems to not work from Form Applet while in Query Mode.
It works great during Edit mode.
Is there a way to allow HTML Attributes in Query Mode?
Thanks!
Hi
this is very good post !!
Hi Jim,
I did exactly for OnBlur event.But it didn't worked.
I did it in Form applet of partner channel manager for phone number validation.
onBlur="if(/^(*)(\+){0,1}(\d(|-)){10,40}(*)$/.test(this.value)||this.value==''){}else{alert('Enter Valid Phone Format');this.value='';}" is the expression which i used to validate a phone number format.
If anything wrong in this expression please suggest me.
one more thing to add. I realised that this works only on few applet classes. e.g it worked on class "CSSSWEFrameMirrorAdd" but it did not work on class CSSFrameListFile and "CSSSWEFrame"
I don't know why but my HTML attributes aren't working on my Siebel Application.
I only want to restrict the lenght of a control to 10 chars and I tried to do this "maxlength=10" and it didn't work so I tried to do the same on this tutorial and it didn't work either.
Any help of why isn't working?
Post a Comment