What is the best way to refresh an Editable Child List

What is the best way to refresh an Editable Child List

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

SethSpearman posted on Wednesday, July 01, 2009

Hello,

This question is about Winforms 2 application which is using CSLA 3.05.

I am trying to create a user control to which I am going to bind an Editable Child List (ECL).   The Parent object, an Editable Root object (ER), is going to be a property of the user control.  (Side question - or is it best to make JUST the ECL a property of the User Control rather than the whole ER???)

The first time the user control is opened against a particular ER the ECL will be empty so the control will call a Command object of the ER to object to populate the ECL with data using a INSERT INTO SELECT statement.  (But only if the ECL.Count=0)
 
What is the best practice for refreshing the ECL.  I was thinking of creating a Command object member into the ECL which would re-do the fetch.  Is that a common way to do it? Or is some other way recommended?

Just wondering about best-practice in this kind of situation.

Seth B Spearman

superkuton replied on Tuesday, July 07, 2009

Same here, I also need the technique in refreshing child lists.

I have an editable root object which has several read-only child lists. When another form creates a new child object, I need to "refresh" the read-only child lists of the parent object UI.

I think the parent object should only update/reload/redo-fetch  the affected child list, and not the whole object with all child lists, to lessen db/server/network load.

Please help.
Thanks.

tetranz replied on Tuesday, July 07, 2009

superkuton:
Same here, I also need the technique in refreshing child lists.

I have an editable root object which has several read-only child lists. When another form creates a new child object, I need to "refresh" the read-only child lists of the parent object UI.

I think the parent object should only update/reload/redo-fetch  the affected child list, and not the whole object with all child lists, to lessen db/server/network load.

Please help.
Thanks.


I'm not sure if that's quite the same question that Seth is asking but for this the best way is really to implement an observable pattern. I have done this and it works quite nicely but unfortunately it's a bit too tightly integrated into my other objects to publish here. I know that's frustrating to hear. I should make it more generic and write it up as a wiki article or something some time.

The basic idea is that I have a ChangeObserver class instantiated as a singleton. It has a method called Register. A ReadOnly list will "Register" with the ChangeObserver by calling this method, supplying a delegate and telling it what type of object it wants to listen for. The ChangeObserver maintains a Dictionary of delegates, keyed on the full string name of the class that the delegates are listening for.

When an Editable business object is saved, it calls the ChangeObserver's Notify method. Inserts and updates pass the updated business object itself but deletes only pass the unioq

tetranz replied on Tuesday, July 07, 2009

Oops. Finger trouble, I accidently hit the send. Just as well it wasn't DELETE * FROM ... before I wrote the WHERE Smile [:)]

Message continued.

superkuton:
Same here, I also need the technique in refreshing child lists.

I have an editable root object which has several read-only child lists. When another form creates a new child object, I need to "refresh" the read-only child lists of the parent object UI.

I think the parent object should only update/reload/redo-fetch  the affected child list, and not the whole object with all child lists, to lessen db/server/network load.

Please help.
Thanks.


I'm not sure if that's quite the same question that Seth is asking but for this the best way is really to implement an observer pattern. I have done this and it works quite nicely but unfortunately it's a bit too tightly integrated into my other objects to publish here. I know that's frustrating to hear. I should make it more generic and write it up as a wiki article or something some time.

The basic idea is that I have a ChangeObserver class instantiated as a singleton. It has a method called Register. A ReadOnly list will "Register" with the ChangeObserver by calling this method, supplying a delegate and telling it what type of object it wants to listen for. The ChangeObserver maintains a Dictionary of delegates, keyed on the full string name of the class that the delegates are listening for.

When an Editable business object is saved, it calls the ChangeObserver's Notify method. Inserts and updates pass the updated business object itself but deletes only pass the unique id. It also supplies a System.ComponentModel.ListChangedType.

The ReadOnly lists have a ChangeListener method that the delegate calls. It receives the business object or id (as an object of type Object) and the ListChangedType. It finds the appropriate readonly object in its list, updates it and raises a ListChanged events so the UI (usually a grid) will update.

ChangeObserver also has an Unregister which does the obvious thing. I implement Dispose in my lists which calls unregister. That's probably quite important to otherwise it effectively becomes a memory leak when you end up trying to notify lists that are no longer active. It probably stops them being garbage collected.

It all works quite nicely. It's also good for lists used in dropdowns etc. They "magically" change if the list is edited.

Cheers
Ross

BM2010 replied on Monday, September 14, 2009

Ross,

I have an operations monitor that QC testers use to manage a bank of test databases that reports real-time operations status plus history. Because any number of users in India, Philippines, and America can kick off operations, the consoles will need to update in real time... so this sounds perfect.

Did you ever generalize this? I would love to see some sample code on how this is accomplished.


Cheers!
Bill

RockfordLhotka replied on Monday, September 14, 2009

It should be noted that a child object can be directly retrieved through the data portal if that class implements a DataPortal_Fetch() method.

In other words, if you can detect the fact that your read-only cache is stale, you can just use the data portal to directly reload the list.

This works with read-only objects, because they don't really have a strict "child" concept.

It can work with editable objects too, as long as you manually call MarkAsChild() in the DataPortal_Fetch() method, and as long as you are using managed backing fields in the parent (otherwise the relative edit levels will get confused).

SethSpearman replied on Monday, September 14, 2009

Rocky,

Can you explain what you mean by "managed backing field"?

Seth

RockfordLhotka replied on Monday, September 14, 2009

Starting in CSLA .NET 3.5 there's the concept of a property declared with no private backing field - CSLA manages the property value for you. This is discussed in the 2008 book, where I compare and contrast the two field declaration techniques.

In general though, you should use the managed field syntax for child object references because of all the work CSLA does for you in that case.

Rocky





-----Original Message-----
From: "SethSpearman" [cslanet@lhotka.net]
Date: 09/14/2009 08:30 PM
To: "rocky@lhotka.net"
Subject: Re: [CSLA .NET] What is the best way to refresh an Editable Child List

Rocky,

Can you explain what you mean by "managed backing field"?

Seth



tetranz replied on Tuesday, September 15, 2009

BM2010:
Ross, I have an operations monitor that QC testers use to manage a bank of test databases that reports real-time operations status plus history. Because any number of users in India, Philippenes, and America can kick off operations, the consoles will need to update in real time... so this sounds perfect. Did you ever generalize this? I would love to see some sample code on how this is accomplished. Cheers! Bill


No, sorry Bill, I haven't really got it in a form that I can publish. It sounds like you're wanting to see changes that other users have made. That's a bigger problem because you need some of notification from the database that data has changed.

Ross

rsbaker0 replied on Wednesday, September 16, 2009

tetranz:
...It sounds like you're wanting to see changes that other users have made. That's a bigger problem because you need some of notification from the database that data has changed.

Ross


We have this issue also. Because of the way the application is designed, it is possible to have the same underlying data displayed and editable in multiple places on different MDI tabs.

The solution we have chosen for the time being is to auto-save the object being edited when you switch to another "context" (e.g. start editing another root object), and automatically refresh from the database when the next context is activated.

We generally lazy-load children, so an individual child can be forcibly refreshed just by setting it to null. The next property get will reload the child.

It works very well, at least in our test environment, but I agree there are issues with the database/network load caused by this.

Copyright (c) Marimer LLC