CSLA ver 3.6.3 with Old Code

CSLA ver 3.6.3 with Old Code

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


Vinodonly posted on Monday, June 29, 2009

I have now moved to CSLA Ver 3.6.3 but I have lot of code which is having the previous property declaraing syntax and other old code..

Compilation of project is giving me hundreds of warnings that PropertyHasChanged() is obsolete and CanReadProperty(bool) is obsolete.

I will change this code gradually to the newer version but my main concern is that will the code work or will fail..

These warnings are just to warn that I should change my code to the newer one but at least till that is done, it will work or not..

Overall the application seems working but I have not done thorough checking so I just wanted to be sure on this point..

RockfordLhotka replied on Monday, June 29, 2009

Those methods should continue to operate as they did in the past. I haven't changed the code in those methods for several versions.

In CSLA .NET 4.0 I intend on actually removing them, but in 3.6 and 3.7 they'll remain intact, with just warnings about the fact that they are obsolete.

JoeFallon1 replied on Monday, June 29, 2009

Vinodonly:

Compilation of project is giving me hundreds of warnings that PropertyHasChanged() is obsolete and CanReadProperty(bool) is obsolete.


Well, the methods will continue to work as they did in the past. But the whole reason they are obsolete is that they relied on the stack trace to get the property name and it was later discovered that this is not 100% reliable! So your app could act strangely (but it would have done this in the past too.)

So I strongly suggest fixing the code ASAP. At a minimum use the String property name overload.

Later you can upgrade to the newer syntax for Properties and get reduced code and no string names.

Joe

Vinodonly replied on Tuesday, June 30, 2009

Thanks for the replies and I will start working on changing my code..

I have few other queries in the same context..

1. In book it was written that if we call FieldManger.UpdateChildren from parent then we don't have to write updation code in child collection as that will be auto called.

My question is that if I have following object heirachy

Parent->Child1Collection -> Child1 -> Child2Col ->Child2

Then what I understand is that
I have to call FieldManger.UpdateChildren from 2 places i.e. from Parent and from Child1. Pls advs if this is correct.

2. Taking the same scenaior should ValidationRules.CheckRules will also be called from each BO i.e. Parent, Child2 and Child1

3. In ProjectTracker DataPortal_Create etc are defined as override except DataPortal_Fetch, What I understand is that all should be defined with override.

4. If we are using Managed fields then is it possible that ReadProperty Can be called from Child2 to read properties of Parent (as for some valdation code this is needed)

Vinodonly replied on Tuesday, June 30, 2009

Further to my previous msg, I checked the code in CSLA->ChildDataPortal.cs -> Update for updating child objects..

For a new object, Child_Insert is called otherwise Child_update is called.. But nowhere it is checking whether the object is dirty or not before calling the Child_Update...

Do we have to change the code in Child objects to chk whether object is dirty or not before saving object or am I missing something...

RockfordLhotka replied on Tuesday, June 30, 2009

The data portal doesn't check this, but BusinessListBase<>.Child_Update()
does check the IsDirty property of the child objects and only does an
insert/update if the child has been changed.

Rocky

-----Original Message-----
From: Vinodonly [mailto:cslanet@lhotka.net]
Sent: Tuesday, June 30, 2009 7:10 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] CSLA ver 3.6.3 with Old Code

Further to my previous msg, I checked the code in CSLA->ChildDataPortal.cs
-> Update for updating child objects..

For a new object, Child_Insert is called otherwise Child_update is called..
But nowhere it is checking whether the object is dirty or not before calling
the Child_Update...

Do we have to change the code in Child objects to chk whether object is
dirty or not before saving object or am I missing something...

Vinodonly replied on Tuesday, June 30, 2009

I'm thankful to both of you for clearing my doubts..

There is one point more..

Understood that readproperty is protected.. Is FieldManger also protected ?

Currently I'm using applicationcontext and read some properties of parent from GrandChild but I was wondering if there is any better way, specially when now we are having managed fields..

ajj3085 replied on Tuesday, June 30, 2009

Vinodonly:

1. In book it was written that if we call FieldManger.UpdateChildren from parent then we don't have to write updation code in child collection as that will be auto called.

My question is that if I have following object heirachy

Parent->Child1Collection -> Child1 -> Child2Col ->Child2

Then what I understand is that
I have to call FieldManger.UpdateChildren from 2 places i.e. from Parent and from Child1. Pls advs if this is correct.


That's correct.
Vinodonly:
2. Taking the same scenaior should ValidationRules.CheckRules will also be called from each BO i.e. Parent, Child2 and Child1


Yes, each instance that needs to check rules needs to call CheckRules... usually done on create or fetch, but you could call prior to saving too if there are rules that might not have been run, but that would be rare.

Vinodonly:
3. In ProjectTracker DataPortal_Create etc are defined as override except DataPortal_Fetch, What I understand is that all should be defined with override.


Well, the Create without parameters is pretty common, and most people will do creates without parameters. For fetch though, there is usually some criteria, so you almost never override the fetch, because its rare you'd fetch using a System.Object type. You'd probably want something more specific... Csla.SingleCriteria for example. In that case, just make the feth private.

Vinodonly:
4. If we are using Managed fields then is it possible that ReadProperty Can be called from Child2 to read properties of Parent (as for some valdation code this is needed)


I don't think this is the case. I believe ReadProperty is protected, so you'll need to expose the value to the child in some other way. Unless Parent and Child are of the same type.

Copyright (c) Marimer LLC