Django-oscar: Documentation about variations

[elioscordo]

Hi guys,
thank you for the code! I have read other issues and conversations about variations. Maybe the doc could be improved with some more information about the variations / children out of the box.

For example, for clothing type we would:

Create attributes using the django admin site (color, size)
Generate children products with all the possible combinations
Change a bit the front end template to cover the two drop-downs
Allow the child product to have images (when the green it selected, show green)
right? is it right or I am totally out of track?

thanks,
elio

[maikhoepfel]

Hi Elio,

absolutely agree. It's hard for us to do good docs, because we know the framework so well and don't know which parts are confusing. Do you think you could contribute a few improvements in that section? Github's editor works well for doing docs pull requests.

Cheers,

Maik

[jakobholmelund]

Well, most of what he mentions, isn't even possible atm or am i missing something totally ?. So pretty hard to add it to the docs. IMO the dashboard part for variations is almost useless for more that 2-5 variants in it's current state.

[SalahAdDin]

I think that Oscar need a better documentation for variant products, for solve my question i had to search in StackOverflow and test some things, i lost three days trying to understand it (I know, i'm fool).

[khink]

In addition, i'd like to gain more insight when to use "Product attributes" vs. "Parent and child products". "Product color", for example, could be done in both ways.

Attributes seem have the advantage of being mixable, so for T-shirts you can have both "color" and "size" choices.

For my use case, which is a product with only color choice, i would pick "Parent and child products" to implement this, because i'm not sure the shop has an infinite supply of each color. We can manage stock records for individual child products, i don't think that's possible with attributes.

It would be nice to see this reasoning validated/corrected, and i'd be happy to make it a PR after.

[solarissmoke]

@khink my take on it is as follows:

• Use attributes where you are storing structured data for a product that you can use for search/filtering/display purposes. For example, if you are selling TVs you might have a "screen size" attribute on each TV, so that customers can filter for a particular screen size. For T-shirts, an attribute might be the material used (cotton, polyester etc).

• Use variants for things that modify the actual choice of product - i.e., if you need a different stock record for those variants (i.e., pricing or stock is different because of the choice). You can use attributes to define the differences between your variants, but a child product should only be used if it has its own stock/pricing.

[sasha0]

@solarissmoke shall we add couple of practical examples to the documentation or are we good?

[khink]

@sasha0 @solarissmoke I think the sandbox would benefit from an example using attributes without "child" products. It looks like currently only variants are implemented (for T-shirts sizes).

I'm wondering now if i was wrong in my interpretation of the functionality. I was under the impression that one could either set "Product Attributes" on the Product Class, or create "Variants" to the Product. Now i see that the sandbox contains Variants, which use Product Attributes. So it's not either/or. So maybe the documentation i submitted here is not entirely correct, and it certainly does not look complete to me.

[solarissmoke]

Attributes are precisely what differentiates variants - i.e., variants have have different attribute values that distinguish them from each other.

Let me try and add an example to the documentation and also the sandbox in the next few days.