Plain Black, makers of WebGUI - C2: WebGUI::Product to WebGUI::Asset::Sku::Product

colink

Date: 4/11/2008 11:46 am · Subject: C2: WebGUI::Product to WebGUI::Asset::Sku::Product · Rating: 0

I've finished analyzing the WebGUI::Product and WebGUI::Operation::ProductManager and am ready to start moving that code over to WG::Asset::Sku::Product.

I think the original design is very functional and elegant; the only criticism I have is that it's hard to setup many similar items (like lots of t-shirts with different designs as individual products). Moving to Assets, where you can create prototypes, will fix that.

So my plan is just to add a screen to WG::Asset::Sku::Product that allows you to add parameters and options, and then another screen to configure variants. This last will initially only allow for enabling or disabling individual variants in a product, but eventually I can see where this would be the inventory management screen for that product.

Does anyone see any flaws or problems with this, or alternately, am I missing an opportunity to do something really good by following this route?

Back to Top

Rate [ | ]

JT

Date: 4/12/2008 2:08 pm · Subject: Re: C2: WebGUI::Product to WebGUI::Asset::Sku::Product · Rating: 0

The only thing I can think of is that if you store the variants as a property of the product in a JSON blob, then the variants will be versioned with the product, but more importantly, will cary with the product for the purposes of "prototyping" and "packaging".

Back to Top

Rate [ | ]

colink

Date: 4/12/2008 6:47 pm · Subject: Re: C2: WebGUI::Product to WebGUI::Asset::Sku::Product · Rating: 0

Those are two big advantages, but if variants were used for inventory control, then every inventory change would be another version in the db.

Well, unless we stored inventory someplace else. But then when the packages are imported you'd have to interface with the inventory system.

In AssetPackage I see the beginning of hooks for handling Asset collateral data. But that wouldn't help with Prototypes.

Back to Top

Rate [ | ]

JT

Date: 4/12/2008 8:50 pm · Subject: Re: C2: WebGUI::Product to WebGUI::Asset::Sku::Product · Rating: 0

And what is the problem with that? Plus you must be forgetting about the update method.

JT
On Apr 12, 2008, at 6:48 PM, <ckuskie@sterlink.net> wrote:

colink wrote:

Those are two big advantages, but if variants were used for inventory control, then every inventory change would be another version in the db.

Well, unless we stored inventory someplace else. But then when the packages are imported you'd have to interface with the inventory system.

In AssetPackage I see the beginning of hooks for handling Asset collateral data. But that wouldn't help with Prototypes.

http://www.plainblack.com/webgui/dev/discuss/c2-webguiproduct-to-webguiassetskuproduct/2

--

Plain Black, makers of WebGUI
http://plainblack.com

Back to Top

Rate [ | ]

colink

Date: 4/12/2008 10:30 pm · Subject: Re: C2: WebGUI::Product to WebGUI::Asset::Sku::Product · Rating: 0

On Saturday 12 April 2008, jt@plainblack.com wrote:
>
> And what is the problem with that? Plus you must be forgetting about the update method.

I did :)

Let me tell you what I'm thinking so you can tell me what's wrong
with it.

The current ProductManager has three tables (names are paraphrased):

parameters (stored per Product)
parameterOptions (stored per Product and parameter)
variations (stored per Product, parameter and parameterOption)

The number of variations is equal to the product of
parameters * parameterOptions. Each variation is tracked
independently because they can be individually enabled
and disabled. For example, you may have size (big and small)
and color (red and blue). If you sell out of small, red
widgets, you can disable that variation and not be hounded
by requests for things you can't deliver.

You probably already knew all that.

The parameters and parameterOptions map nicely into a set of hashed
arrays.

{
'size' => [
'big' => {
priceModifier => ??,
weightModifier => ??,
},
'small' => {
priceModifier => ??,
weightModifier => ??,
}
],
'color' => [
'red' => {
priceModifier => ??,
weightModifier => ??,
},
'blue' => {
priceModifier => ??,
weightModifier => ??,
}
],
}

variations need to be mapped differently:

{
'size:big;color:red' => {
enabled => 1,
identifier => 'guidGUIDguidGUIDguid00', #Used for inventory control
compositePriceModifier => sum of individual price modifiers,
compositeWeightModifier => sum of individual weight modifiers,
},

'size:big;color:blue' => {
enabled => 1,
identifier => 'guidGUIDguidGUIDguid01'
compositePriceModifier =>
compositeWeightModifier =>
},

'size:small;color:red' => {
enabled => 1,
identifier => 'guidGUIDguidGUIDguid10' #Used for inventory control
compositePriceModifier =>
compositeWeightModifier =>
},

'size:small;color:blue' => {
enabled => 1,
identifier => 'guidGUIDguidGUIDguid11' #Used for inventory control
compositePriceModifier =>
compositeWeightModifier =>
},
}

For generating inventory reports, I think it would be easier to keep
the inventory in a separate db, which is why I added the identifier
in the JSON. Otherwise, the inventory field could be right in
the JSON, too.

I think I've just convinced myself that it's fine.

Colin

Back to Top

Rate [ | ]

JT

Date: 4/13/2008 11:43 am · Subject: Re: C2: WebGUI::Product to WebGUI::Asset::Sku::Product · Rating: 0

I'm not suggesting that you store it all in the same field, I'm just suggesting that you use json blobs to store it. You could have one field for the parameters and options. Another that is the list of exclusions. Another that is the inventory list, etc. Then join those together in code at render time.

Back to Top

Rate [ | ]