Your Pointy-Haired Boss is back and wants you to add a header and footer band. He's hired a graphics design consultant who came up with a page that looks like this:
As software developers, we should get accustomed to looking at unrendered pages:
<html>
<head>
<link rel="stylesheet" type="text/css" href="../css/css490.css" />
</head>
<body>
<div class="logo">
</div>
<hr class="logo" />
<div class="menu"><p>
Home | Time | Logout | About Us
</p></div>
<p class="time">The time is now <span class="time">6:58:48 PM</span>.</p>
<div class="menu"><p>
Home | Time | Logout | About Us
</p></div>
</body>
</html>
The graphics designer conveniently provided a CSS style sheet for your use.
Before you rework the web site, it's time for a little refactoring...
Templates simplify site maintenance by letting you put the common parts of a page into a single file and invoking it with parameters defining page-specific contents.
In general, templates are simply text files containing markups. The library loads the file at run time and provides an interface for rendering the markups.
There are two benefits to using template files:
The Go standard library provides two separate template modules under
text and html. Use the
html template library.
Save your template files under the
templates
directory in your workspace.
Add the
--templates
flag to your program, since the directory holding containing your
templates file will be something you're going to want to configure
at runtime.
This is a refactoring step that does not introduce new functionality. The purpose is to make the next change easier.
Don't forget to check all files into Git.
After you've implemented the new look and feel, your PHB realizes
that the keywords
Home,
Time,
and
Logout
in the upper and lower bands should be links to the appropriate
pages within the site.
Under the Don't repeat yourself principle, you should only have a single copy of the menu to maintain.
Note that activating the menu is a discrete unit of work and should get its own git commit.
If your solution to assignment 2 is contained in a single source file now would be a good time to factor out the cookie management into a separate module.
Port the code to display UTC time from the assignment-01 branch to the main branch.
Logging remains the best way to analyze the behavior of a system, but there are two problems that must be managed. Logging may produce mass quantities of output and the voluminous output may reduce the performance of your program as the I/O and other operations.
A more sophisticated approach to logging divides log messages
into to various classes or levels. A typical classification of
severity levels may include keywords
critical,
error,
warn,
info,
debug.
and
trace.
Configuration options allow the choice of what level of logging to perform. Typically during development and testing, all levels are enabled. When a program is deployed to production, debug messages are typically disabled1.
Additionally a good logging system may use languge features such as reflection to include source information such as function and line number.
Download the logging package from Cloud Instruments Repository and add it to your git repository. Make sure that you read read and comply with its license.
Rework the print statements you did for assignment 2 into log messages2.
Add a command-line flag
--log
to specify the name of the log configuration file.
Write an XML configuration file so log messages will display tab-separated fields
the
Save the configuration file under the
etc
directory of your workspace.
Submit a tarball of your
.git
directory. Your
README
file should tell the reader how to proceed.