[ »Simplified Navigation ] [ »Dynamic CSS ] [ »Random Thoughts ] [ »SOAP, XML, Perl, MySQL ]

What's Behind This Website?

This MaxText website uses several different technologies to achieve its goals.

» CSS
» PHP
» Perl 		» MySQL
» SOAP
» XML

An explanation of how each of these was employed follows.

Top

Simplified Navigation

PHP has been a wonderful tool to simplify the coding of the left-hand navigation. I have opted not to use images in the navigation pane, mostly because they aren't easy to maintain. If a new menu item is needed, it can't be implemented without first creating a button image. Moreover, navigation buttons can be slow to load.

Therefore, the MaxText navigation is more or less text-based. Using the CSS effectively, I can achieve dynamic mouse-over effects without using Javascript (and more navigation button images.)

It is not unusual to see "brute force" techniques applied to get such navigation, whereby each item in the text-based navigation is hand-coded. Tweaking the look-&-feel of the navigation formatting requires each item to be edited individually to achieve consistency.

Instead, I use a PHP array to store the exposed name and the underlying URL. I then have PHP loop through the array and auto-generate the HTML for the navigation when the page is loaded.

I can use the same array to generate navigation that has:

These options are still primarily text-based, which facilitates maintenance and navigation changes.

Regardless, my navigation is compartmentalized into its own file. I then use the "include" command on all relevant pages to have this file inserted into the content when they are loaded. This is one of my favorite commands because it removes clutter and distractions from the content of the individual source files. It is very similar to the link command for CSS so that it doesn't have to be embedded.

The advantages:

Macromedia Dreamweaver employs what they call templates which also helps with the write-once/reuse-many-times paradyn. What I don't like about their templates are:

Top

Changing the Look-&-Feel with a Dynamic CSS

I've been in many situations where a seemingly small request from an influential person had huge ramifications in the documentation. Things like:

I've learned to steer clear of such problems by making more efficient use of my tools.

In the case of the Bells & Whistles look-&-feel functionality, I created it for my own use to help me compare quickly color and font options. One thing led to another, and I ended up inserting it into the navigation. It is one file which PHP includes into the navigation file, so can be backed out easily when I tire of it.

It works by defining PHP variables for colors, fonts, and images that get populated from the web form in the navigation pane. The normal CSS file was turned into a PHP file with key style elements defined from those variable values. This PHP-based CSS file then gets included into a common PHP file used by the entire site. When any page is loaded, the CSS information gets inserted directly into the generated HTML page but with the variable information resolved.

I would have preferred to keep the generated HTML cleaner by using a one-line link to a CSS file. Its problem is that external CSS files aren't run through the webserver's PHP processor to resolve the PHP variables. On the other hand, if the full content of the CSS file is included within a page, such PHP variables can be resolved. The compromise is that my PHP source files can remain clean and the CSS information can still be compartmentalized in its own file, while the HTML generated on the site becomes somewhat verbose with CSS style information.

Top



 

Random Thoughts
 

Top

Getting the Random Thoughts

The workflow for getting the random thoughts included on each page is rather complicated. Although it was an intellectual exercise to prove that I could do it, it wasn't without some real-world significance and money-savings. Specifically, MaxText was not established at the ISP with access to a database like MySQL, while another website under my control was. To get MySQL on MaxText would have meant yet another monthly fee. Just as importantly though, the information I wanted to display was needed on the other site as well. Even if MaxText had direct access to MySQL, did I want to duplicate the information in another database? No.

So here's the workflow for getting a single random quote displayed on a MaxText page:

  1. A given parent PHP page on the site includes a PHP file with the "Random Thought" (RT) information. The parent can pass in variables to the RT file, such as the number of quotes to display. This in itself could have come from the Bells & Whistles forms included in the navigation page.
  2. The RT file is pulled into select PHP pages with an include statement.
    • It contains some basic HTML formatting.
    • It defines an IFRAME, which has the ability of created a frame-within-a-page that displays different content. Perfect for the RT.
    • The information passed-in for the number of quotes is used to help size the IFRAME.
    • The IFRAME calls a CGI script with the quote information. This script is called the client application.
  3. The client application performs several preparation tasks:
    • It parses any incoming variables, such as the number of RT to output.
    • It generates a SOAP request for a server application, making sure it includes any information that needs to be passed along.
    • It sends the SOAP request over the Internet.
  4. The server application resides on another webserver that has access to the MySQL database. The server application performs several tasks.
    • It receives the SOAP request.
    • It parses any variables passed in, such as the number of RT to collect.
    • It generates an SQL statement applicable to the request.
    • It sends the SQL statement to the MySQL database.
    • It retrieves the results of the database call.
    • It parses the database results and formats it into an XML packet.
    • It sends a SOAP response with this XML packet of database results back to the client application.
  5. Then the original client application continues with its operation by performing several more tasks.
    • It receives the SOAP response.
    • It parses the XML packet into its own internal data structure.
    • It generates the HTML tagging and formatting for each item in the XML packet.
    • It outputs this to the IFRAME.

This workflow could have been simplified on the client side, in that newer PHP versions support the SOAP protocol. However, my ISP has not installed these PHP versions. Their Perl installation, on the other hand, does include modules for SOAP.

It is not possible to have a CGI Perl file generate PHP code and have that code executed by the PHP processor, because the CGI bypasses the PHP processor. Likewise, a PHP file is not designed to kick-off a CGI script automatically and have the CGI and PHP content appear side-by-side. If my ISP's PHP installation would have supported SOAP, it would have been a non-issue. Given that my pages are PHP, my SOAP interface is through CGI (Perl), and the goals of the "Random Thought" feature, the IFRAME element was a convenient tool to get CGI content embedded within a PHP page.

The most difficult aspects of this implementation were:

Just because I program something and test it on the Apache web server installed on my home computer, doesn't mean that I can plug it into my ISP's environment and expect it to fly without some modifications.

Top