1  Assignment Description  

This is an individual assignment. Students are referred to the Faculty's policy on plagiarism.  In this assignment you will build a prototype of a simple web-based system for purchasing tickets for football games for the AFL (Australian Football League). The system enables members of the public to purchase tickets. 

The aims of this assignment are :

(i)  to enhance understanding of XML and to develop some skills at representing and manipulating data using XPath and XSLT;

(ii)   to develop a better understanding of building web applications using asynchronous JavaScript and XML technologies.   

Because I want you to practice using XSLT on the server and the client, and also to use the DOM API on the server and the client, some parts of the design of the system are probably different from an  ideal implementation. Even if you believe that a better implementation is possible, you MUST implement the system as instructed here! 

2  Assignment Details  

Each match in the AFL season is described by the following data :

• Home team
• Away team
• Venue of match
• Date of match
• Starting time.

As an example, the first match of the season is described by

• Home team - Richmond
• Away team - Carlton
• Venue of match - MCG (Melbourne Cricket Ground) 
• Date of match - 26 March 2009
• Starting time - 19.40  

In this prototype system, the file that specifies the match details for which tickets are available does not need to contain details of absolutely every AFL match. Neither will this prototype keep track of the number of tickets available and purchased for particular games. We assume that all tickets have the same price ($30), and the actual seating is not allocated - customers can simply purchase tickets for the match(es) they request without specifying the actual seat location in the stadium. Tickets have to be purchased one at a time.

(A real system would offer a multi-ticket purchase option, and of course would allow users to indicate preferred seating, with seats available at various prices,  but I have tried to keep the requirements for the assignment relatively simple.)  

When a user accesses the system, they will be shown the front page, or "purchase page", which is the main interface of the system. This page will display all the controls that the user can use to interact with the system, and will also display a shopping cart that shows the matches for which tickets have been purchased, plus some other details.   

This page should provide the user with the following transaction options:

a)  Quit; 

b)  cancel all purchases in the shopping cart, then remain within the purchase page, ready to make a new purchase; 

c)  make a purchase;

d)  go to the checkout - a new page that manages payments.

Making a purchase is the default activity. The other 3 activities should be controlled by buttons to be pressed by the user. The 4 activities are described below.

a). Quit Option

Choosing quit should have the effect of exiting from the system; any items currently in the shopping cart will just be "forgotten" - ie, no purchase will be made.  

b). Cancel Purchases Option

Choosing this option should cause the shopping cart to be emptied without a purchase being made. The purchase page should still be live, and the user can continue interacting with it.

 c). Making a Purchase Option

This is the default option. The user does not have to press a button to access this option.  The purchase page should have a list box control (call it LB1) that allows the user to

choose whether to display 

• no matches 
• all matches
• just the matches involving a selected team. 

(Thus there should be 18 options available in this control - no matches, all matches, and the 16 team names: Adelaide, Brisbane, Carlton, ...., Western Bulldogs.)   

When the system loads, the "no matches" option should be selected as the default. The list box should allow just one item to be selected. Selection of an item should require two steps: (i) click on the item in the list to highlight it; (ii) click on a button underneath the list to actually make the request. (This two-step process protects against inadvertent selection of options, with each selection causing communication with the server.)  

A second list box control (call it LB2) should be on the purchase page, that lists the matches for which tickets are available. Initially, when the page loads, because LB1 has "no matches" selected, LB2 should be empty.   

When the user makes a choice in LB1, LB2 should immediately display the list of all matches which correspond to the user's selection and for which tickets are available. If the user selects a team option in LB1, then all matches that involve that team, either as home team or away team, should be listed in LB2. The options should be a list of all relevant matches described by giving just the teams (home team first) and the date (eg "Richmond vs Carlton, 26/3/2009").   

Selection of a match should require two steps: (i) click on the match in the list to highlight it; (ii) click on a button underneath the list to actually make the request. When the user clicks on the button, they are indicating that they wish to purchase a ticket for the selected match. Having done so, the user should be presented with a confirmation dialogue to provide the opportunity to go ahead with the purchase, or to abandon it. 

• If confirmed, the shopping cart for the user should be updated with details of this purchase. (Just a single ticket is purchased. If a user wants to purchase several tickets, then in this prototype they must be purchased one by one.) 

• If abandoned, then the shopping cart will remain unchanged. When a user interacts with the system, a shopping cart is maintained that includes all tickets purchased so far. The user can choose to go to the checkout (Option (d), described below) at any time to finalise the purchase of the tickets that have been chosen.   

The  user's shopping cart should be displayed at all times (including when the system first starts up, when it will be empty). It should record the matches for which tickets have been selected for purchase (identified only by the home team and away team - don't display the date), the number of tickets purchased for each match, and the total cost of the tickets. If it is empty, it should still be displayed, with some text indicating that the cart is empty.   

Note : For this prototype, the only way to alter purchases in the shopping cart is to cancel all purchases as described above. (In the real system, a more sophisticated set of options will be provided!)

d). Go to Checkout Option

Pressing the checkout option should present the user with the "checkout page". This should be displayed in a new window or tab, with the original page being maintained in the main browser window or tab. The shopping cart should be displayed on this page too. The user will be required to supply personal details - in the real system this will be address and credit card details; in our prototype, the user should simply be asked for name and email address. If the user departs from the check-out page, and later comes back, in this prototype we require the user to enter their details again. {In a real system, the data would probably be remembered.}