If we were to have a system that utilized simple variants, we could display a simple table of product variants on the "main products" page, listing the names of products, cost or cost di
Trang 1One important aspect of this code is that, each set of attribute values is cached, and
then added as a tag for the template engine after the attribute sets themselves have
been converted into tags This is because the template system processes the tags in
order, so if it doesn't do the attributes first, it won't find the tags it generates, which
are replaced with the attribute values, as explained in the next section, Templates.
Templates
We have looked into how to alter the framework to use different templates
depending on if the product has customizable attributes The next stage is to
actually make these templates
We need a template for the product with attributes This template requires a
nested loop of template tags: the outer loop of template tags will be to generate
a drop-down list for each attribute, the inner loop to generate the attributes for
each of the attribute drop-down lists
<h2>{product_name}</h2>
{product_description}
<p>Cost: £{product_price}, number in stock {product_stock}
Weight: {product_weight}Kg.
</p>
<p>
<img src="product_images/{product_image}" alt="{product_name}
image" />
</p>
<! START attributes >
<select name="attribute_{attribute_name}">
<! START values_{attribute_name} >
<option value="">{value_name}</option>
<! END values_{attribute_name} >
</select>
<! END attributes > attributes > >
This is the same code as our product template, with a select field A drop-down list
is generated for each set of attributes associated with the product, and then list items
are generated where appropriate
Trang 2A look back at simple variants
We discussed simple product variants earlier One advantage that they have over
multiple variants becomes obvious when page design becomes a concern If we were
to have a system that utilized simple variants, we could display a simple table of
product variants on the "main products" page, listing the names of products, cost or
cost difference, and a purchase button
Of course, this is something we could look at implementing as subproducts, should
we wish to
Giving users control
Along with giving users a choice for products in our store, we may also wish to give
them some control over the products; for example, this could include:
Uploading a photograph or image, for our Juniper Theatricals store; this will
be for customers to order and purchase customized novelty t-shirts
Supplying some custom text, again for our Juniper Theatricals store; this will
be for customers to customize their novelty t-shirts with a punch line of their
own, to fit into the products template
•
•
Trang 3How to customize a product?
We need to make it possible for our customers to customize the product through
both file and image uploads, and then entering of free text
Uploads
If the product is to allow the customer to upload an image, then the template
requires a file upload field within it, to facilitate that We are only going to look
at allowing a single file upload for each product; if a product required multiple
images, for instance print media, where back and front designs may be required,
the customer can compress them into a single file It may be worth considering
implementing multiple file uploads per product at a later stage, should the
requirements of our store demand it
Custom text
The simplest way to handle custom text is to have at most one free text permitted
per product This would simply involve having an extra field in the table to contain
items held within a customer's basket, relating to the value from this field, and also a
field in the products table indicating that the product can accept free text as an input
For many situations, this should be sufficient; however, let's look at a potential way
we could support multiple text fields In our Juniper Theatricals store, we will want
to advertise customizable t-shirts for sale, with novelty text or images within them If
the customer is to supply some text, we may wish to provide them with options for
entering text for the front, back, and perhaps even the sleeves, or below a logo, which
may appear on the breast of the shirt
If we have an additional field in our products table containing a list of free text
attributes, we may wish to collect it from the user, and then generate text boxes for
each of these attributes, and the submitted values could be serialized into an array
and stored within a single field in the customer's entry for the product in the basket
items table, when we develop that in Chapter 6
Trang 4When viewing a product with custom text inputs, the appropriate text boxes appear
within the view, as the following screenshot illustrates
Limitations to this method
This method obviously has limitations Primarily, because we store all of the custom
text inputs available and their values in a single database field, instead of one per
value, it isn't going to be easy to search for product purchases based on the values
submitted into these Another limitation is that all of the text fields would need to
be text input boxes, and we could extend this to support both input boxes and text
areas, among other relevant and useful input boxes
Maintaining uploads
In Chapter 6, we will look at processing these uploads; however, we will also need to
consider maintaining them If a file is uploaded and a product is added to a basket,
and that basket is never converted into an actual order, we will want to remove that
file Similarly, once an order has been paid for, and processed fully, we would also
want to remove it
Trang 5Security considerations
There are also a number of security considerations which we must bear in mind:
By allowing customers to upload files, we could be open to abuse from
someone repeatedly uploading images to our server We could implement
time delays to prevent this
Which types of files will we allow customers to upload? We should check
both the type of the file uploaded and the file extension against a list of
suitable values
What would the maximum file size be for files customers upload? If we set
this value to be too large, our server will get filled up quickly with custom
files, or could be abused by someone purposely uploading very large files
What safeguards are in place to prevent customers finding uploads of
other customers?
Database changes
To allow customers to customize products, we obviously need to make some changes
to our database structure to indicate that a particular product is customizable, and
can be customized either by the customer uploading a file or entering some text
Extending our products table
The changes required to our products table are actually quite simple; we only need
to add two fields to the table:
allow_upload(Boolean): This field is used to indicate if the customer is
permitted or able to upload a file when adding the product to their basket
custom_text_inputs(longtext): This field is used to hold a serialized
array of free text fields, which we may wish to collect from our customers
The following SQL query will modify the table for us:
ALTER TABLE `content_types_products` ADD `allow_upload`
BOOL NOT NULL, ADD `custom_text_inputs` LONGTEXT NOT NULL ;
•
•
•
•
•
•