Over the past few months we have looked at Bricolage, an open-source content management system (CMS) based on PostgreSQL, mod_perl and Apache. Bricolage has gained a good deal of mind share in the last few years, partly because of its open-source license, partly because of the open-source technologies on which it is based and partly because its feature set is comparable to many proprietary CMS packages, to say nothing of the open-source CMS offerings.
This month, we conclude our tour of Bricolage with a look at its use of templates. To date, we have looked at a number of the administrative and editing capabilities that Bricolage brings to the table, but a CMS is useful only if you can customize its output and make the resulting Web sites appealing.
HTML templates have existed for quite a long time, and they are a nice compromise between static pages and putting HTML inside of a program, which makes it inaccessible to a designer. If you want an HTML page to change dynamically, using templates is a good way to go.
Of course, this raises the important question: which templates should you use? Hundreds of different templating systems exist, including several dozen written in Perl. Some of these, such as Text::Template, are not HTML templating systems per se, but they have been used with great success on a variety of Web-related tasks.
Which templating system you should use is a debate rivaled only by Linux/BSD and Emacs/vi discussions. Luckily, Bricolage rises above the debate, coexisting happily with both HTML::Mason and the Template Toolkit. It theoretically is possible to use another templating system, but these two are popular and powerful enough that they appear to satisfy many Bricolage users. I personally prefer HTML::Mason and demonstrate Bricolage templating with Mason, but if you are a Template Toolkit fan, feel free to use it instead.
A template is a generic outline for the content of a page of HTML. Everything is considered to be static, except for variables, whose values are filled in (interpolated, in the language of programmers) at runtime. For example, consider the following template:
<html> <head> <title><% $title %></title> </head> <body> <h1><% $headline %></h1> <p><% $body_text %></p> </body> </html>
The above template, written using Mason syntax, always has a title, headline and paragraph. The contents of the title, headline and body text, however, are variable.
Mason also provides two global variables: $r, the standard mod_perl object that gives us access to the internals of our Apache server through its Perl API, and $m, the object that provides additional information about the overall Mason environment and the current, specific Mason template.
Bricolage introduces three new objects into this mix. The most important is $story, which contains information about the current story. Stories contain elements, which can themselves contain additional elements; the current element is available using the object $element. Finally, Bricolage sends pages to an output channel (normally, but not necessarily, to a Web site) using a mechanism known as a burner.
Before we continue, it's also important to understand Mason's autohandlers, which make it possible to give a site a unified look and feel. If an autohandler exists for a particular directory, then the autohandler always is going to be invoked instead of a file in that directory. That is, if you request /abc/def.html and /abc/autohandler already exists, /abc/autohandler is invoked instead of /abc/def.html. This might sound strange at first, and it is—except that the autohandler can invoke the originally requested template at any point by invoking $m->call_next().
A common strategy is to put as much common material as possible inside of the autohandler, including menus, images and headlines. The autohandler is a Mason template like any other, except for the way in which it is invoked. Inside the autohandler, between the various headlines, images and menus, you insert a call to $m->call_next(), which inserts the requested page. You thus get the benefits of a modular design using multiple templates, while simultaneously having the ability to redesign the site by changing a single file.
Autohandlers nest, meaning that Mason invokes all of the autohandlers it can find in all of its parent directories. So if we request /abc/def.html, Mason first looks for and invokes /autohandler, followed by /abc/autohandler, followed by /abc/def.html. This allows you to create a section-specific look and feel, as well as section-based menus and other information.
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)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- 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