This assignment is a continuation of Assignment 1.
Your task in this assignment is to design and implement a database-backed
Web application that models the main components
of an online auction system such as eBay, using HTML, CSS, PHP, Smarty, MySQL and
JavaScript. The application must allow users to register, login and
logout,
offer items for sale, update and delete items offered for sale, browse and
search items offered for sale, and bid for items offered for sale.
It would be useful if you have not already done so to visit eBay, register, and explore it to
familiarise yourself with its features.
Note
Do not change the structure or content of your Assignment 1 database
tables. Do not change your Assignment 1 source code. Use new database
tables for Assignment 2.
Before you start, copy your complete Assignment 1 directory
assign1 into a new directory assign2, create new database
tables (a2_categories and a2_items), and change
all references to old table names in your solution to new table names.
Tasks
Your task in this assignment is to design and implement the main components
of an online auction system such as eBay
as summarised above.
Specifically, your system, must provide the following features:
The system must extend that of Assignment 1, in particular it
must manage a static set of categories and a dynamic set of items for
sale.
Users can register, login and logout. Logged-in users must see a
visual reminder that they are logged-in while they are logged-in.
Registered users have a username, a password, a real name and an email
address.
Logged-in users
(and only logged-in users) can offer items for sale. A user may have
several items offered for sale at the same time.
As in Assignment 1, items offered for sale have a name,
a description, a category, a vendor, and a starting price (the lowest
price at which the item will be sold). For Assignment 2, vendors are
foreign key references to a users table, items also have a closing
datetime (the final datetime at which new bids for the item may be
made) and may have an image. Note that every item must have a closing
datetime but may or may not have an image.
After offering items for sale, but before any bids have been
placed for the item, the item's vendor can update the item. At any
time before an item's closing datetime, the item's vendor can delete
the item (i.e., withdraw it from sale), in which case all bids
for the item will be removed. (These operations must be made from
the detailed description of the item, and only the item's vendor
can perform these operations.)
As in Assignment 1, all users can search items offered for
sale by one or more of category, name, description and vendor.
Searching return lists of item summaries (name, category, and starting or
current price), with each item
summary leading to a detailed description of the item. These lists
must be paginated. The detailed description must now also include
the item's image (if provided) and the time remaining until the closing
datetime.
Logged-in users can bid for items offered for sale, up to the
closing datetime for the item. A user may be bidding for several
items at the same time. Each bid must be at least as high as
the initial price and must be strictly higher than
any previous highest bid for the item;
the system will not accept bids that are do not satisfy these
conditions. The system will not accept bids after the
closing datetime for the item.
Logged-in users can view a list of items they have offered for
sale, are currently bidding on, or have won. As above, these are
paginated lists of item summaries that link to detailed descriptions.
Users may request the bid history for a given
item from the complete description of the item. A bid history displays
the bidder, time and price of each bid, in reverse chrolonological
order (i.e., most recent bids first).
The system must not deal with payment issues (which are
outside the scope of this course).
Within this scope, the system must provide all natural and
necessary features to be usable as an online auction system.
Other requirements
All user input must be appropriately sanitised. Selected user input
must be appropriately validated. (I.e., for convenience, you do
not need to validate all user input, but you must validate some user input
to demonstrate you know how to do it, and document what user input is
validated.)
Your application must have a simple, uniform, distinctive, usable,
two-column user interface. Page layout must conform to generally accepted
standards. Page transitions must be chosen to enhance usability.
More specifically, you must use a 2-column page layout, with a header that
identifies the application and contains a link to the home page, the name
of the logged-in user and possibly other login and search features, and a
footer containing your name and student number and a link to the
documentation.
HTML5 elements and attributes must be used to enhance function and
readability where possible.
JavaScript must be used to enhance document behaviour on the client,
e.g., for client-side input validation, for displaying additional
information about an item when the cursor is held over an item summary, or
to poll the database every 15 seconds say and to update the detailed
description page every time a new bid is made on that item (remember,
there may be many users accessing the application concurrently).
Implementation
The user interface must use valid HTML5 documents It must use CSS to
separate HTML document content from presentation. The server-side
scripting language must be PHP. Separate MySQL tables must be used for
users, categories, items, bids, and possibly other information. The
implementation must use Smarty templates to separate application logic from
HTML presentation. It must use session variables to maintain application
state (in particular, which user if any is currently logged in). It must
use JavaScript or jQuery to provide document behaviour that enhances the
user experience.
MySQL transactions must be used to ensure data integrity when required.
You must use good program structuring techniques as taught in
Programming 2 and previously in this course. As a minimum, groups of
related function definitions must be stored in separate definition files,
PHP scripts must not contain any HTML content, all files must be
properly commented and indented, all HTML and CSS files must be
valid, and all definitions, images, CSS, JavaScript, etc., must be stored
in separate subdirectories.
You must demonstrate that you can design and implement the application,
using the tools and techniques described during the course. Howevever,
if you find yourself implementing the same task
repetitively, it may not be necessary; seek advice. Do not implement
anything (significant) that is not requested above.
Suggestions
Start work now!
Design and implement your solution incrementally.
Start by designing your MySQL tables. This is a critical task. You may
omit inessential attributes initially.
Then decide which documents or scripts you will need, whether they are
forms, scripts that generate output, or (action) scripts that are executed
only for their effect. Think carefully about where action scripts
redirect to after execution.
Then design and implement PHP scripts corresponding to the page views and
action scripts, testing after completing each script.
Then incrementally extend the database schema, set of scripts and
implementation, and repeat.
Clarifications and more detailed suggestions will be given in lectures and
laboratories.
Testing
Test your application thoroughly after implementing each new feature, and
test it on at least two distinct browsers.
Documentation
Your submission will require written documentation together with
well-commented source files, and possibly a demonstration of your
application.
Your documentation must be in the form of one or more HTML documents. It
must:
Include the database schema used (i.e., the SQL "create
table" statements used) in your application.
Describe how to use your application, in particular give relevant
URLs.
Describe which (if any) requirements weren't implemented and why.
Describe which (if any) features do not work properly and why.
It may be helpful to use the following checklist in providing the
above two descriptions:
User registration, login and logout.
Offering items for sale.
Offering items for sale with or without images.
Updating items before any bids placed.
Deleting items before closing datetime.
Browsing items by category.
Searching items by name, description or vendor.
Paginating lists of item summaries.
Displaying complete descriptions of items.
Displaying images in complete description of items.
Displaying remaining time in complete description of items.
Placing bids for items, subject to all constraints.
Displaying bid history for items.
Describe what usability testing was performed and what changes
were made as a result.
Provide any addition usage notes or comments.
Assessment criteria
We expect the structure of your application to be clear, simple,
standards-conformant, validated, and well-documented. We expect the
organisation and English in your implementation and documentation to be of
high quality.
Assessment of your assignment will be based on functionality,
implementation, documentation, overall quality, and submission details. We
will award approximately 2 marks for submission and documentation, 4 for
interface and interaction design, 15 for functionality and 4 for
implementation.
7401ICT students are required to implement image management. 2503ICT
students may implement image management.
Keep your solution simple. You will not get additional credit for
doing more than was requested.
Bonus marks
2503ICT students will receive bonus marks for implementing image
management.
All students will receive bonus marks for implementing a responsive design
that works well on phones as well as on computer monitors.
Bonus marks will only be awarded if most other requirements are satisfied.
Submission instructions
Note. Read and follow the instructions below carefully. Marks
will be deducted if you do not follow these instructions
exactly.
Solutions must be submitted to and must run on dwarf.
The due date for submission is midnight on Sunday 19 May
2013.
Late penalties of 2.5 marks per day will be applied.
Your assignment must be submitted by uploading
all relevant files to the directory
/export/home/sxxxxxxx/public_html/wp/assign2/
on host dwarf.ict.griffith.edu.au. (Here
xxxxxxx is
your student number.) Check early that you are able to do this.
The directory assign2 must contain all
relevant files.
Relevant files include all HTML files, all CSS files, all PHP
source files, all included files, all Smarty templates, any other
program files, all SQL files, all data files, and all documentation
files. Use logical and consistent file names and use subdirectories
appropriately.
The directory assign2 must not contain
any irrelevant files. Clean your directory before submission.
The documentation must be provided as an HTML file called
doc.html, in directory assign2. Microsoft Word
files are not acceptable.
When you are ready to submit, send a short email from your University
email account to the following addresses :
j.faichney@griffith.edu.au and dylan.prior@griffith.edu.au (Gold
Coast)
r.topor@griffith.edu.au and h.perrett@griffith.edu.au (Nathan)
This message must have following exact subject line
(for our email filters):
WP Assignment 2 Submission
The body of this message must contain the following items, each on a
separate line:
Your name
Your student number.
The full path of the directory containing the submission on dwarf,
e.g., /export/student/sxxxxxxx/public_html/wp/assign2/.
(Note that this is not a URL.)
The full URL required to run the submission on dwarf, e.g.,
http://dwarf.ict.griffith.edu.au/~sxxxxxxx/wp/assign2/index.php.
(If your home page is index.html or index.php you do
not need to include the file name in the URL.)
The full URL of the (top-level) documentation file, e.g.,
http://dwarf.ict.griffith.edu.au/~sxxxxxxx/wp/assign2/doc.html.
Other information
Plagiarism will be dealt with according to standard University
policy.
All use of work done by others must be properly cited.
Extensions will not be granted except for medical or other similar
reasons.