Lists and Root/Child Objects

DougZ posted on Tuesday, November 21, 2006

If you have a Read-Only List object that is used when searching for an individual object in the list, are those individual objects always Child objects simply because they were found with the List? Here is my scenario:

In a web app, a user views a list of recruits (RecruitList), selects one (Recruit) to edit, and clicks "OK". This brings up a page with text boxes and such populated with the Recruit's data. The user edits the data as appropriate and clicks "Save". Is Recruit an Editable Child or an Editable Root?

Thanks,
Doug

DougZ replied on Tuesday, November 21, 2006

Yes, that makes sense. Now, let me give you a different scenario:

A user views a list of recruits (RecruitList) and selects one (Recruit) to edit. When he/she selects one, textboxes below the list (on the same form) are populated with data from the selected Recruit. The user edits the data in the textboxes and clicks "Save". The list refreshes to include the updated Recruit's data. In this case, from what I can tell, Recruit would be an Editable Child. Is that correct? Could RecruitList be a Read-Only List, or must it be an Editable Child List? On a side note, what is an EditableRootList (included in the Templates solution)?

Thanks,
Doug

guyroch replied on Tuesday, November 21, 2006

DougZ:
Could RecruitList be a Read-Only List, or must it be an Editable Child List?

Yes, RecruiteList can be a ReadOnlyList. In fact my scenario is using a ReadOnlyList and a root BusniessBase and not an Editable Child List.

The Objects responsibility are as follows:

ReadOnlyList (RecruitList)-> To allow the user to view and select 1 recruit object, and nothing else.

BusinessBase (Recruit) -> To allow the user to Edit/Add/Delete a given recruit object.

The workflow would be something like this...

1. Load RecruitList

2. Display RecruitList and allow the user to select one recruit

3. Call the Recruit.GetRecruit(Id) factory method with the selected recruit Id as a parameter. This will cause you Recruit object to load itself.

4. Display the editable Recruit object and allow the user to edit it.

5. Call the Recruit.Save() method on your Recruit object

6. Update your RecruitList by reloading it again. Theorically the only way you can _modify_ a ReadOnlyList is inside the DataPortal_Fetch method because Rocky provided some protection to enforce the _readonly_ in the ReadOnlyList. Look closely at the code sample and you'll notice a boolean propertry called 'Readonly' (I think) in the DataPortal_Fetch.

JoeFallon1 replied on Tuesday, November 21, 2006

DougZ:
Yes, that makes sense. Now, let me give you a different scenario:

A user views a list of recruits (RecruitList) and selects one (Recruit) to edit. When he/she selects one, textboxes below the list (on the same form) are populated with data from the selected Recruit. The user edits the data in the textboxes and clicks "Save". The list refreshes to include the updated Recruit's data. In this case, from what I can tell, Recruit would be an Editable Child. Is that correct? Could RecruitList be a Read-Only List, or must it be an Editable Child List? On a side note, what is an EditableRootList (included in the Templates solution)?

The workflow advice in the other thread is spot on.

You are mixing a few things together here.

The scenario should be:

A user views a Web page with a list of recruits. This is most likely a DataGrid bound directly to your ReadOnlyList. (Note the ReadOnlyList contains a bunch of RecruitInfo objects which are the data for each row.. They are NOT editable in any way. They are used for display.)

You should NOT have a "bunch of text boxes" on the same form as your datagrid. So your point about picking something from the list and having the text boxes filed in for editing is a mistake.

Your web page should have a Select button for each row of data. When the user clicks the button to Select the Recruit to edit you postback and trap the ID value and store it in Session and then re-direct to your edit page. The edit page grabs the ID from Session (if it does not find it then it re-directs to a message page or a main menu page.) Once you have the ID value you instantiate a Root level editable BO using the ID to Fetch that record from the DB. Your form is populated with data which the user edits. When the user clicks Save you can check if the BO IsValid or not. If not, list out the BrokenRules for the user so they can fix the page. If it IsValid then do the Save and let the user know it succeeded. then navigate them back to the menu or the datagrid.

Joe

Bayu replied on Wednesday, November 22, 2006

DougZ:

Yeah, I kind of switched to a Windows Forms environment for that second scenario. I can't really think of a scenario in a web app where I would use Editable Child List objects and/or Editable Child objects. Can you?

Invoices.

Just before submitting the invoice to the client you can allow the user of your web-app to 'clean up' the line-item descriptions (spell-checking, fixing typos, etc). For this view you would display the entire Invoice (EditableRoot) with all its lineitems (EditableChildren) in a grid-like control where the user can edit each lineitem description, commit the update and then submit the invoice.

Bayu

DougZ replied on Wednesday, November 22, 2006

Bayu,

There is a C# template in the latest Templates solution called EditableRootParent.cs. That's what I am referring to. Also, in the Templates solution, read-only objects are split into ReadOnlyChild.cs and ReadOnlyRoot.cs. Any thoughts?

This is what is confusing. The templates in the Templates solution aren't 100% in agreement with what's in the book and what's on OneLittleVictory. That's why I was wondering in the Business Object Stereotypes thread if there was a good, up-to-date source of clear and concise descriptions of the stereotypes. It would help those of us who are not yet CSLA literate understand how to use the framework and templates.

Thanks,
Doug

Bayu replied on Wednesday, November 22, 2006

DougZ:
Bayu,

There is a C# template in the latest Templates solution called EditableRootParent.cs. That's what I am referring to. Also, in the Templates solution, read-only objects are split into ReadOnlyChild.cs and ReadOnlyRoot.cs. Any thoughts?

This is what is confusing. The templates in the Templates solution aren't 100% in agreement with what's in the book and what's on OneLittleVictory. That's why I was wondering in the Business Object Stereotypes thread if there was a good, up-to-date source of clear and concise descriptions of the stereotypes. It would help those of us who are not yet CSLA literate understand how to use the framework and templates.

Thanks,
Doug

Ahhhhhhhhh,

Now I get your point. :-)

Well, I had a look:

EditableRoot vs EditableRootParent
- they are both EditableRoot objects and follow that stereo-type
- it's just that the ~Parent version already showcases how you would add a collection of EditableChildren
- so wrt EditableRoot, the EditableRootParent templates adds the following:
    - there is already a local variable in place (at the top)
    - there is a readonly property added that exposes your children
    - and IsValid and IsDirty have been extended to also take your child collection into account

Then ReadOnlyRoot vs ReadOnlyChild:
- they both follow the ReadOnlyBase stereotype
- but what is shown is the different loading patterns
- you see, only root objects (editable or not) are the ones to actually do the DB-CRUD
- so what you see in ReadOnlyRoot is that the object is populated using the classic dataportal_fetch method
- but that an EditableChild will never directly call the DB itself, its parent object (or grand-parent, etc) will invoke a factory method that accepts a datareader (this ultimately routes to the private Fetch method)

Does this clarify some?

Bayu