Fields

I wanted to know if is possible add to the product one fields where I can select color and size.
Site Example: www.rasouliniastore.com

Thanks

Yes it is possible. But you would have to build it because there isn't a wizard to do it for you. You would have to create the database associations or static lists for the options depending on your store and then show them with the add to cart buttons after adding a size and color column to the cart in order to store those options.

Unfortunately I'm not very good at creating what you say, is possible to know how to do it?

There is not a way to do it without trying. Have you added the columns to your cart? Where do you get stuck?

Originally Said By: Ray Borduin

  There is not a way to do it without trying. Have you added the columns to your cart? Where do you get stuck?  

I find myself in this same position also. Unfortunately, I cannot seem to get started at resolving the situation either. My problem is as follows and any helpful pointers would be gratefully received.

My client is going to be selling clothing, which for every size has a unique reference. The sizes generally are the usual of small, medium, large and XLarge. This is further exacerbated by including colour combinations.

Because PowerStore keeps a tally of stock levels, how would I integrate the sizes and colours into the database and page? What I'm trying to say, is what information do I need and on which pages of the site would I include the necessary code.

All help welcome!

You could handle this quite a few different ways still.

You could probably have each size, color, and product combination as a separate product so that you wouldn't need to update the current inventory control system.

Trying to do inventory control for multiple options will get very hairy very fast if you don't insert them as separate items.

Originally Said By: Ray Borduin

  You could handle this quite a few different ways still.

You could probably have each size, color, and product combination as a separate product so that you wouldn't need to update the current inventory control system.

Trying to do inventory control for multiple options will get very hairy very fast if you don't insert them as separate items.  

OK I can see how that might be the better solution for us mere mortals but when the customer comes to the item in question – a shirt let's say – in one particular style and design that is available in 6 sizes and 4 colors each size thus necessitating 24 separate entries into the db how do we logically represent that to him or her as a single item available in a myriad of sizes and colors?
I know I'm not the only one confused by this.
Wouldn't it be easier to have a color and a size table and incorporate them as foreign keys.
I've mimicked your "productcategories" table in PowerStore to create a productsizes and productcolors table and have attempted to emulate what you did but so far, no luck.

Either method of getting the job done would be OK with me but am I wrong to assume the latter method to be the preferred one?

Mick

I'd say you would still have an easier time creating the interface to edit the multiple products as if they were one than to try to get it actually working with variable options in a relational table.

If you did options and variable options then you would have to come up with a database structure that would allow you to store the inventory according to multiple options. A single option I could try to explain, but variable options like size and color, where each size/color combination has it's own inventory gets very complex from a database perspective.

You either need to add the complexity in the database or add it in the administrative interface. I'm just saying it would be easier to do with the admin interface if you aren't very skilled at this type of thing, and in that case you probably wouldn't have asked the question.

How would you create the admin for it? One page at a time... and each would have their challenges and would likely require at least some hand code.

Can you even imagine the interface you would like someone to use? I guess I would start with doing the design of what I would want to make functional and defining the admin experience. Then I would work on getting the forms to look right and function correctly before the form post.

Then I would get Webassist tools involved to do the database manipulation and form validation. But you are going to have to do a lot of work outside of the WebAssist tools to get it done either way.

Originally Said By: Ray Borduin

  I'd say you would still have an easier time creating the interface to edit the multiple products as if they were one than to try to get it actually working with variable options in a relational table.

If you did options and variable options then you would have to come up with a database structure that would allow you to store the inventory according to multiple options. A single option I could try to explain, but variable options like size and color, where each size/color combination has it's own inventory gets very complex from a database perspective.

You either need to add the complexity in the database or add it in the administrative interface. I'm just saying it would be easier to do with the admin interface if you aren't very skilled at this type of thing, and in that case you probably wouldn't have asked the question.

How would you create the admin for it? One page at a time... and each would have their challenges and would likely require at least some hand code.

Can you even imagine the interface you would like someone to use? I guess I would start with doing the design of what I would want to make functional and defining the admin experience. Then I would work on getting the forms to look right and function correctly before the form post.

Then I would get Webassist tools involved to do the database manipulation and form validation. But you are going to have to do a lot of work outside of the WebAssist tools to get it done either way.  

I certainly agree with what you are saying here.

My client would like to have stock control, but if it means that he has to enter every size in very colour and show the appropriate pages to contain the items, it all becomes very unwieldy for the buyer to find what he wants in my opinion!

The easy option at the moment is to provide the buyer with a choice of size and colour, where appropriate, and leave it to the site owner to decide if he has the appropriate item for delivery!

If anyone else can come up with a better way, please let us know!

You would need to create a couple of separate tables; 'Colours' with your colours in, and 'ProductColour' with the joining information of both product and colour.

The 'Colours' table would have colour_id and colour columns.

The 'ProductColour' table would have to consist of an id, colour_id and product_id.

At that point you take your product_id and join it with the colour_id by using the joining table which basically allows you to have one single instance of 'red' in your database that applies to many products.

Basically, you need to create an inner join between the product_id and the colour_id and it's at this point my knowledge gets shaky I'm afraid.

When a user browses a product with multiple colours, you ask the page to take the product_id e.g. 99, look in the ProductColours table (not the colours table) for any instance of product_id 99 and then print to a dropdown menu (or similar) the colour_id's where the records product_id matches 99...

Colours table: colour_id; colour
ProductColours table: ProductColour_id; colour_id; product_id

so the SQL will look like this (I think):

SELECT FROM ProductColours.colour_id, ProductColour.product_id, Colours.colour FROM ProductColours INNER JOIN Colours ON ProductColours.colour_id = Colours.colour_id
WHERE product_id = VALUE
ORDER BY colour ASC

The parameter 'VALUE' then needs the following info:
Name: VALUE
Type: Numeric
Value: Request("product_id")
Default: %

You then do the same for sizes, and I guess you could also apply the same for stock levels. This is only a sample, and I don't expect it to work... it might do, and that will be nice for you, wont it? If it doesn't, then there is a good ground for somebody else to offer up a bit of advice on how it might be able to work. I am sure that this is fairly rudimentary SQL, but I struggled with it a bit, lost my rag, struggled some more, really spat the dummy, struggled on further, and hey presto, it worked. How, I don't know, but it did :D

The above needs to be applied in the advanced recordset panel in dreamweaver.