Templates: Separating Programs from Design
If you are running a small web site, then you are probably responsible for everything—server administration, the site's content and the CGI programs that produce variable and dynamic content.
If your site is of any significant size, the work is probably divided among a number of people. Indeed, most large sites divide their staffs between the people who are responsible for the site's content and design, and those who are responsible for the infrastructure and technical side of the site.
Such a division undoubtedly makes it easier to administer a site. After all, it is much easier to find someone to write content or to write CGI programs than to do both. In addition, splitting the work according to function allows everyone to do what he does best.
At the same time, such a division makes it difficult for sites to maintain a uniform presentation style. CGI programs produce HTML that must match the style of the rest of the site. This might mean inserting a certain header at the top of each page, using a particular background color or inserting a graphic on the side of each page.
In other words, there are two separate sources for HTML content on a web site. The pages of HTML created by the designers, and the HTML produced by the CGI programs. If a site does not change its style often (or at all), the fact that the HTML comes from two sources does not matter. The designers establish a style for the site, which is then adopted by both designers and programmers for their work.
However, many sites have taken to redesigning every few months, partly due to continually improved technology that allows designers to create more interesting, exciting experiences on their sites. Every time a site's design changes, all of the existing content must be rewritten to fit the new design. Sites that have split their content between programmer-generated HTML and CGI-generated HTML will find themselves having to convert two types of files with two separate staffs.
For example, let's assume that a site has standardized white-on-blue text. Each time the designers create a new page, they make sure to include a <body> tag of the form:
<body bgcolor="blue" fgcolor="white">
In order for the site to have a uniform look, all of the CGI programs on this site must include a similar <body> tag at the top of their output. Here is a basic “hello, world” page that demonstrates how to accomplish this:
#!/usr/bin/perl -w use strict; use diagnostics; use CGI; # Available from http://www.perl.com/CPAN # Create an instance of CGI my $query = new CGI; # Send an appropriate MIME header print $query->header("text/html"); # Begin the HTML, with our colors indicated print $query->start_html( -title => "Hello, world!", -bgcolor => "blue", -fgcolor => "white"); # Send our message print "<P>Hello, world!</P>\n"; # End the HTML print $query->end_html;If this program were run as a CGI program from within a web server, it would produce a short page of HTML on our screens, with a the text appearing in white text on a blue background. (And yes, we should use hex codes for consistent colors across platforms, but this is just meant to be an easy example.)
After creating an instance of CGI (an object module freely available from CPAN at http://www.perl.com/CPAN), the program sends a MIME header indicating that it will be sending HTML-formatted text to the user's browser. Following that MIME header, it sends a <body> tag, hidden somewhat by the start_html method that takes care of such tag production for us.
Finally, we send our short message, marked up in HTML, and invoke the end_html method, which sends a </body> tag to end the body of the HTML text and an </html> tag to indicate the end of the HTML page.
What happens when the designers decide that white-on-blue text is passe, and that they would rather have a more modern look (along the lines of Wired magazine) with orange text on a green background? It would not be very difficult for the designers to perform a global “search and replace” on the <body> tags appearing within the HTML files on the site. To modify each of the CGI programs on the server is much trickier.
One solution is to put all of our design-related variables in a library module that we can import into our programs. Here is an example of such a module called SiteDesign:
#!/usr/bin/perl -w package SiteDesign; $background_text = "white"; $foreground_text = "blue"; 1;
The above module is named by the package statement. Following that statement, variables and functions are assumed to begin with the string SiteDesign::. To avoid problems with the package names when variables are imported into a program, we have turned off the normally helpful construct use strict.
Assume that the above code is placed in a file named SiteDesign.pm, and the file is placed in a directory named by the special Perl variable @INC (the list of directories in which Perl modules are located). Our programs should now be able to include this library with the statement:
In other words, we could rewrite our “Hello, world” program as:
#!/usr/bin/perl -w use strict; use diagnostics; use CGI; # Available from http://www.perl.com/CPAN use SiteDesign; # Create an instance of CGI my $query = new CGI; # Send an appropriate MIME header print $query->header("text/html"); # Begin the HTML, with our colors indicated print $query->start_html( -title => "Hello, world!", -bgcolor => $SiteDesign::background_text, -fgcolor => $SiteDesign::foreground_text); # Send our message print "<P>Hello, world!</P>\n"; # End the HTML print $query->end_html;This code is certainly an improvement over the first version of our program, in that the HTML produced by our programs can be changed without having to modify the programs. Existing CGI programs do have to be changed so that they make use of SiteDesign.pm—but you only have to change your existing code once, rather than each time the site's design changes.
This approach is useful in many ways, but it does not solve all of the problems. While we have reduced the amount of work that a site's programmers need to perform each time the designers change their minds, we have not eliminated it entirely. The designers still have to come to the technical staff each time they wish to make such changes.
Furthermore, there is a practical limit to the number of ways in which we can affect our programs' output by setting variables. We could add a variable indicating which image, if any, should be displayed at the top of each page, another variable indicating whether an image should be displayed at the bottom of the page, another variable indicating the font size, yet another for whether the first paragraph should be centered, and so forth, ad infinitum. Sure, it would still be easier to change these variables than to change the output of each CGI program, but this solution does not scale well to a large number of variables. Would you want to be the programmer asked to modify 30 configuration variables each time the site's design was changed?
One possible solution to this problem is to put the variables in a configuration file, similar to the quiz file that we have discussed over the last few months. Such a file, particularly if it were masked by an interface consisting of CGI programs and HTML forms, would allow designers to modify the site's design without having to bother the programmers. However, designers would still have to deal with the large number of configuration variables, as well as understand what they mean. And programmers would still have to write code taking all sorts of styling possibilities into account.
In other words, the use of variables to indicate styling is better than nothing at all but is far from a perfect solution. What we would like is a way of creating pages of HTML that could be modified by designers, and also gives the possibility of executing code within those pages of HTML.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Returning Values from Bash Functions
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide