Website Architecture

At this point, we know how to output html from PHP, how to use the control structures available in PHP, and a little about how to make data permanent (on a hard drive somewhere) in PHP.
Before we continue talking about databases, I thought it would be useful to talk about how to organize your web applications as you are developing them.
A common approach is to use a variant of the Model-View-Controller (MVC) design pattern.
We split the project into different types of files (later we will use classes) which we might put into different project folders: views, models, and controllers.
views folder files are responsible for drawing web pages. They should mainly be HTML with little or no logic. They may have functions like those from earlier today which take data created elsewhere and draw it in the content of an HTML page.
controllers folder files contain the logic of the application. Code here should not touch permanent storage directly nor should it render HTML.
models folder files contain code to read and write data from the file system. It shouldn't contain logic related to the web app or render things to a browser.

More Website Architecture

In a traditional MVC set-up, a user sees a view, manipulates the GUI, which causes controller functions to be called. These functions in turn make models calls to read and write storage. If storage is written then the model might call view functions to update what the user sees.
In web-development we often use a slightly different MVC set-up known as Model-View-Adapter or mediating-controller MVC .
Here the user points his browser at a web page. Typically, this is set up to always hit the same index.php page.
From the request query string, the index.php determines a controller to use and a function in that controller to call.
This controller function uses the request to determine which model calls to make to read and write storage.
Based on the above, the controller function, determines which view is appropriate to send back to the user and intializes any data it may need.
The controller then calls the appropriate view render function to draw the web page the user will see in his browser.
Notice this is different from MVC in that the controller invokes both model and view methods. In traditional MVC, we have controller function invoking model functions which in turn invoke view updates.

Our basic set-up for website interaction so far is:
1. User comes to initial page of web-site.
2. A default web page (the landing page) for the site is served, either using a static HTML page or a with minimal PHP intervention.
3. The user clicks links or enters form data to navigate around the site.
4. No dynamic processing happens on the client.
5. On the server, a controller processes the link or form data, uses session information, gets/sets database information using models, and chooses a new view to display.
In choosing a form whether it should use method GET or POST, ask whether the result of processing the form data should be a bookmarkable location?
If it can be, use GET; otherwise, POST.
For forms that do things that we don't want to be repeatable with the same information, like purchasing items, posting comments or blog entries, etc., we should use POST.

When you click the reload button on a page that is the result of a POST'd form, or use the back button to cycle through pages where forms were POST'd, your browser will typically ask if you want to resubmit the form data.
Not only is the back button somewhat broken by this, people have a nasty habit of clicking okay on any dialog box that pops up, which can result in a re-purchase, re-blog post, etc.
To solve this problem, we use a web design pattern known as POST-REDIRECT-GET.
The idea is when POST is used for the form:
```
<form method="post">

<input type="submit" name='submit button' value='submit' />
</form>
```
we process the data in the receiving controller. Rather than choose a view and display it, we instead, output a 301 redirect, location header to some safe page. In PHP, we could do this with a line like:
```
<?php
header("Location:http://somewhere.safe.com/");
```
When the browser, goes to http://somewhere.safe.com/, it will use GET to request the page.
Because the POST'd form data resulted in a redirect, the get location only is stored in the browser history. So now going back through the history using the back button will go through this same page and before this the page where the form was initially blank.

Write a script StoreGold.php which outputs an HTML page with a form that uses method POST. Do not have an action.
On your form, have a text field with label Amount of Gold: and a submit button "Put Somewhere Safe".
If the StoreGold.php script see data posted from your form, it adds the Amount of Gold POST'D to an integer stored in gold.txt and redirects to SafeStorage.php
SafeStorage.php outputs a HTML page with Total Gold Stored on it followed by the amount in gold.txt.
Verify that the back button works for this page.
Post your solution to the Mar 10 In-Class Exercise Thread.