Fellow CSLA users I have a headbraking problem,
I have a list with root objects wich have no child relations.
I want to bind this list to a grid (GridEX, Janus components).
I also want to be able to edit them, but not save them right away.
So the new EditableRootListBase isn't an option because it saves immidiatly.
Once an OK button is pressed, I want to save them.
It also depends on wheter the list with objects is valid if the OK button is Enabled or not.
How should I approach this situation?
It's keeping me busy for quite some time now.
Thanks in advance.
I wonder if you might be confused about what an EditableRootList (or EditableRootCollection as it was known in CSLA 1) really is. I think many here believe it to be a collection of Root objects. A collection can never contain Root objects. By its nature, it can only contain Children.
I'm also not sure what you mean by "not save them right away." I'm going to assume you mean that you want the whole "list of them" updated to the database in one UI operation and any edits that you make to individual members aren't persisted to the database individually.
If that's correct, you can change your EditableRootObjects be Switchable instead. Then use them as Children in this scenario and the EditableRootList will work just fine for you.
If you find the Switchable class too confusing, just create an Editable Child Class for them and use it in this context (Use Case), but continue to use the EditableRoot in those other Cases for which it is appropriate.
This is just another variation on the long-running theme here about designing objects based on their desired behavior. These Business "entities" behave one way for some Use Cases (when your original selection for implementation of EditableRootObject was correct) but quite differently when they are members of a list offered in the U.I.
It's pretty common in my experience to implement the same "business entity" (a Customer, Employee, Invoice, Timesheet, etc) with two or more CSLA types in the same application. This is very common in applications that provide lots of data entry and entity maintenance in the U.I. Apps that provide primarily processing activities (where the UI basically offers a place to select processing options and the opportunity to view processing output) don't usually require this "multiple-type" entity implementation.
Thanks for your reply Q Johnson.
Well your assumptions are correct thats exactly what i ment.
It's an interesting reply you wrote and very usefull.
But i'm a bit confused if you are reffering to EditableRootListBase or EditableRootList wich is a template.
FYI - from the eBook:
Behind the scenes the implementation of the “child” objects is different as well.
EditableRootListBase
is designed to contain editable root objects, rather than editable childobjects. In other words, it contains objects that inherit from
BusinessBase that do not callMarkAsChild()
in their constructor.
Joe
Copyright (c) Marimer LLC