How to create Varying No of Columns in Child Object

How to create Varying No of Columns in Child Object

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


Vinodonly posted on Wednesday, February 21, 2007

i have a table say color which is having color of garment, this is associated with a size table which define sizes. so let us say

Blue Color is having S, M, L, XL sizes.

Red Color is having 2X, 3X size

How i can  create Varying No of Columns in Child Object in this way(this is some thing like a cross tabular report)

RockfordLhotka replied on Wednesday, February 21, 2007

For read-write data this could be quite challenging (hard to hook up the rules). But for read-only data there are two reasonable solutions: use a DataTable or implement ICustomTypeDescriptor.

Either way, you have a dynamically shaped object that can describe, to data binding, what columns are in the object. The DataTable is able to change shape because it implements ICustomTypeDescriptor - so that interface is really at the root of the solution either way.

Vinodonly replied on Wednesday, February 21, 2007

Actually this is read write. and infact each size will be having more then one properties associate with it i.e. No of pcs etc.

So final way it will look like this

               Sizes

Color      

Blue      S   M   L   XL

            2   3   3   1 (No of pieces, plus one or more associated properties)..

Can you suggest any idea on how to implement this..

Mark replied on Wednesday, February 21, 2007

I know you want the cross-tab look/feel, but this seems like it should be implemented a bit differently.

I'd think you should a 'Garment' root object.  It would contain a child collection of 'AvailableColors'.  Each 'AvailableColor' child object would have an 'AvailableSizes' child collection that contains all the available sizes (plus whatever properties you need).

Garment

-> AvailableColors

   -> AvailableColor (Red/Blue/Green)

      -> AvailableSizes

         -> AvailableSize (S/M/L) along w/piece count, whatever

On the DB side, you'd have a Garment table, a master Color table, a master Size table, and then the tables that relate everything together (GarmetColor, ColorSize, or whatever you want to call them).

Now that design is somewhat complete, the only challenge left is to get this into a cross-tab look/feel (for UI display? reporting?).  For reporting, it's just a matter of writing the SQL (or using a report writer) to transform the data the way you want.  For UI display, it might be a bit more challenging depending on what controls you're using, but it should be doable.

Just my 2 cents...

Copyright (c) Marimer LLC