Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
validation in field
- Thread starter faxof
- Start date
What do you call "picture check" ?
In Notes you have two options to control field values.
One is to use the Translation Formula, and verify then length of the field, eventually cutting off the excess. The disadvantage of this method is that the user is not alerted to the change unless you display a message, which, in practice, you want to avoid doing until the document is getting saved.
The other option is to use the Java formula OnChange and do the same thing dynamically. The disadvantage here is a huge cost in performance as soon as the user is typing in the field (unless the document is being used in a browser, in which case performance is much better).
Pascal.
In Notes you have two options to control field values.
One is to use the Translation Formula, and verify then length of the field, eventually cutting off the excess. The disadvantage of this method is that the user is not alerted to the change unless you display a message, which, in practice, you want to avoid doing until the document is getting saved.
The other option is to use the Java formula OnChange and do the same thing dynamically. The disadvantage here is a huge cost in performance as soon as the user is typing in the field (unless the document is being used in a browser, in which case performance is much better).
Pascal.
- Thread starter
- #3
In short, no.
The Input Validation Formula is there for one thing, to allow the document to be saved. The result of an IV formula MUST be either TRUE or FALSE.
Never, ever try to modify a field value in an IV formula. This is considered bad programming practice. If you must set field values when the document is being saved, use the QuerySave or PostSave events - that is what they are for (or eventually a Computed for Display field formula). If you persist and do it, you may get lucky, of course, and it may work. But if you are not lucky then the result of the operation will be FALSE and your doc will not save.
You can, however, use the IV formula to check the field length and block saving while displaying a prompt to the user telling why. That will avoid performance problems and prevent the user from having to go through various amounts of OK clicking due to the translation formula executing on doc refresh.
Be sure to always check, in the IV formula, that the doc is being saved in addition to whatever else. Why ? Because of a bug that exists in Notes since before I was a Notes consultant (meaning before R3 at least - you know, last century ;-)). The bug is an issue with the time of formula execution.
Allow me to put my Instructor Hat on :
You know that, for an editable field only, there are three formula areas : Default, Translation and Validation.
The Default Formula is evaluated on document creation only. The Translation Formula is only evaluated on document refresh, and the Validation Formula is only evaluated on document save.
That is the theory. In truth, both the Translation AND Validation Formulas will evaluate on document refresh and save.
What does that mean ? Nothing for the Translation Formula, we don't generally care if it is checked on doc save. But for the Validation Formula, we do. Why so ? Because each time the VF comes up False, the user gets an error message from Notes (or a custom one if you put it in). Imagine what the user will think of your application if, just when he creates a new document, he gets an error message that such and such a field has not been filled. Well obviously not, since the document is brand-new and he hasn't had time to edit it yet.
This situation might be viewed as funny the first few times, but it gets sour rather quickly. So, to avoid it, always write your VFs like this :
That way, the VF will only kick in when the document is truly being saved, which will save the user from a measure of aggravation and dozens of button clicks.
There, I think I've said enough for now. Have fun !
Pascal.
The Input Validation Formula is there for one thing, to allow the document to be saved. The result of an IV formula MUST be either TRUE or FALSE.
Never, ever try to modify a field value in an IV formula. This is considered bad programming practice. If you must set field values when the document is being saved, use the QuerySave or PostSave events - that is what they are for (or eventually a Computed for Display field formula). If you persist and do it, you may get lucky, of course, and it may work. But if you are not lucky then the result of the operation will be FALSE and your doc will not save.
You can, however, use the IV formula to check the field length and block saving while displaying a prompt to the user telling why. That will avoid performance problems and prevent the user from having to go through various amounts of OK clicking due to the translation formula executing on doc refresh.
Be sure to always check, in the IV formula, that the doc is being saved in addition to whatever else. Why ? Because of a bug that exists in Notes since before I was a Notes consultant (meaning before R3 at least - you know, last century ;-)). The bug is an issue with the time of formula execution.
Allow me to put my Instructor Hat on :
You know that, for an editable field only, there are three formula areas : Default, Translation and Validation.
The Default Formula is evaluated on document creation only. The Translation Formula is only evaluated on document refresh, and the Validation Formula is only evaluated on document save.
That is the theory. In truth, both the Translation AND Validation Formulas will evaluate on document refresh and save.
What does that mean ? Nothing for the Translation Formula, we don't generally care if it is checked on doc save. But for the Validation Formula, we do. Why so ? Because each time the VF comes up False, the user gets an error message from Notes (or a custom one if you put it in). Imagine what the user will think of your application if, just when he creates a new document, he gets an error message that such and such a field has not been filled. Well obviously not, since the document is brand-new and he hasn't had time to edit it yet.
This situation might be viewed as funny the first few times, but it gets sour rather quickly. So, to avoid it, always write your VFs like this :
Code:
@IF(@ISDOCBEINGSAVED & ...That way, the VF will only kick in when the document is truly being saved, which will save the user from a measure of aggravation and dozens of button clicks.
There, I think I've said enough for now. Have fun !
Pascal.
- Thread starter
- #5
Use the Domino Designer Help database you should have locally with your Designer client. Check the functions @left, @right, @contains, @length and eventually @for.
Then check out these sites for development tutorials :
Pascal.
Then check out these sites for development tutorials :
Pascal.
- Status
Similar threads
- Locked
- Question