some help required with adding product attributes to e-commerce module
22 views
Skip to first unread message
windandwaves
Apr 1, 2008, 12:16:56 AM4/1/08
to SilverStripe Development
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 builder essentially
<A>he or she can also choose to display the product group ID
<B> yea, but we need to know this, because we might add a field for
the product id when entering the selling items
<A>i think the selling items are the products
<A>so we keep this whole framework intact
<B> indeed they are
<A>they already have a product id
<B> yea internally
<B> but that is not a big issue, because we can easily change that ltr
<A>ok cool
<A>would you like me to do something?
<A>what can I do next?
<B> how do we display the items
<A>yes, that is still a little tricky
<A>i can show you what I am working on at the moment....
<B> yea, that might help
<A>http://www.resumetemplates-usa.com/resume-templates/
<A>it is not really working at the moment .... as I am working on it,
but it displays each product and uses AJAX to show the details on the
side
<A>having said that, I think that the ecommerce module should come
with a really basic layout without any fancy ajax stuff
<A>as then you can build your own rather than having to strip away
what you do not need
<B> but i think they just wanted to show you the possibilities
<A>such is true
<B> but some of the code is insane
<A>no kidding!
<A>i think we should have a really simple e-commerce engine
<A>that at the same time is very powerful (e.g. you can easily add
100,00 products)
<A>then - you can add layers on top of that - almost like themes
<A>the thing is what I found is that the two e-commerce applications i
have been building in SS illustrate that each situation is so unique
that you just want to start with a really basic ecom engine
<B> i was just about to say the same
<A>this is turning into a pretty epic conversation -
<B> lol
<A>years from now, peopel will be quoting it - as a groundbreaking
step in e-commerce
<A>lol
<B> we hope so
<B> ;)
<A>legends in their own imaginations
<B> haha
<B> legends we will be
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 builder essentially
<A>he or she can also choose to display the product group ID
<B> yea, but we need to know this, because we might add a field for
the product id when entering the selling items
<A>i think the selling items are the products
<A>so we keep this whole framework intact
<B> indeed they are
<A>they already have a product id
<B> yea internally
<B> but that is not a big issue, because we can easily change that ltr
<A>ok cool
<A>would you like me to do something?
<A>what can I do next?
<B> how do we display the items
<A>yes, that is still a little tricky
<A>i can show you what I am working on at the moment....
<B> yea, that might help
<A>http://www.resumetemplates-usa.com/resume-templates/
<A>it is not really working at the moment .... as I am working on it,
but it displays each product and uses AJAX to show the details on the
side
<A>having said that, I think that the ecommerce module should come
with a really basic layout without any fancy ajax stuff
<A>as then you can build your own rather than having to strip away
what you do not need
<B> but i think they just wanted to show you the possibilities
<A>such is true
<B> but some of the code is insane
<A>no kidding!
<A>i think we should have a really simple e-commerce engine
<A>that at the same time is very powerful (e.g. you can easily add
100,00 products)
<A>then - you can add layers on top of that - almost like themes
<A>the thing is what I found is that the two e-commerce applications i
have been building in SS illustrate that each situation is so unique
that you just want to start with a really basic ecom engine
<B> i was just about to say the same
<A>this is turning into a pretty epic conversation -
<B> lol
<A>years from now, peopel will be quoting it - as a groundbreaking
step in e-commerce
<A>lol
<B> we hope so
<B> ;)
<A>legends in their own imaginations
<B> haha
<B> legends we will be
Sigurd Magnusson
Apr 1, 2008, 12:25:40 AM4/1/08
to silverst...@googlegroups.com
Romain, you just did some work in this area this week. Can you shed
some light, or was your problem and approach quite different?
some light, or was your problem and approach quite different?
Romain LOUIS
Apr 1, 2008, 4:43:15 PM4/1/08
to silverst...@googlegroups.com
As for me,
I have used a DataObjectDecorator on the Product class, I think it's
better than creating a new class which extends the class Product.
Check http://doc.silverstripe.com/doku.php?id=dataobjectdecorator for
the documentation and also the file EcommerceRole.php
Sigurd Magnusson wrote:
> Romain, you just did some work in this area this week. Can you shed
> some light, or was your problem and approach quite different?
>
> >
>
>
--
Romain Louis | Core Developer
SilverStripe
http://www.silverstripe.com
Skype : romain.louis
Level 3, 97-99 Courtenay Place
Wellington, New Zealand
Nicolaas Thiemen Francken
Apr 1, 2008, 5:01:56 PM4/1/08
to silverst...@googlegroups.com
Hi Roman
Thank you for your reply.
Do you think that using a data-object-decorator provides an overall solution
to the problem expressed in my original email (allowing buyers to choose
extra product details - size, colour, etc... while keeping the CMS
data-entry simple and retaining the productID x Quantity Model in the
shopping cart) and can you perhaps elaborate a bit more on how you used it?
I can see how it is useful (although perhaps not as well as I should), but
we are looking for something that adds this functionality as a core part of
the e-commerce module - using a data-object-decorator may actually limit the
potential in this case)?
If anyone else has any ideas then I would also appreciate other input.
Cheers
Nicolaas
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.3/1354 - Release Date: 1/04/2008
5:38 a.m.
Romain LOUIS
Apr 20, 2008, 7:46:01 PM4/20/08
to silverst...@googlegroups.com
Hi Nicolaas,
Sorry for the delay of my answer,
Actually it seems that your problem corresponds to the product attributes.
Check the Product class and you'll notice that a Product_Attribute class
exist and it's this class you have to use to make the couples Size and
Colors of your problems.
However, at the moment the ecommerce module doesn't manage entirely the
Product_attribute because if it's easy to create the attributes, after
you have to :
1) Manage the price which might change depending on the size and/or the
colour
2) Save this attributes values in the OrderItem
And this has not been done yet. I am still working on the ecommerce
module and this is one of the extensions that SS wants to add to the
ecommerce module for its next version.
Hope I have well answered to your question
Romain
Nicolaas Thiemen Francken
Apr 20, 2008, 8:02:39 PM4/20/08
to silverst...@googlegroups.com
Salut!
Thank you for your answer Romain.
Just let me know if I can help.
Just so you know (I forgot to mention this): I am listed in the bug database
as the person responsible for adding the product attribute extension so I am
more than willing to help - but a bit stuck.
Cheers
Nicolaas Thiemen Francken
Director Sunny Side Up Ltd
skype: nicolaasthiemen
within NZ phone 0800 771 777
overseas call +64 274 771 777
n...@sunnysideup.co.nz
www.sunnysideup.co.nz
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.2/1388 - Release Date:
> 20/04/2008 3:01 p.m.
>
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.2/1388 - Release Date: 20/04/2008
3:01 p.m.
Romain LOUIS
Apr 20, 2008, 8:41:35 PM4/20/08
to silverst...@googlegroups.com
Kia Ora !
This problem is pretty complex, yes because we have to manage as well
the other kind of relations that we could find and which would affect
the price or the settings of a product and we have to find a way to
store them in the DB and be able to play with them easily.
I think, we should have a search on the web because I am sure this
problem mist have been solved already by someone else (not for the
ecommerce of ss but for a similar commerce db structure).
Cheers
windandwaves
Apr 20, 2008, 9:17:05 PM4/20/08
to SilverStripe Development
My recommendation listed earlier in this post was that we actually
take a different route. Adding attributes is a messy business - it
would require a significant overhaul of the e-commerce framework,
which right now relies on a relatively clean concept of product ID vs
quantity.
My suggestion was to create pseudo product attributes by setting up
the CMS in such a way that you can add sub-categories of products that
actually become products themselves. Basically, we strengthen and
deepen the relationship between product groups and product items.
This was explained in my original email.
The advantage of this is that you can keep the simple structure of
productID x quantity. Furthermore, reports will be a lot easier
too.
The other idea of the concept I am advocating is that you have several
product levels. However, in the CMS and for the visitor to the front-
end website they may appear on the screen like one product with the
option to choose several attributes.
This means that we keep the database structure similar to the way it
is now and instead focus our attention to making data-entry in the CMS
easier and front-end presentation more meaningful to users.
This approach is better in my opinion as it:
- requires less back-end work
- creates a sleeker front-end for administrator and user
- allows the e-commerce solution to be used for a wider variety of
purposes.
I am keen to continue my work, but I think it would make sense to
consider this idea first.
Nicolaas
take a different route. Adding attributes is a messy business - it
would require a significant overhaul of the e-commerce framework,
which right now relies on a relatively clean concept of product ID vs
quantity.
My suggestion was to create pseudo product attributes by setting up
the CMS in such a way that you can add sub-categories of products that
actually become products themselves. Basically, we strengthen and
deepen the relationship between product groups and product items.
This was explained in my original email.
The advantage of this is that you can keep the simple structure of
productID x quantity. Furthermore, reports will be a lot easier
too.
The other idea of the concept I am advocating is that you have several
product levels. However, in the CMS and for the visitor to the front-
end website they may appear on the screen like one product with the
option to choose several attributes.
This means that we keep the database structure similar to the way it
is now and instead focus our attention to making data-entry in the CMS
easier and front-end presentation more meaningful to users.
This approach is better in my opinion as it:
- requires less back-end work
- creates a sleeker front-end for administrator and user
- allows the e-commerce solution to be used for a wider variety of
purposes.
I am keen to continue my work, but I think it would make sense to
consider this idea first.
Nicolaas
Reply all
Reply to author
Forward
0 new messages