In this assignment, you will develop the ORM layer for our banking application. You will be provided with stub definitions for three classes representing customers, accounts, and transactions. These stub definitions are used to implement the RESTful interface used by your client-side interface code from assignment 5. You will use your assignment 5 solution to test your assignment 6 implementation. If you are unhappy with or did not complete assignment 5, you can copy my assignment 5 solution in order to test your assignment 6.
In order to setup assginment 6, do the following:
In order to complete the assignment, you should only need to modify the files in the model subdirectory. The files at the top-level implement the RESTful interface as documented in assignment 5. This interface relies on the classes defined in the model. All of the required methods have documented stub definitions. Your task is to provide an implementation for those stub definitions that matches the documenting comments. Each of the model classes includes a constructor that is private to the class and a forJSON method. You should not alter or modify these.
When the model classes are used by the RESTful interface code, the file ‘model.php’ is used to include the model classes. This file also properly sets up the DateTime class to use the correct timezone and calls “mysql_connect” and “mysql_select_db” in order to set up a connection to the database. This means that your code will not have to do this and that you can use the other PHP mysql library calls without worrying about setting up the connection. You should not need to modify model.php in
order to complete the assignment.
Although stub definitions have been created for all of the methods that the RESTful interface relies upon, you may need to create additional methods in the model classes in order to support your implementation.
In order to test your model implementation, you should be able to make a copy of your assignment 5 solution and simply change the base URL used to interact with the server-side back end to:
where <login> is your class login name. Be sure to make a copy of your solution and not modify your original solution since we may still be grading it. If you are unable to use your assignment 5 solution for any reason (i.e., it doesn’t work or you simply don’t like it), you are free to copy my assignment 5 solution found here. You will need to change the first line of ‘login.js’ and ‘account_view.js’ in order to set the base application URL as discussed above.
Although you will not need to set up the database connection, you will need to interact with the database by issuing SQL queries and handling results. To do so, you will need to know the details of the database design. The database for our banking application is implemented as 3 tables:
Below are the column details for each account. The columns are listed in the order required for a SQL insert statement. Each table includes an id column which is an auto increment primary key for the row.
The a5_customer table has 5 columns:
The a5_account table has 4 columns:
The a5_transaction table has 6 columns:
To create these interfaces, you will need to issue AJAX requests for application resources using the RESTful API described in the Application API section below.
The login.html interface should allow the client to provide an email address and a password. A button should also be provided that submits this information to the application’s authorization service (described below). Upon successfully authorizing the client, the browser should be redirected to the account_view.html interface.
The account_view.html interface should provide the client with the following information and capabilities:
If, while using the account view interface, access to account and transaction information is denied because you do not posses the correct credentials (i.e., you haven’t logged in), the client should be redirected to the login interface.
The base URL for the server-side of the application is:
All results are JSON encoded and the content type of the HTTP response will be set to “application/json”. All application resources can be accessed either using https or http (as long as you are consistent).
The following RESTful resources from the base path are defined:
Your interface should deal with errors gracefully by providing some indication of the error to the user and allowing the user to rectify the situation if possible (i.e., provide a party name, change the amount of the transaction, etc.).
Although not required, consideration will be given to additional interface functionality such as being able to sort transactions on different fields and paging transactions so that no more than a reasonable number show up at once.
Visit the page: http://wwwp.cs.unc.edu/Courses/comp426-f11/a5/model/setupCustomer.html in order to setup a test customer for yourself. This will obliterate all data associated with this customer (identified by the email address) and will create a new set of test data associated with that customer. Be careful not to step on each others toes (i.e., setup a customer for yourself to use associated with your own email address).
The test customer will have 3 accounts with an initial balance of $10,000. It will also randomly generate 200 transactions dated between 1/1/2000 and the current date.
subdirectory of your class web space called “a5”.
For this assignment you will develop a RESTful interface for an on-line banking application. You should develop a separate controller for each of three different resource types:
Create three PHP files to act as controllers named customers.php, accounts.php, and transactions.php. Place all files in a directory named “a4”. You should support the following URLs and HTTP methods (NOTE that for all of the URL paths below, the base path to your class web space and the specific “a4” directory where the files are located is assumed and is not shown in
the paths listed below).
Your code should appropriately validate any URLs and parameters and generate unsuccessful responses as appropriate. For example, an attempt to retrieve the details of a customer that does not exist should result in a “404” response. Amounts or dates that do not make sense should also result in an error. You should use the PHP built-in function json_encode in order to generate the JSON representations. You can use the AJAX Console to test your PHP scripts.
Your code should interact with the PHP classes defined in a4-model.php as demonstrated in class. You should make your own copy of the file in your “a4” directory. You can use the AJAX console application demonstrated in class in order to test your controllers. Remember, because the code in “a4-model.php” does not actually store any data permanently, your controller for creating a new transaction will not result in a permanent change to the model.
HINT: When constructing JSON representations for dates, you will need to use the DateTime object’s “format” method to generate an appropriate string representation. Similarly, when receiving parameters that represent dates, you should create new DateTime objects that correspond to those dates in order to be able to compare them with any properties in the model that are represented as dates.