With the simplest of tools, I created a set of dynamic web pages. The tools I used were a sparse set of lean text files for content, one template page and all augmented by some anorexic php code. It's my propensity to experiment hastily pasting in rash changes that some times I soon rue. Nonetheless, my making such mistakes were the source of my determination to implement the subset of dynamically driven web pages described here.
The aforementioned experience changed my direction as a developer. That outcome was positive for me. Finally,I can recommend these techniques to others that have a similar conditions on their site.
My efforts creating my new site began shortly before the plug was pulled on Open Source Today. The first tasks were creating a better overall design and pulling over my coding articles. I had reached the stage where I had tired of exclusively hand coding. These tasks had become too labor intensive and repetitive. I was primed to take a completely different course. I even thought I too would soon be using a web designer, code generator. I was open to radical change.
In haste to make an impression while beginning to make contacts to do other sites commercially, I found it too easy to take the wrong paths. Some errors were easily remedied by just reversing or dead ending the process. Others that were too hastily applied, such as pasting of mistaken code too many places was not amenable to the easy fix. The latter was the impetus to my embarking on creating a set of dynamic web pages.
My site uses a near common set of web pages as its external face. They differ in their use, i.e. content and appearance. I control the latter by connecting the specific div tag structure to different classes or instances [the "id"]. These pages are the home, site info and, the focus of this article, the menu pages. They all resemble the graphic pictured below:
Figure 1 Web Page Structure showing all [most] floating div tags
Let's start with the hard coded regions. The header that is fixed with the site logo on the left (oops within another floating div, not shown) and centered is the site title name. On the right center column the Google ad script resides in all these templates. Only on the main page the central main column has fixed content, on every other template and all other regions the content is called upon display.
It is important to recognize that much of the home page was altered to contain dynamic content, much of which is duplicated on the other two extant templates. The upper left column holds the logo list, the lower corners in the footer contain calls to fairly constant components, i.e. the contact and credits and the Firefox link on the left and right, respectively. The central portion of the footer contains variable content such as a navigation bar to all the menus and some text. In the center column resides the main content that comprises the page. This location is highly variable and is all open to subsequent alteration.
Prior to implementing the dynamic form of the menus, five to six existed as separate static pages. Much of the common code was lifted from these pages. They too were using common external content. Moving this to a common template requires passing its identity from the menu choices on the home page with the GET variable attached to the link. If you are not familiar with this option, see it as simply as ending the link with a question mark followed immediately by a variable and it value. Mine looks somewhat like this:
http://[site]/[path]/[menu-template].[ext]?item=[code]
Most of descriptive text within the brackets should suffice. However, you may wonder about the extension [ext]. I am forced to use "php" rather than the expected html, otherwise my php code does not fire.
I made larger changes in the head(er) tag section. The first action is to identify the menu and then loads the proper files. The first line identifies the menu. Then it needs to know where the content files reside, i.e. the path variables. Before running too far ahead, here is what the code looks like on the menu template page in the head(er) section:
<head>
<?php
$get_it = urldecode($_GET["item"]);
$menu_meta = $_SERVER['DOCUMENT_ROOT']."/[path]/menus/meta/";
readfile($menu_meta.$get_it.".txt");
...
?>
Let me show you one example of these files and talk just a bit about their content:
<title>Tags Coding Menu</title>
<meta name="description" content="Primarily articles describing
hand coding techniques applied to several html tag types, e.g.
div and others along with their associated style code in the
css files." />
<meta name="keywords" content="html tags, div tag, hand coding
html and css, web page coding" />
<meta name="pagename" content="How To Listings" />
<meta name="date" content="March 21, 2008" />
If you look up at the code you can see when the variable value sent by the GET is "tags", the file content is read and those are the lines inserted. My remaining meta tags and link to the cascading style sheet (css) file are hard coded into the template. The ellipse just under the readfile implies there are lines of code I am not showing. Most are the paths to several content and graphic files locations. Indeed they are just pasted copies taken from the home page template. Moreover, some are not even required. For now let it suffice with my saying to you there is more code in the head(er) tag region and there may be more than I mentioned.
The other regions of the menu page have nearly the exact content as on the home page a bit less. The only major difference is in the central center column, were the menu links to individual articles are listed.
Let me first give you the structure of the central columns:
<div id="col-left-bst">
//Logo list
</div> <!-- Left hand column end -->
<div id="central-col-bst">
// Specific Menu code
</div> <!-- End of central B/ST column -->
<div id="col-right-bst">
// Google text ad
</div> <!-- End of right B/ST column -->
The only code of interest here is the menu code, so let's forget the rest. Here is an exact copy of the central column code:
<div id="central-col-bst">
<?php
readfile($menus . "/menu-list-".$get_it.".txt");
?>
</div> <!-- End of central B/ST column -->
Of course, the section heading was ironic. That's the code, brain numbingly simple, yet it works reliably. Finally here is an example menu, this time the Templates that has two advantages: simple than many and is likely to remain unchanged:
<h2 id="prod-news">Templates Speed <br />Web Page Creation </h2> <h5> <a id="hand-coding" name="hand-coding">Hand Coding </a> html and css files</h5> <h2> <a href="http://www.ermel.org/handcoded/"> <img src="http://[site]/[path]/handcode-frk.jpg" width="114" height="31" border="0" alt="100% hand coded HTML" / > </a> </h2> <h3>____________________________________ </h3> <h3><a href="http://[site]/[path]/HowTo-html-Coding-Templates.html"> Web Templates</a><br />Static Pages</h3> <h3><a href="http://[site]/[path]/HowTo-Coding-Templates-II.html"> Web Templates - II</a><br />some Dynamic Content</h3> <h3><a href="http://[site]/[path]/HowTo-Coding-Templates-III.html"> Web Page Templates - III</a><br />some Dynamic Content</h3> <h3>This ends web page templates as a separate topic<br /> further discussions will be found in Dynamic Content<br /> and the Tags Sections</h3> <h3>____________________________________</h3> <h6><a href="http://[site]/#back-template">Home</a></h6> <h6>Last update April 08, 2008</h6>
Simple text read from a file at run time. It's hard for me to think of a simpler model. So there it is, try something similar, I think you will like the limited effort required and the reliability.
I must admit I have not been completely candid with my readers. Yes this is the way the code was functionally working but it was not the way I wrote it. Any programmer with a modicum of experience knows that s/he cannot assume even seemingly perfect code will always work without error. So in my php code I attempted to catch likely mishaps, where the passed variable value in the GET string is not recognized or matched to the correct text files. Unfortunately, I failed to get the code to function properly. I got syntax errors where the obvious solutions eluded me. Thus, I had to live with the simplified code until I saw the viable method to execute the failing error code.
Even with the new approach, I found the redirection to a custom error page not completely satisfactory. Somehow an syntax error was encountered before the the system jumped to the new page. Ironically, upon writing this article I now think some new code might solve this problem. But my interest in redirection to a common error page has faded. If you believe my suggestion has merit, you could apply the suggested solutions. Instead of a separate error page, I opted to use the menu form to display the error message and to solicit the user's input. In addition to this error handling pages I also added an automatically generated email notice to the webmaster. While all the aforementioned code has been tested it has not yet been applied to the site.
Once again I stress for every advance and insight more questions arise. When I began this write up I thought I had a neat division between the simplest code and a second that would have described my error catching. Instead I see three distinct topics all involving error trapping, but requiring focused, separate write ups on each. As I advised in my early articles, re-examine your assumptions and be prepared to correct your infractions. I too am guilty and I have much to redo.
Corrections, suggested extension or comments write: How-To-Guy. If the mailto does not work, use this: hcohen[-At-]bst-softwaredevs.com.
© Herschel Cohen, All Rights Reserved