4.1 Custom validation rules: how do I access the previous value of the property?

4.1 Custom validation rules: how do I access the previous value of the property?

Old forum URL: forums.lhotka.net/forums/t/10129.aspx

JCardina posted on Friday, March 04, 2011

I'm just porting an old CSLA 1.x app over to 4.1 and am now at my first set of validation rules and I realized I used to make *heavy* use of the old value in a property in many areas, however in 4.1 it appears my custom rule is called *after* the property has already been changed, not immediately before changing.

In the old CSLA rules system it was trivially easy because we controlled it during the setting of the property right in the Set code so we could inspect the value of "value" and of the property and use the two for the rule.

In the 4.1 CSLA I have to make a custom rule for even the simplest of these scenarios.

Unfortunately I don't have access to the equivalent of the old property value only the newly changed property value.

This is a completely different take on things and wouldn't be a big deal if I could, in my custom validation rule, get access to the previous value of the property before it was set.

I have the CSLA 4 objects ebook and the rule section makes no mention of accessing prior values, is this possible?


ajj3085 replied on Friday, March 04, 2011

Before we get into any suggestions, does the rule always need the "last" value, or the what the value was at the time the object was loaded from the database.

JCardina replied on Friday, March 04, 2011

Hi Andy the last value.

I can think of many workarounds, I just wanted to know if it was an integral feature somehow that I'm missing because it seems like there would be common real world scenarios where you would need this.


tmg4340 replied on Friday, March 04, 2011

Ever since managed properties entered the picture, access to previous values (whether that be the most-recently-previous or the original value from the database) has been an issue.  Rocky made a design choice not to store previous values as part of his managed-property system, largely to keep the size of the object graph down.  There is also a potential issue when dealing with the undo stack as well, though that's easily solved by simply putting those values on the stack as well (with another attendant size increase).  The size issue, along with the simplification of the property-declaration system, won out.

Rocky typically points to a blog article (which escapes me now, but should be somewhat easy to find by searching the forums) showing a custom PropertyInfo implementation that saves previous values.  From what I remember, while it isn't entirely straightforward, it's not hard either.  I also know of one other user (whose name escapes me - sorry) who had developed a system for storing values only on changed properties, thus reducing the size issues.

As for the "commonality of need" - well, I don't think that comes up nearly as often as you might think.  Most folks who have asked for it on the forum do so for performance reasons - reducing property-change events on properties that don't really change, not updating DB fields that don't change, etc.  Finally, developing something to manage all the possibilities in a generic fashion is fairly non-trivial.  Some people want most-previously-recent value, others want original DB value, and others don't care (and likely wouldn't want to pay the space penalty either).


- Scott

JonnyBee replied on Saturday, March 05, 2011

Jason Bock wrote the article on CustomPropertyInfo and the code is also available from http://cslacontrib.codeplex.com.

His custom PropertyInfo will keep the original value (not the last value) but you should be able to alter it into saving the last value too.



JCardina replied on Saturday, March 05, 2011

As I said before I can think of *many* workarounds I just wanted to know if it's an integral feature already.  Thanks anyway.

Copyright (c) Marimer LLC