Page Architecture

When we put together our site files, we wish to retain as much flexibility as possible, while maintaining a single location for making site changes.

To accommodate this apparent contradiction, we can use include files to house recurring HTML elements, CSS styles & code.

Insulate Structural HTML: An advantage of using includes is we can remove all structural HTML from our pages.

Basic Document Structure: On a typical web page, just as in a word processing document, we frequently find a header and a footer. The header & footer areas provide the context for the page.

What goes between the two identifies (makes unique) the specific document. If the top and bottom of a document are the header and footer, what goes between can be called the guts. When we work with a page, this is the area we would like to concentrate on.

Maximize Content Of Includes: When we decide how much to include in our header/footer files, we find out that it pays to include as much as possible inside these files. The more code that remains inside the the includes, the less coding is required to make site wide changes.

Placing all structural HTML inside the header & footer allows us to go from div to table based design (or vice versa) as needed. It also allows us to more easily accommodate other devices, as the header & footers can be swapped out dynamically inside the include files.

Guts/Identity: The traditional 'center' of the page, sometimes called the 'guts' in a design (in relation the words header & footer) is what distinguishes any page from all others. For example, a 'links' page features different information from an 'about us' page. For lack of a better term, you'll hear me use the word 'identity' to define this area, and in fact the entire page. The purpose of a page should be clearly defined, and that purpose gives the page an identity. All visible elements of the page should contribute to this identity.

Templates: The word template exists in various contexts. If we go back to the word processing document concept, a template provides a model from which to start. It provides a starting point from which related pages are created. Starting from one template allows us to focus on the identity of the page, without concern about behavior of the context, the header and footer.

Structural vs Functional Includes: Not only will we include files that house structural HTML, we'll also include files that house functions, objects and other code we can re-use across all site pages. This saves time in deploying and refactoring (repairing)

Wrapper Functions: Programming languages have strengths & weaknesses. Where we anticipate a 'weak' or potentially vulnerable point in the code (for example, session handling in PHP, or filtering user input in many languages) we can decide to 'wrap' other functionality inside our own functions. In this way we can adapt the code in a vulnerable area from one place. The downside of a wrapper is the documentation must be very clear so others will know where to make changes in the code.

Code File Storage: While it would be nice to include a 'kitchen sink' of code in a single file, this could be too much of a good thing. If we place all utility code in one place we run the risk of overly confusing developers as the code base grows, and even of inhibiting performance. Further, as pieces are moved in and out of the architecture in refactoring it may become harder to identify where changes need to be made.

Code Include Identification: For the purposes of our class demos, we have split the code 'include' files into the following identities:

1) Configuration (configINC.php) Global variables and site wide settings are placed in one file. This way the email address of the developer in charge can be changed quickly and easily, minimizing possibility of damage in more code intensive areas.

2) Connection (connINC.php) Placing all code related to connecting to the database allows us to secure potentially dangerous database credentials in one place.

3) Utility (utilINC.php) This file becomes the one included file in our pages. This is because configuration and connection are brought along in a 'come along' fashion because those 2 files are in turn included in the utility file, at the top of this file. The utility file further includes all our favorite custom functions for PHP processing.

Page Architecture: In light of the above information, view the following diagram of our page architexture:

Code Sequence: The structure above indicates the sequence (1-4) in which the files much appear to achieve our goal. Since PHP is a procedural (linear) scripting language, the sequence of the code is critical. While functions & objects can be called as needs at any time, where they are called in the sequence of the HTML can cause problems. For example, we process a 'header' file, including the 'title' tag, the contents of the 'title' are not known, as the identity code has not yet been processed. In PHP we can address such issues by using a callback function.

Callback Template: PHP allows us to 'buffer' our code, and do a search and replace on the title tag for instance, before the code is delivered to the browser. This is how we can place any finishing touches on any part of the page, before producing output: PHP Callback Template