Hello all.

Using VS.Net 2005, Adapter. I'm struggling with a design approach for a simple pick list. In the windows UI it's a typical scenerio: two lists and two buttons between the lists - the "Copy>>" button and the "<<Remove" button. When you click the "Copy>>" button, selected items in the master list on the left are moved to the sub list on the right. When you click the "<<Remove" button, selected records on the sub list are removed.

In this case, I'm using this UI to create catalogues by choosing items from the master product list.

I'm using two EntityCollections: MasterListCollection and CatalogueDetailCollection. The CatalogueDetailCollection is prefetched within the CatalogueEntity.

Using this pick list interface, creating a CatalogueDetailCollection in a new CatalogueEntity is easy enough: just populate the new CatalogueDetailCollection with entities from the MasterListCollection and save the CatalogueEntity.

The problem comes when you use the pick list UI to modify an existing CatalogueDetailCollection. Now, there is a pre-existing number of entities in the CatalogueDetailCollection and the user and can add new records to the collection AND/OR remove existing records.

Now, the coding gets hairy. Theoretically, I should use UoW. but the user can add to and remove from the sub list over and over again. How do you use UoW to handle a situation wherein an existing record was REMOVED from the sub-list and then RE-ADDED back before the CatalogueEntity was saved? Ultimately, the sub-list contains a combination of new records and pre-existing records that the user may have bounced around before the SAVE button is finally clicked.

Sorry to have run on like this, but I don't know how to keep the code design simple on this. My guess is that I'm over-complicating the concept.

Thanks for any insight that you can provide me!

Jeff

Jeff wrote:

Sorry to have run on like this, but I don't know how to keep the code design simple on this. My guess is that I'm over-complicating the concept.

Yea. This sounds like a typical mover interface, as we call it here. I would not worry about binding as they move items left and right.

I would just move the items from list to list (probably client side). Once they press save, then I would itterate through the "selected" list and update the data accordingly.

BOb

I think there 2 approaches to handle this isue:

1- You may hold a collection of the CatalogueDetailCollection when loaded to the list (before any change made by the use), let the user change the lsit as he wishes without any action from your side, once he presses "Save" you would create a collection of the items currently found in the Catalogue list, and compare it with the List you hold from the begining, then you may find those which were add to the new list and weren't there in the old one (To Be inserted) , and those which vanished (To be deleted). And now you may use a Transaction, a UoW Or not.

2- The other approach (which I don't like very much although it might be easier and faster) is to Delete all the CatalogueDetail Entities related to this catalogue from the database, and just Insert all what you have in the list when the user presses Save. This approach is not valid for some business scenarios, for example if you have a timestamp (Date of creation for example) in the CatalogueDetail entities. This would be re-newed without a reason every time the user add new entities to the list.

Hmm... thanks for both responses. Considering how ubiquitous this type of interface is, you'd think that coding it would be easier. On my first posting, I failed to take into account the matter of referential integrity which might prevent existing entities from being dropped from the CatalogueDetailCollection. This only complicates the update process further.

I've added a bool flag called Applied to the source and target entities. The source and target records are visible in the relative source and target grid lists based on the Applied values. The "Copy>>" and "<<Remove" buttons simple change the Applied flag settings. Upon save, I perform an iterative update on each target entity based on whether the target entity is new and on the setting of the Applied flag.

It's verbose, but it works.

I chose this strategy thanks to your feedback.

Thanks again.

Jeff