Custom PropertyInfo<T> derived classes?

Custom PropertyInfo<T> derived classes?

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


rsbaker0 posted on Thursday, October 30, 2008

I was curious if anyone is implementing their own derived classes from the new PropertyInfo<T> class for supporting managed fields?

Is there some reason I shouldn't do this? Child objects and lists will often be derivable from a foreign key relationship in the database, and I was thinking specifying the relationship in the PropertyInfo to allow for a centralized fetching infrastructure.

skagen00 replied on Thursday, October 30, 2008

Just to chime in and say that we are using derived PropertyInfos without any trouble.

JoeFallon1 replied on Thursday, October 30, 2008

I did it as an experiment to see how each PropertyInfo could track its current value as well as its original value. I found I also had to create a subclass for FieldData to implement the new IsDirty behavior which compares the current and orginal values and if they are the same then it is not dirty.

This means that each property could check its state for dirty and if you change it but then change it back it is no longer dirty. This is not true of CSLA BOs in general. Once you change them, they are always dirty. Even if you revert the value to its original value. This disregards the Undo feature of course since that does restore the total state. I am talking about UI changes to a field over time.

I thought I posted some sample code for this a while back.

You may want to search for:

Inherits FieldData(Of T)

Joe

 

rsbaker0 replied on Thursday, October 30, 2008

JoeFallon1:

I did it as an experiment to see how each PropertyInfo could track its current value as well as its original value. I found I also had to create a subclass for FieldData to implement the new IsDirty behavior which compares the current and orginal values and if they are the same then it is not dirty.

This means that each property could check its state for dirty and if you change it but then change it back it is no longer dirty.

Excellent! This will be very helpful.

I had rolled my own implementation for caching the original values when I started using CSLA 2.1, so even more of my infrastructure can be eliminated if I switch over to managed properties.

I make use of the "is it really dirty" concept for some fields in business rules, skipping the logic if the user didn't make a change to a field, and if they do and break the rule, they can "fix" it by putting the original value back.

Thanks.

JoeFallon1 replied on Thursday, October 30, 2008

Let me know if you want to see the sample code I wrote. It may or may not be helpful. You can decide.

Or if you find the posted version.

I am not really using it. I was just testing out the idea.

Joe

 

Copyright (c) Marimer LLC