Editable vs. Read-only child dilemma

Editable vs. Read-only child dilemma

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


SonOfPirate posted on Friday, January 19, 2007

I have a Project BO that has an Attachments child collection.  In my UI, the Project is displayed using a multi-tab layout with the Attachments shown on its own tab.  At the top of the tab is the data entry form used to add a new attachment to the project consisting of a textbox to enter the name to assign to the document, a combobox listing attachment "types" and a textbox/button pair to display the Open File Dialog (acts like the asp.net FileUpload control) and an Add button.  Clicking the button creates a new ProjectAttachment BO, sets the various properties and adds it to the Project's Attachments collection.  The list of attachments is updated to reflect the addition; however, the information is not persisted to the database until the user saves the changes.

My problem stems from the Type property of the Attachment object which is a Guid foreign-key reference to an AttachmentType object.  Because I have defined the ProjectAttachment class as an editable child, the Type property returns the guid value, not the actual object, so that this value is persisted to and retrieved from the database.  Unfortunately, when I display the collection in a grid, this column displays the guid value instead of the string name.

The way I would normally create such a listing would be to have a read-only child collection of read-only "Info" objects which basically flatten out the heirarchy by resolving all of the foreign keys in the query so that instead of returning the AttachmentType's guid value, it would return the name.  BUT, I can't do that here since I need to have an editable child.

I thought about doing a combination by having the editable child behave like a root and persist itself to the DB then have the read-only collection (or read-only children) refresh itself from the DB which would automatically add the new record to the display.  But, since we are not persisting the object when the Add button is clicked (it is added to the in-memory collection and persisted with the parent), this approach won't work.

I'm wondering if anyone else has come across this dilemma and how you have or would have dealt with the situation.

Thanks in advance.

 

Jimbo replied on Friday, January 19, 2007

It think that the model used for ProjectResouces in ProjectTracker will show you the way.  It uses a redundant field for the Name which is obtained from the resource object passed in to the Create method.  Another way to get the Name is to make the grid column a readonly ComboBox column and populate the combo with the "Type" collection; then set the  "DisplayMember"  to the Name property.  You can set the combobox column to hide the dropdown button.  The use of a combobox column is also shown in ProjectResouces (but editable in that case)

SonOfPirate replied on Friday, January 19, 2007

Yea, I failed to mention that there is already discussion about replacing/augmenting the Win Forms app under development with a Web app.  The web DropDownList doesn't offer the same features.  I'd hate to be tied to a particular UI implementation.  And, if I was to use a disabled ComboBox/DropDownList, it would only lead to inquiries as to under what conditions is it enabled.

If this is the only option, then I can certainly find a way to make it work.  I'm just hoping there are other ideas/suggestions out there.

 

Copyright (c) Marimer LLC