Handling Save for multiple edit screens on child/grandchild objects

Handling Save for multiple edit screens on child/grandchild objects

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


Michael posted on Monday, March 31, 2008

I have am working on a program with the following BO heirarchy:

Project : BB
|-Jobs : BLB
  |-Job : BB
    |-Drawings : BLB
      |-Drawing : BB
        |-Revisions : BLB
        | |-Revision
        |-Materials : BLB
          |-Material : BB

In my main form I have a tree view control displaying a ProjectList : NameValueList. When a Project node is selected, the Project is loaded into the node's Tag property, and subnodes for Jobs, Drawings etc added to the node.

I am using the WinPart / Documents menu idea from the ProjectTracker example. I would like to have separate edit screens for Project, Jobs, Drawings, Revisions, and Materials. All of these screens could potentially be open at the same time. Obviously, the whole Project must be saved in each screen which returns a new Project object, so every other screen and the node's Tag in the tree view need to update their references.

Has anyone come up with an elegant solution to something like this?

Pawz replied on Wednesday, April 02, 2008

I have almost the exact same setup, treeview and everything - and I tried doing it your way first, but indeed you start running into some pretty serious issues with trying to keep the UI in sync when you save & start replacing object references.

So I backed up and thought about it some more, and realised that the problem was more in my object design than in the ui. I took it apart and set up the whole thing differently.

The main thing I missed was that (for me) many of the sub nodes operated completely independantly of each other - there was no business requirement to check, for example, data betewen materials. Which was the first indication that they probably shouldn't even BE in a BLB at all!

So now I've got seperate editable business objects for each node, and each one saves & updates its own node & child nodes. Clicking on the node loads up the winpart and the fully editable business object.

This has the very nice advantage of being able to have an unlimited size list of items in the treeview with very little overhead (all read-only lists / info objects), along with the LoadOnDemand which limits the number of records I need to load. Then the time consuming database access is limited to the single business object loading when the user requests it.

Another thing I found useful was to raise a custom event on the WinPart, an 'OnSave' event - and then add an eventhandler on the nodes as I create them, so that if (for example) the name of your material changes, the node can be notified & updated.

Michael replied on Thursday, April 03, 2008

Thanks Paws, that's an excellent post that has really got me thinking. I've got a bit of work ahead of me now to change my objects over, but I can see it'll be worth it.

Copyright (c) Marimer LLC