LoadProperty(IPropertyInfo, object newValue) issue.
LoadProperty(IPropertyInfo, object newValue) issue.Old forum URL: forums.lhotka.net/forums/t/8300.aspx
rfcdejong posted on Thursday, January 07, 2010I bumped into a strange behaviour, since we use reflection to load properties we call the LoadProperty(IPropetyInfo, object newValue) overload. Which results into less code executed, but always a SetParent() etc called.
Currently we're using Csla version 184.108.40.206
Calling the method LoadProperty with a interface IPropertyInfo and a newValue (on line 1854) the ResetChildEditLevel(newValue) is always being called.
Calling the method LoadProperty with a generic PropertyInfo and a newValue (on line 1750) there is so much more done.
I would guess the generic is just an encapsulation around the non-generic for type safety.
Generic one does:
- compares the oldvalue with the newvalue and calls LoadPropertyValue generic;
- if the values are the same it skips the rest;
- it does eventhook binding transfer
- it checks the type of the propertyInfo and does something depending on the type:
Only IEditableBusinessObject and IEditableCollection call ResetChildEditLevel(newvalue)
The non-generic LoadProperty doesn't do checking and alwys calls ResetChildEditLevel.
rxelizondo replied on Thursday, January 07, 2010this is not the only place where the CSLA excibits different behaviour for Generic/NonGeneric method calls. Check out post:
Th second post makes the observation.
You even chimed in there :)
rfcdejong replied on Monday, January 11, 2010Can this be put on the issuelist?
- The non-generic should not always call ResetChildEditLevel
- The non-generic should evaluate the value
- The non-generic should transfer it's eventbindings.
rfcdejong replied on Friday, June 11, 2010
May i ask if this is solved in Csla 4.0 ?
I think the LoadProperty without a generic should work the same as a LoadProperty with a generic.
rfcdejong replied on Sunday, June 13, 2010
This will solve a issue where our root BO won't get notified when a 2 deep nested child is loaded and a "busy change" doesn't bubble up when LoadProperty is called. For now i just made sure the generic LoadProperty was called as a workaround.
RockfordLhotka replied on Thursday, June 24, 2010
My solution to this problem is to broaden a solution Jonny put in for another issue - the non-generic LoadProperty() method now just invokes the property setter, thus ensuring that the normal property set path is followed.
In BusinessBase this is done within a BypassPropertyChecks block, so it is a load, not a set.
The end result is that, in reality, the generic LoadProperty() method is the one that really does the work, and the non-generic LoadProperty() is just the long way to get there.
rfcdejong replied on Friday, June 25, 2010
dmnc replied on Monday, June 28, 2010
Do you now have to introduce setters for read-only properties and the non-generic LoadProperty()?
RockfordLhotka replied on Monday, June 28, 2010
For this change to work, yes.
I do this anyway - create a private setter for read-only properties. It makes coding inside the business class a lot more consistent.
I know - that's now how I did it in the 2008 book . But that was in 2008. Over the past couple years I've discovered that I like containing the LoadProperty() calls in a private setter much better than scattering LoadProperty() calls around the rest of the class.
Copyright (c) Marimer LLC