>Now to avoid the above, an idea that I got was to put the valid() call straight in the table using Field Validation Rule. Now the problem is that the actual validation is done in the BO.methods(), if I use a BO call here then I guess browsing through such tables outside the app will become impossible.

You usually don't have to duplicate the same "validation rules" in the .Valid() events AND in the "save" routine.

The "rule" that you would normally code in the "save" is: Is a required field missing ?

If a field is optional, there is no need to "validate" it in "save" because the .Valid() would have handled it (had it been entered in the first place).

If the field is "required" and "missing" in the "save", then you just send Focus back to the missing field and the .Valid() will then pick up on it; a general message like "Field is required" is all that is necessary for any missing field ... the field that now has Focus is the one in error. (From a framework point of view, you simply return the field name; the framework interprets this as a missing field or a field in error and sets the focus).

Is summary, "save" handles "missing" fields; .Valid() takes care of all the "validations" .... when performing "field level validation".

If there are "cross-field validations", these can be handled in the "save" but can also be enforced by dictating a strict tabbing order in the UI by not allowing one to leave a particular field or to "arrive" (.When()) at some other field if a "previous" field(s) met some sort of condition. The User is always allowed to "back up" in the tab order to undo a set of conditions that might otherwise lead nowhere. As a user moved along, certain fields might also be disabled based on the present context; this eliminates having to "surprise" the User at "save" time by clearing or invalidating fields that are invalid within the context that the User chose (eg. male vs female; labor vs material; etc).