PropertyHasChanged calls MarkDirty() *after* checking rules??

PropertyHasChanged calls MarkDirty() *after* checking rules??

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


rsbaker0 posted on Thursday, September 18, 2008

I was wondering if there was a specific reason for implementing this like this in BusinessBase? I was trying to use the IsDirty value in a rule implementation, and object was still "clean" even though the property value had changed at the time the rule was executed.

    protected virtual void PropertyHasChanged(string propertyName)
    {
      ValidationRules.CheckRules(propertyName);
      MarkDirty(true);
      OnPropertyChanged(propertyName);
    }
 

ajj3085 replied on Thursday, September 18, 2008

Hmm.. I would think it should be the other way around.. especially since that's the reason MarkOld was called prior to calling DP_F.

RockfordLhotka replied on Friday, September 19, 2008

This would be a (subtle) breaking change from long-established behavior.

Is there a broad concencus that this should change?

RockfordLhotka replied on Friday, September 19, 2008

Actually, now that I look at current code, MarkDirty() is called first in 3.6. Probably in 3.5 as well, though I haven't checked there.

But this code changed quite a bit when I introduced the field manager, and added support for the WPF requirements around the PropertyChanged event.

JoeFallon1 replied on Friday, September 19, 2008

RockfordLhotka:

Actually, now that I look at current code, MarkDirty() is called first in 3.6. Probably in 3.5 as well, though I haven't checked there.

But this code changed quite a bit when I introduced the field manager, and added support for the WPF requirements around the PropertyChanged event.

Correct. 3.5 uses the "new" style.

3.0 did it the "old" way:

Protected Overridable Sub PropertyHasChanged(ByVal propertyName As String)
  ValidationRules.CheckRules(propertyName)
  MarkDirty(
True)
  OnPropertyChanged(propertyName)
End Sub

Joe

 

rsbaker0 replied on Friday, September 19, 2008

RockfordLhotka:

This would be a (subtle) breaking change from long-established behavior.

Is there a broad concencus that this should change?

I was just wondering why it was done this way -- I could certainly override the method in the derived class in CSLA 3.0.x and do it the other way, but I didn't want to cause any unintended side effects.

Even leaving it as is, I can work around it -- it just tripped me up briefly and I thought it seemed backwards, so I thought it was worth asking about.

 

RockfordLhotka replied on Friday, September 19, 2008

I can’t say why it is that way – obviously I thought it was backwards too when I did the 3.5+ code :)

 

Rocky

 

skagen00 replied on Friday, September 19, 2008

It indeed is a subtle change, but I think the issue he brought up does seem entirely valid and I'd rather deal with the ramifications of the change (I can't imagine this really affects me) and have it work "properly".

My 2 cents

ajj3085 replied on Friday, September 19, 2008

Ya.. and given that no one has hit an issue with the order of the call before, I would guess that for most people the change won't matter.

Copyright (c) Marimer LLC