Dynamic Root List and Dynamic Root - where's the "Parent"?

Dynamic Root List and Dynamic Root - where's the "Parent"?

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

tiago posted on Saturday, July 02, 2011

Dynamic Root List is a stereotype on its own while Dynamic Root is just a special Editable Root. Of course the later is part of a collection... sort of. Take the Parent property. You would expect every collection member to hold a reference to its parent collection on the Parent property. This doesn't happen on Dynamic Root. Quoting the documentation

public Csla.Core.IParent Parent { get; }
    Member of Csla.Core.BusinessBase

Provide access to the parent reference for use in child object code.

This value will be Nothing [null for you and me] for root objects.

When I want to implement a rule like NoDuplicates - a pretty standard rule for data you edit in a grid - I have to implement my own ParentCollection property and take great care to make sure it is filled in all the right places.

Is's done and CslaGenFork will have an option to do it for you.


is there some smart way of Csla doing it for us?

After all this is a special case and the Editable Root object is clearly defined as an iitem of a DynamicBindingList

public class DocClassEditColl : DynamicBindingListBase<DocClassEdit>

ajj3085 replied on Tuesday, July 05, 2011

I think you're misunderstanding what DynanicRootList is meant to be used for.  Its sole use case is to support editing in a grid, where edits are saved as each row's changes is committed by databinding.

The root objects contained within the list are competely unaware they are in a list, as editing one has no bearing on editing the other.

If you want that concept, use a normal BusinessListBase and change your roots to child objects.

Alternately, you can check the rule by hitting the db in the rule (say by executing a CheckForDupsCommand objet), or just throwing an exception on in the DP methods.

tiago replied on Tuesday, July 05, 2011

On further investigation, the "child" EditableRoot objects are indeed aware of the parent. And the rule works ncely.

tiago replied on Tuesday, July 05, 2011

In fact, the "child" EditableRoot objects are aware of the Parent only after they are loaded. So the NoDuplicates rule won't comnplain about duplicates just after loading. When you start editing them, they know about the parent allright. Can you fix this Rocky?

tiago replied on Thursday, July 07, 2011


Is there any chance of fixing the "null parent on fecth" issue?

ajj3085 replied on Saturday, July 16, 2011

So you have a child, and its parent is null until after its created?  The parent won't (and can't) be set until after its added to the collection, so I don't think this will change.

If you have a rule that requires a parent, what I would do is on the BO that contains the collection object, in your DP_F (or child_fetch) after the entire collection is loaded, loop and ask each child to check its rules.  You can add an internal method to the child which will call CheckRules.

tiago replied on Saturday, July 16, 2011

Hi Andy,

That's exactly what am asking Rocky: set the Parent when the object is added to the collection - kind'a overrite the Add() method.

CslaGenFork has an option to set a property ParentList that works beautifuly and allows me to mark to apply the rule NoDuplicates as soon as I load (fetch) the collection.

Using the Parent property only marks duplicates as errors when I try to change them, after fetching.

BTW this is a special kind of collection DynamicRootList that is made of EditableRoot objects. According to the documentation,, as objects are root objects, I was expecting the object to have a NULL Parent property. Then I found out that, after all the collection is fetched, they have a proper Parent property. Either their Parent property should always be null or it should be set from the momemt the object is added to the collection. Like it is, it's non-sense (or a bug).


JonnyBee replied on Sunday, July 17, 2011

In terms of a NoDuplicate rule I'd rather recommend to do a lookup in the database.

Would you always "assume" to have ALL items from that table loaded into memory?

I'm not sure of what it is that is the real bug here:

  1. Should the EditableRoot obects have a Parent at all in the DynamicRootList? 
  2. Should Parent be set when new items are added to the DynamicRootList?



tiago replied on Monday, July 18, 2011

Hi Jonny,

1) The NoDuplicates rule is very interesting because you can use on all of the elements of a given collection. That collection  may be not the same "collection" you find in a database table. Say Brands & Models. You cannot repeat a model for a given brand but nothings stops Philips and Siemens to name a model with the same name. Here the collection is the brands of a model. On the other hand, on the collection of brands, there can be no duplicates - no two Siemens brands. In this case, the collection is the database table.

BTW I made a version the follows the errormessagedelegate just like the othe rule of CslaContrib I' like to publish there

2) The issue... you can choose the issue, according to the chosen rule :)

A) If the CSLA rule is root objects always have a NULL Parent property, then that rule should apply to EditableRoot objects created by a DynamicRootList and EditableRoot object should always have a NULL Parent property, no matter they are child of a DynamicRootList.

B) If the CSLA rule is objects created by other object should have a properly filled Parent propery, then the paretn property should be set as soon as the object is created. Right now what is happening is that the Parent property is set only after the creation of all EditableRoot objects child of a DyamicRootList.

Copyright (c) Marimer LLC