SetParent and Parent property

ajj3085 posted on Thursday, January 10, 2008

Hi,

I'm looking at the Csla source, because I couldn't figure out why I couldn't see the SetParent method for a derived class.  The reason is that it's only marked as internal, not protected internal.  Is this intentional?

If it is, it seems to imply that only BOs contained within a BusinessListBase are children.  BOs contained directly by another BO are not.  That's fine if that's how things are intended to be.

I have the latter scenario, one BO directly contained by another BO.  I'm writing my factory create for the contained BO, and as part of it I want to set the parent (the BOs in question are Document and LineItems).   If this isn't how Csla is supported to work, that's fine, I'll work something else out. 

Thanks
Andy

ajj3085 replied on Thursday, January 10, 2008

I've cracked open the 2005 C# book.  Here's what the book says:

Page 120:  Table 3-7:  Child   An object that is contained by another business object.

So BLB and BB are both considered business objects I would think, since both implement IBusinessObject.

But page 120 seems to say something a bit different when discussing the parent property, saying "If a business object is a child of a collection, then it will maintain a reference to its parent."  So is that a description of how things should work, or how Csla actually works?

If page 120 is accurate, it seems that SetParent should be protected internal. 

JoeFallon1 replied on Thursday, January 10, 2008

I believe Rocky has always considered the Parent property to be associated with collections. Until now. I think he has added all kinds of support for Parent in the latest version that he is working on. I only skimmed the code but I think the idea is that he will be able to handle many scenarios within the context of the framework that are difficult for developers today. Like setting the parent and bubbling events.

Joe

 

ajj3085 replied on Thursday, January 10, 2008

Ya, it certainly seems as moving forward the Parent will be businessbase or businesslistbase.  I guess, given that, it would be ok for me to make SetParent protected internal.  I don't see a reason this would be a problem.  Certainly makes things a bit easier instead of needing to keep another reference in a different field.

ben replied on Friday, January 11, 2008

Hi,

I agree with you, Andy. I did this small change to our CSLA version some time ago because we had this problem you are describing. I know you don't like to change the CSLA ;-), so I vote to do the change to the general CSLA framework.

Ben.

ajj3085 replied on Friday, January 11, 2008

I don't like to, but I DO modify Csla.  For example, I adding in CanExecuteMethod support before Rocky made it part of the offical framework.

I think this change is coming in 3.5 anyway, but maybe such a change would be good enough to back port IMHO.  I ended up not doing this because the parent object I wanted to use was also a BO, and implementing ApplyEditChild and RemoveChild was something I didn't want to do... although now that I think about it, the BO is also (potentially) a collection as well (I'm implementing a Composite pattern).  Opps... guess I will make the change now :-)

Andy

RockfordLhotka replied on Friday, January 11, 2008

In 3.5 CSLA will have more robust child management features. This includes automatically setting a Parent property for a child (both BO and BLB child objects).

SetParent() will still be internal, but the Parent property will be set (and reset on deserialization) for both types of child object.