Need a new flavor of BindableList class?

baltrinic posted on Sunday, June 11, 2006

I have read the currently running thread on switchable objects started by cmay.  I have a related but rather different problem I am trying to tackle.  What I seem to need is something like a bindable list class that works with editable objects that are not marked as children, but I want some advice from those more experience with CSLA and OOD.  Here is the scenario.

 

I am trying to implement a grid that behaves in a manner similar to an outlook style task list.  First the user can use a field chooser to define what properties of the task object they want to see in the grid.  Second the user can modify most of those properties right in the grid, and they can double click on a row in the grid and an editor window will appear allowing them to view and edit the entirety of the object.  Moreover, edit/undo/accept changes operates on a per task basis only.  The list is never edited as a single entity; movement off of a row commits the changes to that row automatically. 

 

This sounds to me like a need a new flavor of BindableList class that supports the following data-binding features:

1. Deleting exiting object immediately upon deletion from bound grid.
2. Adding new objects to persistent storage as soon as the newly added grid row loses focus.
3. Removing a newly added object from the collection and not saving it to persistent storage in the event of a CancelAdd action.
4. Saving changes to an existing object immediately upon loss of focus by the grid row to which it is bound. 

Has anything like this come up before?  Has anyone implemented something like this?  I would like to pattern my work after a time-tested solution or at least pick the brains of those more experienced than myself before charging off to re-invent the wheel.

 

Thanks in advance for any advice.

Fabio replied on Tuesday, June 13, 2006

Do you mean that you have something like a BOsBrotherhood without parent ?
Csla base classes don't contemplate this case. BindiableListBase is an editable transaction list (mean that save is in one transaction) and implement n-level undo.
You need some more simple.
You can create your own
[Serializable()]
public abstract class BoBrotherhood<T, C> :
      System.ComponentModel.BindingList<C>
    where T : BoBrotherhood<T, C>
    where C: IUDBusinessObject // you need an interface in your BusinessBase to access Save a Delete method
  {
    protected BoBrotherhood()
    {
      AllowEdit = true;
      AllowRemove = true;
      AllowNew = true;
    }
  ..........

1th you need to study System.ComponentModel.BindingList<C> or IBindingList
2th study how work the ReadOnlyListBase to implement the rest of the class.
3th IUDBusinessObject mean that you have two public methods in you BO: Save() that you have in BusinessBase<T> and Delete() to call DataPortal_DeleteSelf()
4th be carefully with Authorization and others important concept of Csla
Now we need to analize your points:
1) BindingList have a protected method that you can override
    protected override void RemoveItem(int index)
    {
      Items[index].Delete(); //  C is a IUDBusinessObject
      base.RemoveItem(index);
    }
2)I think two ways: public constructor in your bo,  "standar" factory of Csla. If you use factories you must implement something like this in your list hinerited from BoBrotherhood
    protected override object AddNewCore()
    {
      YourBO item = YourBO .NewYourBO ();
      Add(item);
      return item;
    }
To save the added BO you need to use the BindingSource events to save boBindingSource.Current and remeber that Current, may be, implement IUDBusinessObject.
Note: remeber UI is not the BO; don''t mix! don't think in databinding, csla is another story)
3) Where you think you need a CancelAdd ? In the UI you need a BindingSource so don't warry, when the CancelEdit method hare colled on a new bo the reference in the list is removed so you don't need to do anything.
4) The same of the end of point 2

Be carefully!
Bye.
Fabio.

kbaltrinic replied on Tuesday, June 13, 2006

Fabio,

Thanks for the tips.  This is generally the direction I was heading in.  I just wanted to confirm that this was indeed something not handled by the existing framework.  I am still a little incredulous that someone out there has not encountered this sort of requirement before and that there isn't already a standard solution.

If not, I guess I will post my solution here when I am done.  Is there a respository anywhere for CSLA extensions and classes and such where developers can post their code?

--Ken

xal replied on Tuesday, June 13, 2006

It sounds to me that you're mixing UI logic with business logic. Let me see if I get this straight. Your objects are persisted and loaded independently, right? so the collection is just there to support a list that only exists so that the users will get a grid. So you can just create a List(Of T) and handle the adding removing methods to do the saving / destroying of your objects. If you need to load a bunch of them at a time, you should then create the collection on the business objects' library and do the same thing as the other one, but you'd also implement a dataportal_fetch to load the wholebunch of root objects.
You could have a friend LoadObject that accepts a datareader as parameter and extracts the info that you can call from the collection's fetch or from the root's fetch.
That way you can load a whole bunch of root objects together or independently with little effort.


Andrés

Ronnie replied on Sunday, June 18, 2006

Good thread. I have a feeling the OP's situation is also the reason for many wanting to create switchable objects, simply to show a list of them on the UI. The suggestion I've seen is almost always to create a readonlylist with readonly children, and suddenly you have 2 quite similar objects to maintain. I know, I know, let the use case tell you what you need...

Xal, I think you suggest making a collection based on "List<T> where T : BusinessBase" instead of a collection based on any of the csla base classes, correct? I guess I have become a little blinded by clsa and trying to do everything with only csla, but I like that idea. I'm not sure I like having this UI support class in the domain layer, but I guess you could think of it more or less like a Repository for the editable root (more or less in line with how its described in domain driven design).