PropertyHasChanged Combo

glenntoy posted on Friday, May 05, 2006

In CSLA 1.1, MarkDirty() is called when a property has changed its value. In CSLA 2.0, PropertyHasChanged() performs 3 actions: a.) it executes the validations rules if there are any b.) calls MarkDirty() and c.) call OnPropertyChanged.

I've watched the CSLA 2.0 Part 2 in DNRTV, it seems in the project trakker sample in the property it calls Validation.CheckRules("PropertyName") and followed by the PropertyHasChanged() method. Isn't it redudant to call CheckRules() in the property when it is already called inside the PropertyHasChanged()?

I dont know if this is a typo error, just want to know the correct way of doing it. Maybe Rocky has a reason why he called the CheckRules("") w/ PropertyHasChanged().

Thanks,

Glenn

ajj3085 replied on Friday, May 05, 2006

I found this too, and it did end up running the rules twice. I'd think it shouldn't be in the book, but maybe it was a last minute change?

At any rate, I don't put a call to check rules explictly in any property setting and just call the PropertyHasChanged method.

glenntoy replied on Friday, May 05, 2006

I think your right, I guess Rocky ported the project trakker from 1.1 to 2.0 and forget to make the necessary changes in the part. Anyways, its not that big deal but again just making sure what is the right way of doing it.

In my case, I only called PropertyHasChanged() if the validation rules aren't complex. I have a scenario here that the business rule of a property has a computation and it affects other properties.. I explicitly called CheckRules() and MarkDirty() and OnPropertyChanged()

razorkai replied on Friday, May 05, 2006

Hi Glenn.

Can you be more specific? Not sure which Object or Property of Project Tracker you are referring to, so what I am about to type may be incorrect. If the property name in Validation.CheckRules("PropertyName") is the same as the property it is being called within then I agree that it is incorrect. However, if the property name is different then this is perfectly valid as it means that the property specified in Validation.CheckRules("PropertyName") has some validation rules that depend on the value of the property it is being called from. Hope that makes sense as it is hard to explain. Basically, PropertyHasChanged uses reflection to determine which property has changed and therefore only checks the rules for that property. So if we have one property that depends on another we have to force it to recheck the rules for the dependent property when the other changes.

HTH.

John.

glenntoy replied on Friday, May 05, 2006

Ooops.. sorry guys.. the project trakker Project.vb is okay. I got blinded with Started() and Ended() Properties in Project.vb .. Your right razorkai. What I mean is the same property name. Apologize for not being specific.. ;-)

Thanks razorkai and aiij????

RockfordLhotka replied on Friday, May 05, 2006

I think you misread what I was showing.

It is true that ProjectTracker has a couple properties where CheckRules() is called explicitly - but that is against a different property from the one being set. Specifically, the Started and Ended properties in Project do this.

The reason is that these two properties have a co-dependant validation rule (Started<=Ended). In order to get the ErrorProvider to show both properties in error due to the same rule violation, Started must call CheckRules("Ended") and Ended must call CheckRules("Started"). The rules for a given property are not being run twice. Instead, the rules for two different properties are being checked when either one changes.

Rocky