HW#3 --- last modified October 17 2022 22:41:45.

Solution set.

Due date: Nov 2

Files to be submitted:
  Hw3.zip

Purpose: To write an application that uses databases and uses the MVA design pattern

Related Course Outcomes:

CLO3 -- Write server-side scripts that process HTML forms.

CLO5 -- Develop and deploy web applications that involve components, web services, and databases.

Specification:

For this homework you will develop a monster underwriting app to satisfy the insurance needs of monster's of all shapes and sizes.

Here are the requirements for your project:

1. Your Hw3.zip folder has a readme.txt file with all the names and ids for your group.
2. All the web pages you output validate as XHTML 5.
3. Your project is written using namespaces. You only create variables, arrays, objects, define new classes, etc. in the namespace cool_name_for_your_group\hw3 and subnamespaces thereof.
4. Your project directory structure and urls that are linked to by your project are as follows:

   index.php -- entry point into your project. No other file in your project is directly linked-to.
       All urls used as links by your project are in the format (including links to images):
       BASE_URL/index.php?c=name_of_controller&m=name_of_method&arg1=value_for_arg1& ...&argn=value_for_argn 
   src
    |-configs |- Config.php contains a class with constants for things like 
    |         |       database user, password, host, port, etc. Basically, 
    |         |       it should have anything you think the grader might need
    |         |       to get your program running on the grader's machine.
    |         |- CreateDB.php can be run from the command-line to make a good initial
    |                database.
    |-controllers -- contains all the controller classes you write, one per file
    |-models -- contains all the model classes you write, one per file
    |-resources -- contains any resources used by your app such as images
    |-styles -- has any external stylesheets you need
    |-views -- contains all the view classes you write, one per file
         |-elements -- contains all the element classes you write, one per file
         |-helpers -- contains all the helper classes you write, one per file
         |-layouts -- contains all the layout classes you write, one per file    
   

5. Typing php CreateDb.php while in a shell in the configs folder creates an initial Mysql Database with tables created in BCNF. The tables' schemas is reasonable for storing and retrieving any data similar to that given in the mock-up views above.
6. Your project defines base classes: Controller, Model, View, Element, and Helper. The namespaces for these and their subclasses should be respectively: cool_name_for_your_group\hw3\controllers, cool_name_for_your_group\hw3\models, cool_name_for_your_group\hw3\views, cool_name_for_your_group\hw3\views\elements, and cool_name_for_your_group\hw3\views\helpers.
7. Your project uses the Model View Adapter pattern that we have discussed in class. This item is for overall how well you succeeded at this. What this means for particular classes will be described in the next several points.
8. Only controller classes directly handle request/form data. Controllers use this information to invoke model methods that make database calls to get/set/update info in the database, then choose a view, instantiate it, and call its render() method to display a web page back to the requesting browser.
9. Only subclasses of Model interact with the database. The base Model class has methods for performing the initial connection to the database. Model classes have methods to marshal a particular kind of object from one or more tables, and to take already created objects and unmarshal them persistently into the database.
10. Only subclasses of View, Element, Helper, Layout are allowed to render HTML. Each view is used to render a particular kind of whole web page. Elements are used to render a particular portion of a web page that might occur on several kinds of web pages (for example, a navigation block). Helpers have methods which make it easy to output the HTML for particular kinds of widgets (say a method that takes an array and uses it to output the HTML for a dropdown with the elements coming from the array). Layouts are used to output common header and footer HTML that might be used by several views.
11. On the Landing page and the Policy Type pages, Policy Type links take one to the page of the appropriate Policy Type page
12. Policy links take one to the appropriate Display Policy page. Next to a Policy link is the date on which that meeting will happen.
13. The main landing page Popular Policies contains the three most viewed policiess from most viewed occurring to least.
14. [-] links next to a Policy Type only appear on the landing page and indicate the Policy Type currently doesn't have Policies. Clicking the link deletes that Policy Type. [-] links next to a particular Policy link only appear on Policy Type pages. Clicking this link deletes the Policy. As [-] by itself doesn't say what this link does, you should implement some way of making these links WAI compliant.
15. Links on each page main heading take one to the appropriate policy type or the landing page. I.e., in Monster Underwriters/Lair, the Monster Underwriters link takes one to the landing page, the Lair link takes one to the Lair policy type page.
16. On a Policy Type page, all policies for that policy type are listed in alphabetical order. Sorting is done at the database query level, not after the data is retrieved.
17. Policy Types are always listed in alphabetical order. Sorting is done at the database query level, not after the data is retrieved.
18. The link to the New Policy Type page is only on the landing page. The New Policy Type page allows a new policy type to be added to the list of current policy types. If the name is blank, or sanitizes using filter_var to blank no new policy type is added. In both cases, after the action is performed the current landing page is shown.
19. The New Policy page allows a new policy to be added to the current Policy Type. The link to an New Policy link does not appear on the landing page, but does appear on every Policy Type page. On the new Policy Page, the Save so far stores the data that is on the form into a session. If the user navigates back to the page the session info should be used to populate the fields. Clicking Done saves the policy details to database tables provided the Title, Email, Duration, and Description are all non-empty after sanitization with filter_var. On successful completion the user is returned to the landing page, otherwise, the user remains on the New Policy Page.
20. The Display Policy page shows a previously created policy as illustrated in the mock-ups above.

Point Breakdown