flattening business list?

ajj3085 posted on Friday, October 06, 2006

HI,

I have a business list which can contain different types of objects. Some of the object contain other objects as well. All of these object implement a common interface.

I would like to create a view which 'flattens' the collection. Each top level object has a Position (an int) and the list must be sorted according to this property. However, if an object contains other objects, those must be displayed before the next root object.

For example:

simple4
simple1
complex3
sub1
sub2
simple2

Should display as:

simple1
simple2
complex3
sub1
sub2
simple4

Has anyone done something simiilar to this? Oh, the list also has to support adding and removing items as well..

Brian Criswell replied on Friday, October 06, 2006

Wow, what is this for? This is doable, but I think there may be a lot of work keeping track of the order of things, readjusting the list when the underlying items change and delegating add and remove calls. The ObjectListView was a lot of work, and it only has to keep track of one kind of item.

ajj3085 replied on Friday, October 06, 2006

This is to support a collection of Line items.

There's a simple line item, which is just a single row on the grid, with a price, part number etc.

We also sell bundles. The bundle item is like a simple line item, but contains a list of sub line items which make up the bundle. You can't edit, add or remove sub items.

Then the user can group Simple line items. What ends up happening is that the Group item has a collection of sub items as well. The sub items in this can be edited and can be removed or moved out of the group.

There's some other line items as well, but these function more or less like the Simple line item (except they allow different properties to be modified or not modified).

Andy

Brian Criswell replied on Friday, October 06, 2006

This might sound mad, but have you considered writing a series of custom controls for this? Your list could plug in to a custom control that was a 1 column table layout panel. For each item in the list, you create a user control corresponding to the type of line item and place it into a new row in the correct place in the table layout panel. The controls for items with subitems would behave in a similar manner. The AutoSize property of the panels would keep everything laid out properly and simplify the adding and removing of items. It could actually turn out to be simpler than creating this view.

ajj3085 replied on Monday, October 09, 2006

Yes, but there are some concerns. One is the time it would take, as its just me doing everything from database to UI. Second, i'd have to write a new control for each new kind of line item. Although I don't expect more, its always a possiblity.

As a side note, I'm trying to figure out if any patterns help me here. So far, no luck.

I think what I'll do is create a DisplayLineItem, which will wrap any kind of line item. It will have a collection of sub items no matter what the underlying type is.. and I'll have the grid in a hierarchy mode to show the sub items. Not ideal, but the custom binding list is proving challenging to write.

Andy

malloc1024 replied on Monday, October 09, 2006

I could be missing something but you could try to use a façade. You could wrap the objects in a single class to flatten the hierarchy.

ajj3085 replied on Tuesday, October 10, 2006

Malloc,

I think that's the route I ended up going down by creating the DisplayLineItems binding list. I did complete this, and so far it seems to work, although I have to add a bit to the UI to actually test things out.

Or are you suggesting that this 'flattened' list be the only list exposed by the UI and the various kinds of groups are done totally behind the scenes? I hadn't thought about that..

My only concern is that the UI does need to know a little about the type of line item, so that it can enable / disable items in the grid's context menu (like delete, move up, etc).

Andy

david.wendelken replied on Tuesday, October 10, 2006

I had a similar problem to solve, in that I had 15 different transactions to support, each of which used a somewhat different subset of properties.

I created an object / object collection class that included the super-set (union) of all the properties (plus a transaction type property).

I then added a boolean property for each one of them called Show<property>.

So, I would have Name and ShowName, etc. The Show properties are used by the UI to hide the inappropriate properties for any given record.

I used a DataList to format it and it's working very nicely.

I'm sure there must be a better way to do it, but it's working!

david.wendelken replied on Tuesday, October 10, 2006

Forgot to add some points about using the DataList.

I used the HeaderTemplate to start a <table> and the FooterTemplate to close it off </table>.

Each ItemTemplate and EditItemTemplate were composed of one or more table rows.

ajj3085 replied on Tuesday, October 10, 2006

Yes, this is what I think I'll end up doing. Glad to hear its not that crazy. Since I've been reading Head First Design Patterns during lunch, this sounds like the adapter or facade pattern..

Of course this leads to my next question: Does this adapter / facade belong to the UI or business layer?

ajj3085 replied on Tuesday, October 10, 2006

Ok, so the more I think about this, the more I think that the flat collection class and a special 'display' LineItem class should be all that's visible to the UI.

The GroupLineItem, BundleLineItem, SimpleLineItem, etc. would all be hidden, used only by the business layer internally. My current LineItemFactory would return instances of LineItem (which is the 'view' class) instead of ILineItem which is being returned now.

LineItem would have additional properties; IsDeletable, IsMovable, etc. Any type of UI would likely need to know these. LineItem itself would just encapsulate the actual line item class and delegate most of the responsibility to the encapsulated object. It would figure out IsMovable etc. by looking at the exact class type.

So is this a good idea, or am I heading to a bad place with this design?

Thanks
Andy