Validation Rules Not Updating

ward0093 posted on Thursday, March 01, 2007

I have a CUSTOMER object with a collection of ADDRESSES (or ADDRESS is the business base object)

I have a part of our system where I create a new customer... then I import address data inside the customer object like this:

cust = library.customer.newroot()

cust.importAddressData(thedata)

Inside the "ImportAddressData" I check to see if an Address Object exists, if not, i add one in this method. I then update each property on the address object where appropriate. However, the validation rules "String Required" does not get updating through the "PropertyHasChanged" function that is fired in the property SET portion.

therefore my customer object is InValid because this address object is InValid! What is going on or what am i doing wrong???

ward0093

ward0093 replied on Thursday, March 01, 2007

I forgot to add... when I run this inside my IDE on my dev machine... it works fine (address object is valid)... but all our test and prod. machines... the address is InValid for all properties (Property or String is Required).

ward0093

ward0093 replied on Friday, March 02, 2007

I fixed it but only by adding a ValidationRules.CheckRules() call after I updated all the address properties...

I shouldn't have to do that, should I? The properties should clear the broken rule after they are updated (through the PropertyHasChanged() call) correct?

ward0093

ward0093 replied on Friday, March 02, 2007

Really? I did not know you had to do that!

Do you have an example I can reference? is that in Rockys Book?

ward0093 replied on Friday, March 02, 2007

just found it in the project tracker... do I have to apply this attribute to ALL my properties in ALL my objects????

That is a lot of code!

Jimbo replied on Friday, March 02, 2007

If you application has dozens of classes like some of mine then you need a boy who is adept at doing the copy paste task.
I'm not the guru on this subject .. but it brought me to grief without doing what Rocky et al have strongly recommend.
Otherwise, you can dispense with PropertyHaschanged() and reflection by using explicit PropertyHasChanged("PropName") in your setters but this still requires the same amount of revisits to your code and can introduce typo bugs. Note even if you use literals in PropertyHasChanged("name") in the setters the attribute must also be applied to getters.
Im sure you will get a response from the masters on this issue.

JoeFallon1 replied on Friday, March 02, 2007

Jimbo:
Note even if you use literals in PropertyHasChanged("name") in the setters the attribute must also be applied to getters.

Are you sure about this?

I re-read some threads and Rocky's blog post and this was never mentioned.

Rocky specifically said that if you use on emthod or the other you are fine.

He never said what you just stated.

Can someone please confirm this?

Joe

mr_lasseter replied on Friday, March 02, 2007

This really depends on how/if you are implementing the CanReadProperty and CanWriteProperty. If you don't include the PropertyName in the call it to either method the code uses the stack trace to determine which property you are referring too.

If you are including the property name or you don't call the CanReadProperty in the setter then it doesn't make a difference.

Mike

Jimbo replied on Friday, March 02, 2007

In reference to joe's comment. I really meant that I don't know for sure if the attribute is still required on the getters when you use literal property names in the setters.
In reference to mr lasseter's comment. I think he means "CanWriteProperty in the setter" not "CanReadProperty in the setter"

Generally however CanReadProperty and CanWriteProperty are not the main issue here.

As an aside, I have not been able to implement either CanRead or CanWrite. Although object level authorization is mostly enough. The property read/write auth methods require a Custom Principal/Identity managed by csla ApplicationContext and so-far I have not had any success in casting our custom role security context into an principal object that will stick.

.

ajj3085 replied on Friday, March 02, 2007

If you are calling CanReadProperty without the literal property name, then yes you'll need the attribute. Personally I always enter the literal property name when I call CanReadProperty, CanWriteProperty and PropertyHasChanged. If you don't use the string literal for any one of those, you'll need the attribute (and at that point you should just remove the literal from the other method calls within that property as well).

What is your CslaAuthentication setting in your .config file? I think you'll need to use Csla if you want to use custom prinicpals and have them stick..

Jimbo replied on Friday, March 02, 2007

Andy,
hate to move the subject off the original point but...
Its been a few months since I played with this but I was using Csla authorization.
Creating the custom principal /identity on startup and assigning roles works fine; but when I get it back from csla ApplicationContext it resolves to the original Windows Principal - suggesting perhaps that the UI is on a different thread - although i was lead to beleive that a Windows app is single threaded.

ajj3085 replied on Friday, March 02, 2007

A windows app is by no means single threaded; I use threading quite a bit to keep the UI responsive on long running operations.

When you create the principal, are you assigning it to Csla.ApplicationContext.User? If you are, it should be sorting things out correctly, assuming you have the config file set to use Csla authentication. Otherwise it might be trying to restore the Windows principal... but I'm not sure if it actually does so or not..