ValidationRules.CheckRules in the portal calls

Wbmstrmjb posted on Tuesday, June 30, 2009

Normally ValidationRules.CheckRules() is called from within Create and Fetch but this poses a problem for me and remoting since one of my rules checks information on the "client" (web server) and that information is not available on the "server" (application server). The firing of the rules throws an exception since the data isn't there.

One solution I thought of is to expose a method for calling ValidationRules.CheckRules on the BO and inside the static Get function, call it after it has loaded. Another option is to remove it all together from the Fetch since an object from the db should be valid.

Does anyone have experience with this scenario and what is the best practice to handle it? Thanks.

RockfordLhotka replied on Tuesday, June 30, 2009

The "correct" answer is to make the rules smarter.

If a rule can only run on the client (or server) then use ApplicationContext.ExecutionLocation in the rule to make sure the rule only really runs when it can actually run.

Wbmstrmjb replied on Wednesday, July 01, 2009

Thanks Rocky.

The reason for the "one sided" rule check is that a translation needs to be done on one of the properties. Maybe we are going about it wrong. Here is the scenario (cut down as to not bore you too bad):

We have values for status (like Purchased, Rejected, etc.) and these statuses are effectivedated in the database because they can be turned off, have their name modified, etc. So each status has both an ID (which is primary key, auto-inc) and a Key which is always the same for a given value. As an example:

ID KEY NAME STARTDT ENDDT
1 1 Purchased 06/01/09 06/20/09
2 2 Rejected 06/01/09
3 1 Bought 06/20/09

That is a basic example. So the ID is stored in the record of the actual item. One check needs to make sure the item is "Purchased" which really means has a Key of "1". But the record has the ID (either 1 or 3 depending on when it was made) in it. So we have a translator that carries the pairing of ID and Key and translates back and forth when needed. The translator is carried in the HttpApplication.Application cache. Obviously it does not exist on the Application server across the portal.

Is this a valid time to use your suggestion or are we doing something wrong?

Thanks.