NotUndoable Attribue on Field But I want to Use Properties with managed backing field

NotUndoable Attribue on Field But I want to Use Properties with managed backing field

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


Programmer1987 posted on Thursday, April 16, 2009

Hello ,

I want to put NotUndoable Attribute on some field

but I used properties with managed backing field to support silver light without writing extra code

so if I converted my properties to private backing fields

is it big problem when I use silver light

second , I think when using private backing field I can't use readProperty and LoadProperty Method

any more right ????? then I have to use the private field instead

ajj3085 replied on Thursday, April 16, 2009

You can use ReadProperty; that's an overload that takes the field value as a parameter. LoadProperty wouldn't be worthwhile (you're storing the property in the FieldDataManager and in your class).

I have several private fields because I also want the NotUndoable attribute.. perhaps Csla can add support such that a RegisterProperty overload can take an enum value indicating if the property should be undoable?

RockfordLhotka replied on Thursday, April 16, 2009

This is in the wishlist already - just haven't gotten to it yet.

ajj3085 replied on Thursday, April 16, 2009

Ah, well that's good. I guess I should have checked first. :-)

rsbaker0 replied on Thursday, April 16, 2009

RockfordLhotka:

This is in the wishlist already - just haven't gotten to it yet.

 

When you get around to it, can we please also have Nonserialized on managed fields? Thanks!

RockfordLhotka replied on Thursday, April 16, 2009

I am not sure that will be possible.

 

The reason is that, on the .NET side of things, we’re not manually serializing the list of property values. To serialize or not serialize them one by one would mean we couldn’t let .NET do the serialization normally.

 

I see the value proposition for not undoing managed fields. But if you want a field that isn’t serialized, just use a private backing field. You don’t lose anything by doing so, because the primary cost of using private backing fields is that your field won’t serialize automatically to Silverlight. And if you aren’t serializing it anyway, then you’ve given up the primary reason for using the private backing field in the first place.

 

Rocky

 

 

From: rsbaker0 [mailto:cslanet@lhotka.net]
Sent: Thursday, April 16, 2009 7:00 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] NotUndoable Attribue on Field But I want to Use Properties with managed backing field

 

RockfordLhotka:

This is in the wishlist already - just haven't gotten to it yet.

 

When you get around to it, can we please also have Nonserialized on managed fields? Thanks!



rsbaker0 replied on Friday, April 17, 2009

RockfordLhotka:

I am not sure that will be possible.

 The reason is that, on the .NET side of things, we’re not manually serializing the list of property values. To serialize or not serialize them one by one would mean we couldn’t let .NET do the serialization normally.

I was thinking, perhaps naively, that this could  -- generally speaking -- be implemented by simply discarding all such fields immediately before the FieldDataManager itself is serialized. (e.g. set them to the their default value or set their IFieldData value to null).

RockfordLhotka replied on Friday, April 17, 2009

Hmm, maybe. But then they’d need to be restored too, because (in the general case) the original object still remains in memory and usable after it has been serialized.

 

In fact, the local data portal configuration relies on that behavior to handle exceptions.

 

Rocky

 

 

From: rsbaker0 [mailto:cslanet@lhotka.net]
Sent: Friday, April 17, 2009 7:07 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: NotUndoable Attribue on Field But I want to Use Properties with managed backing field

 

RockfordLhotka:

I am not sure that will be possible.

 The reason is that, on the .NET side of things, we’re not manually serializing the list of property values. To serialize or not serialize them one by one would mean we couldn’t let .NET do the serialization normally.

I was thinking, perhaps naively, that this could  -- generally speaking -- be implemented by simply discarding all such fields immediately before the FieldDataManager itself is serialized. (e.g. set them to the their default value or set their IFieldData value to null).



rsbaker0 replied on Friday, April 17, 2009

RockfordLhotka:

Hmm, maybe. But then they’d need to be restored too, because (in the general case) the original object still remains in memory and usable after it has been serialized.

In fact, the local data portal configuration relies on that behavior to handle exceptions.

Yes, this wrinkle occurred to me as I was typing the original post.  I wonder if it would be possible to clone the FieldDataManager first, manipulate it, and have the clone be serialized so that the original FieldDataManager remains unmolested. Of course, this would be something you would do only if there was a least one such non-serialized field present.

 

You might think, what's the fuss about? But I've found the managed fields let me do many things I can't do with a private backing field. For example, it's possible to remove the value for any lazy loaded child object just with the property name. This is very handy for letting a user refresh a child list without refetching the entire object. Many times, though, such objects aren't editable so there is no point in sending them across when the object is saved.

Programmer1987 replied on Thursday, April 16, 2009

thanks a lot ,

so now I will use readProperty or private field directly to assign or get the value of the field

and about silverlight i have to write extra code as mentioned in CSLA book

right :) !!!

Copyright (c) Marimer LLC