2.  Product Variations and User Uploads

4.  Product and Categories are not enough  Needs to extend product information  User can customize product information  Product variation, uploading images, or product text  We are focusing on:  How to create customizable products  How to assign uploaded files to individual product orders  How we will maintain these uploads  How to assign custom user-submitted data with individual product orders

5.  So far, we have seen static or non- customizable products in our framework  Many products in e-commerce stores require some sort of choice from the customer  Product size, color, no. of items, or material  Why user can customize product information?  To see variations of product  To choose required variation of product before purchasing it

6.  We can use a single dropdown box for variations of product  For a T-Shirt product  We may have two variants, color and size  For both we may have two dropdowns, one for each  To implement this in framework  We would only need to make a reference to the variant of the product the user decides to purchase  In DB, along with product info. of shopping cart, two columns for variant are also required

7.  Simple variant like color or size or quite limiting  But with two variants, color and size, admin would need to create a variant for each combination of these  Which wouldn't really be practical  For different 5 colors and 5 sizes, admin may need to handle 25 combinations of variants of a product

8.  Our framework work should have a list of administrator-definable variation types or attributes  For example for following attributes  Size, color  Each attribute will be associated with its no. of variations  Size Variants: small, medium, Large, XL, XXL  Color Variants: red, green, blue, white, black

9.  Each product will have a number of these variations associated with it, grouped by their variation type  We need to store and manage potential cost differences with different versions of a product  Large T-Shirt have larger cost than small T-Shirt

10.  Any combination of variants selected by customer will be the end product to sale  It is quite different than any combination will lead to a separate product Product Color Red Green Blue White Black Color Red Green Blue White Black Size Small Medium Large XL XXL Size Small Medium Large XL XXL

11.  We won't be associating a product with variation types (attributes)  Because all products have not same variation types  Mobile and T-Shirt  We need to create two tables to record the variation data itself  Some additional tables to maintain the relationship between products and their variants

12. FieldTypeDescription IDInteger (Primary Key, Auto Increment) To reference the attribute from the attribute values table NameVarcharThe name of the attribute, for example size, color, and so on Product Attributes table

13. FieldTypeDescription IDInteger (Primary Key, Auto Increment) To reference the attribute from the association with the products table NameVarcharThe name for the attribute value, for example, Blue, Large, and so on Attribute_idIntegerThe attribute this value is associated with Product Attribute Values table

14. FieldTypeDescription Product_idIntegerThe ID of the product we are associating with the attribute value Attribute_valueIntegerThe ID of the attribute value the product is being associated with OrderIntegerDetermines the order in which the value should be displayed in the attribute list Cost_differenceIntegerIndicates if the variant product has a cost implication, for example ordering an extra large -Tshirt may increase the cost Product-Attribute-Value-Association table

15. Product-attribute-value-association table

16. Constraints on Product-attribute-value- association table

19.  In order to detect, a product has any variation or changeable attributes  We use to get product data and use it for sub query  Sub query groups together all of the attribute and attribute values associated with a product

20.  Product controller will check the attributes property and call/generate the relevant template  Template with or without attributes value  Iterate through them, and for each attribute we generate a list of values associated with it  List is inserted in template (dropdown) dynamically  Attributes are cached and then inserted as tags for template engine

23.  Along with choices about a product we may want to give user more controls  Uploading a photo to be printed on T-Shirt  Short text to be displayed on T-Shirt  For photo  Template required a file upload field  Can be allowed more than one photos  Custom Text  Template requires a textarea or textbox field  Also multiple texts can be allowed

25.  Maintaining Uploads in two ways  If order has been placed  Image is uploaded, payment has made, and order has been completed  Image should be removed from uploads and DB  If order has not been placed  Image is uploaded and product is placed in basket but order is not placed  Image should also be removed from uploads and DB

26.  Security consideration about uploads  Someone can repeatedly upload images ▪ CAPTCHA or time delay are useful  Someone can upload abused images  What type of images should be uploaded? ▪ Provide list of images extensions to controller  What should be the maximum size of each image? ▪ Controller should allow to upload up to a fixed size  Prevent customers to find uploads of other customers ▪ Privacy policy or authentication can be solution

27.  We need to add two fields in product table  allow_upload(Boolean): is a customer allowed to upload file for specific product  custom_text_inputs(longtext): array of free text fields collected from our customers.

28.  Template required to show the variations to user if product has customization options  Textarea or file upload fields  If no customization options, standard template is enough  It can be done with template switching with product variations  If customization allowed, show customization fileds