Overview
This is the first part of a two-part asignment. This part is worth 21% of your final grade for
IFB104. Part B wil be worth a further 4%. Part B is intended as a last-minute extension to
the asignment, thereby testing the maintainability of your solution to Part A and your ability
to work under time presure. The instructions for completing Part B wil not be released until
Wek 12. Whether or not you complete Part B you wil submit only one solution, and receive
only one mark, for the whole 25% asignment.
Motivation
The Internet has dramaticaly changed the way we conduct commerce. Online shopping is
increasingly displacing traditional forms of retailing. Here you wil develop an application
that provides an online shopping experience, using data downloaded from the World Wide
Web. The program wil have a Graphical User Interface that alows its user to choose which
products they want to buy from diferent categories. Having done so they wil then be able to
print an ilustrated invoice summarising their purchases, which can be viewed in a standard
web browser. Most importantly, the online shopping application wil aggregate both archived
and current data sourced from online “feds” that are updated on a regular basis.
This “capstone” asignment is designed to incorporate al of the concepts taught in IFB104.
To complete it you wil need to: (a) use Tkinter to create an interactive Graphical User Inter-
face; (b) download web documents using a Python script. and use patern matching to extract
particular elements from them; and (c) generate an HTML document containing the extracted
elements, presented in an atractive, easy-to-read format.
Goal
Your aim in this asignment is to develop an “online shopping app” which alows its users to
select items from one or more online retailers to add to a “shopping cart” of purchases. There
must be at least four distinct categories of items for sale. The items on offer are extracted
from the product lists ofered by actual online shops. Two (or more) categories are derived
from previously-downloaded web documents, and a further two (or more) categories must be
based on “live” web documents currently online. The online web documents must be ones
that are updated on a regular basis. When users are happy with their selections they must be
able to print an invoice detailing their purchases and the total cost (in Australian dollars).
For the purposes of this asignment you have a fre choice of what products your online
shopping application wil offer. Your application must offer (at least) four clearly-distinct
categories of item. Categories could be:
• clothing,
• electrical goods,
• books and magazines,
• motor vehicles,
• furniture,
IFB104 Building IT Systems
Semester 1, 2018
• toys and games
• jewelery and cosmetics,
• real estate,
• etc.
However, whatever categories of products you choose, you must be able to find online web
documents that contain regularly-updated lists of such products. The categories could al
come from the same online retailer or from two or more diferent ones.
For each product category the corresponding online web document must include at least ten
items for sale at any time. For each item the document must include a product name, a textu-
al description and/or a photograph of the product, and a price. A good source for such data is
Rich Site Summary (RS) web-fed documents. Appendix A below lists many such sites
suitable for this asignment, but you are encouraged to find your own of personal interest.
For the “live” product categories the chosen web documents must be updated regularly, pref-
erably at least once a day.
Using this data source you are required to build an IT system with the following general ar-
chitecture.
Your online shopping application wil be a Python program with a Graphical User Interface.
Under the user’s control, it extracts individual elements from two distinct sets of web docu-
ments to display the products for sale. One collection of web documents is static and is
stored in an “archive”, i.e., a folder of previously-downloaded HTML/XML documents. The
other source of web documents is the “live” Internet. Your application must ofer at least two
categories of products from each of these two sources. For each category of product there
must be at least ten items for sale at any time. Once the user has made their selections via the
GUI, your application must generate an HTML “invoice” for the purchases. This invoice can
then be examined by the user in any standard web browser.
IFB104 Building IT Systems
Semester 1, 2018
Illustrative example
To demonstrate the idea, below is our own online shopping application, which uses data ex-
tracted from several diferent web sites. Our demonstration application alows users to select
from four product categories, “geeky” gifts, western-style. hats, replica (fake name brand)
watches, and children’s toys. The application alows users to se which items are available
and pick those they want to buy from each category. The program aceses al the necesary
data from the various web sites (either “live” or using previously-downloaded documents)
and uses it to produce an ilustrated invoice in the form. of an HTML document which can be
viewed in any standard web browser.
The screnshot below shows our example solution’s GUI when it first starts. We’ve caled
our online shop the “Busy Mouse” and have included a suitably evocative image to serve as
the shop’s logo.
The GUI offers the user four distinct categories of products. Two categories, “Gifts for
geeks!” and “Western hats” are static and are never updated. We asume these are unsold or
remaindered stock and have thus labeled them as our “Bargain bin”, but any name such as
“Previously advertised”, “Old stock”, etc., wil do. The other two categories, “Replica (fake
name brand) watches” and “Toys and games”, are “live” and represent current items for sale
online. These two categories wil likely contain diferent items each time we check them.
The user can select a category of items by clicking on the corresponding radio button. For
instance, the user may choose to look at western hats first:
IFB104 Building IT Systems
Semester 1, 2018
When the user selects a category of products they must be presented with a list of items for
sale and their prices. In our demonstration solution we have done this by popping up a new
window:
Ten products are listed. This information was sourced from a web document downloaded via
the URL shown at the bottom of the window and stored in a local folder. (Why the “hat”
shop also sels necklaces and earings we don’t know!) Our program uses patern matching
to extract the necesary elements from the web document so that if a diferent document is
inserted in the archive the data displayed wil update acordingly.
The user can then select a particular item to buy using a spinbox widget. As per the scren-
shot on the previous page we asume the user selects item number 4 and preses the “Add to
cart” button to add the purchase to their shopping cart.
Next we asume our user selects the “Gifts for geeks!” category and chooses items 10 and 6,
in that order, adding both to the shopping cart by presing the appropriate button:
IFB104 Building IT Systems
Semester 1, 2018
Again, a list of products for sale, extracted from a document previously downloaded via the
URL shown, was displayed when the user selected the category:
Our shopper’s atention then turns to the “Today’s specials” options, in the knowledge that
these categories are “live” and currently online. First the “fake name brand watches” catego-
ry is selected, which produced the following list of items on April 18
th
, 2018:
At this point the user is satisfied with their purchases and preses the “Print invoice” button.
This causes the application to generate an HTML file containing a summary of the user’s
purchases. When viewed in a standard web browser this document details the purchases in
the order they were made, including each product’s name, its description or photo, its price
(in the original web site’s currency), the total price for al the purchases (converted to Aus-
tralian dollars) and the four web pages from which the product details were sourced:
In summary, therefore, our demonstration online shopping application has the following fea-
tures:
o Widgets that identify the application, including a name and a logo.
o Widgets that alow the user to select a product category and an item within that cate-
gory that they wish to purchase, choosing from (at least) two archived categories and
(at least) two live categories.
o Widgets that alow the user to se the names and prices of (at least) ten products for
sale in each category.
o A widget that alows the user to declare that they have completed their shopping and
want to receive their invoice.
The generated invoice has the following features:
o A name identifying our imaginary shop.
o An image representing our shop’s logo.
IFB104 Building IT Systems
Semester 1, 2018
o The total price for al of our purchases, converted to Australian dollars (al four of our
source web sites listed their prices in US dollars, even the “replica watches” site
which is based in the UK).
o For each item purchased:
o The product’s name;
o A textual description of the product or a photo of the product; and
o The product’s price (as shown on the original web site, even if it is in a foreign
currency).
o Links to the original web sites for al four of our product categories, which can be
used to inspect the site’s current contents.
Importantly, the image file containing the “Busy Mouse” logo sen above, and al the other
product images, do not reside on the local computer. They are all links to image files online
and are downloaded “live” when the invoice is viewed in a browser. (The quality of the im-
ages varies, depending on the source. The images for the toys are smal “thumbnails” on the
original site, so are noticeably pixelated when enlarged to fit our invoice’s layout.)
You are not required to follow the details of our demonstration GUI or invoice layout. You
are strongly encouraged to use your own skils and initiative to devise your own solution,
provided it has al the functionality listed above. For instance, diferent widgets could be
used for the GUI, such as pull-down menus for selecting items. Similarly, an obvious im-
provement to our example would be to add a widget to the GUI that displays the current con-
tents of the user’s “shopping cart”.
To produce the invoice, our online shopping application used regular expresions to extract
elements from the relevant web documents, whether they were stored in the static archive or
downloaded when the program is run. For instance, we found by inspecting the HTML code
from the Western Hat shop that its photos were thumbnail images that appeared betwen
… XML tags, which made them easy to find with a regu-
lar expresion. However, extracting the prices for the bestseling toys from Amazon proved
more dificult because they were in diferent formats for diferent products, sometimes with
two or even thre distinct prices shown for one product, reflecting discounts from the original
price. In this case our regular expresion relied on the fact that the price we wanted was al-
ways the last one appearing before the word “Visit” displayed on the page.
Care was also taken to ensure that no HTML/XML tags or other HTML entities appeared in
the extracted text. In some cases it was necesary to delete or replace such mark-ups in the
text after it was extracted from the web document. The generated invoice must not contain
any extraneous tags or unusual characters that would interfere with the document’s appear-
ance when viewed.
A smal part of the HTML code generated by our Python program is shown below. Although
not intended for human consumption, the generated HTML code is nonetheles laid out neat-
ly, and with comments indicating the purpose of each part.