EditableRoot Object

gdk9am posted on Sunday, March 18, 2007

Is it correct that EditableRoot can contain the following  collections ?

1. EditableRootListBase

2. BusinessListBase

3. ReadOnlyListBase

I am using a tree view of business objects in UI

For example

Company (EditableRoot object)

    Branch (EditableRoot)

        Resource (EditableRoot)

Company will contain a list of Branches in EditableRootListBase collection

Branch will contain a list of resources in EditableRootListBase collection

Company, Branch, Resource are all EditableRoot objects since they can be saved independently.

Is this valid ?

 

 

Brian Criswell replied on Sunday, March 18, 2007

Remember that root objects are typically not contained in other root objects.  A root object is the single object that is sent to the DataPortal (along with all of its contained child objects), representing a single "transaction."  You also do not want to load all the root objects at once as that loads more data over the wire than a user will edit.

It sounds like the objects for the TreeView are used to then load objects for editing.  If that is the case, I would recommend getting the list of objects for the TreeView as read-only.  So your objects would only have an id and a display name. Like this:
CompanyInfo
    BranchInfoList contains a list of BranchInfo objects
       ResourceInfoList contains a list of ResourceInfo objects

Clicking on one of those nodes in the tree would use the id and object type to load the corresponding Company, Branch or Resource object for editing.

Bayu replied on Monday, March 19, 2007

Hi,

I think Brian already indicated a key design decision. In addition I would like to share some of my experience with working with trees:

- following Brian you would arrive at the following:
    - lean data structure for loading the whole tree model, which is good
    - per-object editing of properties of particular 'nodes', which is also good

But I guess you chose for editable lists since you also want to enable the user to alter the \structure\ of the tree, i.e. by dragging branches/resources from one parent to the next. For this purpose I also once made my tree fully editable  by using all editable roots and lists. Performance was terribly slow, so we reconsidered it. We felt we were pretty much designing after behavior, but soon we realized that actually we were still too data-centric. See, the behavior here is JUST a change of parent-ids. You don't need a tree full of editable objects for that!

Hence the following:
- we created an empty (!) editable root list TreeUpdateList that contains editable roots of type TreeUpdate
- in the drag-drop event handler we append the corresponding structure-update to this list
- we used an enum to indicate which kind of object was moved (Company/Brand/Resource)
- depending on this the dp_method executed the right SQL (or stored proc, don't remember) that reflects the changed parent-id in the DB
- it is important to note that the ordering of TreeUpdates should be preserved to make it work correctly, so TreeUpdateList is append-only (a queue if you will)

This way all 'behaviors' were supported while still having a performant UI.

Regards,
Bayu