Hi
Sorry about the lenght of the email below (just read the summary if
you like). I have been working a little on the e-commerce module, I
am trying to add product attributes so that people can buy more than
just shirts, books and shoes (e.g. XL T-shirts, yellow shoes, OR hard-
cover version book), but I feel a bit lost. Silverman came up with
some super ideas, but we would dearly like to have some further input
before proceeding. We need an e-commerce module that works from one to
100,000 products so it is important to think through it carefully
before proceeding.
++++++++++++++
In summary, I propose that we do not add product attributes to the e-
commerce module, but instead provide more grouping options for
products while each product attribute combination becomes a product in
itself. I would also suggest to add default product characteristics to
product groups to make the data-entry more efficient (e.g. you enter
one price, image or size to the product group and all products will
inherit this characteristic unless overruled on a product level).
++++++++++++++
Below are some of my thoughts and an IRC conversation that explains
why the recommendations above seem to make sense.
While reading this, bear in mind that I am a rather average PHP
programmer with limited experience in PHP5.
Right now you cannot add extra attributes to your purchases (e.g. you
can buy socks, but you cannot buy extra-large red rocks). I have been
looking at the options for adding this, but I am not sure how to
continue. I would really appreciate some ideas from you. Let me
first of all explain how it works at the moment.
Basically, there are product groups and these groups contain
products. You can specify things like the weight and price of the
individual products, but the order and shopping cart classes just save
arrays of product IDs and quantities (e.g. orderitems = Array([4] =>
1, [5]=>2) ... there is one product with 4 on order and 2 product
with ID 5 on order). This is a pretty efficient system.
When considering options for adding attributes to order items there
are several sides to consider:
A. Entering products into the CMS - this should make sense and keep
data-entry to a minimum
B. Efficient coding with optimised database storage
C. Useful storage for the end-user (e.g. you should be able to buy two
identical products with varying attributes)
Here are the options I can think of:
1. Create a short data-set of product varieties that has a many_many
relationship with products containing the various attributes. The CMS
user can then simply tick the boxes of the items available (e.g.
product 1 is available in S and M, product 2 in M and L). For
a. FOR A this is great - unless it gets complex, for
b. FOR B it is wonderful too, but you need to create one data-set for
each dimension (e.g. sizes, colours, etc...)
c. FOR C this is no good as you can not vary product costs, images or
other attributes. You cannot mark the XL as out of stock, etc... as XL
relates to lots of products at the same time. Once you start adding
multiple dimensions (e.g. colours, sizes, etc...) it becomes a mess.
2. Create a third-tier layer below product groups and products. Lets
call this the "selling items". You move most fields from Product to
"selling items", so the selling items have images, weight, size, etc...
Once you start thinking logically through all this, you realise that
you end up with basically another layer of product grouping and that
the actual products themselves stay as they are.
Lets look at an example: say, you are selling t-shirts. A logical
attribute would be size. If we use option one, then we create a new
dataset called size and in the CMS we indicate for each T-shirt what
options are for sale (e.g. S, M, X, but not XL), using a nice CMS
interface with tickboxes. So far so good. However, in terms of
coding and rewriting the e-commerce platform it becomes a big pain.
What if someone wants to buy two T-shirts 1 in XL and one T-shirt1 in
S. We have to add an extra field to the shopping cart called size -
and then check if (s)he has already ordered something in that size to
find out if a new "add to cart" action should be added to an existing
one or a new one. Now try adding a second attribute like colour. What
if I want two T-shirts1 in red/XL and one T-shirt1 in green/S. How
would we define the actions in "add to order" function in the product
class, etc...
In my opinion it would be much easier to make each product attribute
option combination in its own product, T-shirt1 then becomes a product
group. Within this product group there are quite a few products (e.g.
Green XL, Green M, Green Small, etc...) When you get too many , you
again can divide up the this group into several groups - and so on.
If we go ahead with this option then we should - if anything rework
the templates of the ecommerce module and not so much the code (at
least in this area). Product group pages should be presented more
like products with options. Perhaps there is room for creating a
product sub group or a product holder or something along those lines.
Lastly, if we go with this option, we should develop some tools that
make the data-entry more efficient. That is, we can still create
these datasets of colours or sizes that people can use to create new
products. The instruction would read something like this: click below
to create products in this product group where below is a list of
sizes. Each time the user clicks on a size, a new product is created.
++++++++++++++
Below is a conversation I had about this topic on the IRC channel
following on from these ideas:
++++++++++++++
<A>ok - we see the problems of product attributes
<B> ok
<A>i am thinking that the current model of product ID x Quantity is a
simple nice way to work with shopping carts
<B> correct
<A>however, products come in a variety of sizes, colours, etc.... (the
list goes on)
<B> ok
<A>this either means you make things complex by adding attributes to
products
<A>OR you start creating product groups within product groups within
so that in the end you can stil use the productID x Quantity model
<A>we like the latter, because it keeps it clean... however, this
poses challenges in the CMS
<B> so we agree to go with the second option
<A>I like it better for sure
<A>the first one is unworkable in my opinion
<B> yea, i second that
<A>even though it was hinted by the folks at ss that we should go for
option 1. Either they have a secret OR they have not thought it
through very well
<B> really
<A>i believe so
<B> they want to go with 1
<B> umm
<A>i had that impression - but I am not sure
<A>the reason I had this impresion is because in product.php they have
started an extra class called product_attribute or something like that
<B> there is just too many limitations with the first solution
<B> oh...
<A>yes, it is limiting because it is too complex
<A>anyway, perhaps i misunderstood - we should not assume that ss
chose 1 - and in the end - we should choose the best option
<B> ok, so back to the implementation of s2
<A>so, going with number 2, you said that we should use the complex
table field as a data-entry instrument were perhaps the final layer
(the actual products) are only added to the one before final layer
using a complex table field
<A>so, lets say the product group is SexyShirt ... this is a page ....
but this page has a complex table field where we can add a variety of
selling items = actual products
<A>if some fields in this CTF are not compled than the values will be
inhereted from the product group holder
<A>are you still following me?
<B> yep
<A>cool - one question I have is that when you create a CTF you create
a dataobject, however, we want to create lots of data-objects because
each product group has different products
<B> yes we will create a ComponentSet, which is a child of
DataObjectSet
<A>so in the database you end up with lots of tables OR one long table
of products that has a many_many relationship with product groups????
<A>well, yes, this part is probably a bit too complex for me, but I am
sure this can be worked out
<B> no, it will be a 1-many relationship
<B> because "selling items" can only have one parent
<A>ok
<A>yes, totally right, but in that case will we create many
DataObjectSets?
<B> just one
<A>ok
<B> but it will contain many dataobjects
<A>well, if that works then that sounds great
<A>ok, the componentset vs the databObjectSet idea?
<B> ummm... not really cause we can return either ComponentSet or
DataObjectSet
<A>ok
<A>well, I need to read up about this
<B> it all depends on how we retrive the data from the db
<A>so the next question is - how do we change the ecommerce module to
achieve this?
<B> not that hard actually, i can get it up by this weekend
<A>great!
<A>what shall I do?
<B> i only need a couple of hours to get it right
<B> question?
<A>yes
<B> how do we treat the product ID
<A>what do you mean?
<B> i mean will the selling items have different id, for sale purposes
<A>yes, essentially, the selling items become the products!
<A>in this way all the messy code with relation to the shopping cart
and the order can stay the same essentially!
<B> when displaying the product, do u want to display the same id's
<A>I think so
<B> yee, internally they must have different id's, but for the
customer
<A>oh - yes, I think so
<B> ok
<A>product codes then point to exact product items (e.g. a red XML
SexyShirt
<A>for sure!
<B> ok
<A>that is the whole point - you keep the products exactly as they are
- but create more grouping around them
<A>having said that, I would not show the product ID to the customer
at all - unless I had to
<B> but most products have ID's
<A>ok, well, yes, that is cool
<A>that is up to the template
...
read more »
