Hurley's World

HTML in Perl code and vice versa

Most people who have worked with me know of my ardent desire to keep HTML code out of Perl code. Since I'm a Perl programmer, most of the time when I mention this, people tend to bring up HTML::Mason (either saying "Yeah, it's great for that" or saying "Yuck, I don't want to use it"). Personally, from what I have seen of Mason, I dislike it. You see it gets around having the HTML in Perl code by putting Perl code into the HTML. To me, this is no solution at all for the problem that drives me to using modules such as HTML::Template, namely that most Perl programmers lack critical web design skills and that many web designers are not programmers.

1. Allowing nonprogrammers to make changes to the HTML
   Nonprogrammers tend to panic when they see Perl code. It's something that is foreign to them and well, they just can't seem to understand it. Since I started really programming in college, I well remember my first forays into the world of programming, and it wasn't pretty. Until I could relate to the code, I was completely lost. This problem is further magnified by the fact that Perl allows us to solve the same problem in multiple ways. Yes, I understand that for most of us web developers, using HTML::Template doesn't make as much sense as something like Mason, but I firmly believe that HTML::Template makes a lot more sense to web designers, the people who really should be mucking around with the HTML.
2. Cleaner Perl code
   First, by taking the HTML out of the Perl code, the result will most likely be fewer lines in a Perl script. Often times this alone will make the code look cleaner. Code sans the HTML tends to be easier to read and understand since we don't have to worry about how the information will be displayed (the job of HTML), just how it is processed (the job of Perl). In addition, in my experience Perl programmers do some weird things to get the display to turn out the way they want it to look. These things are not necessarily good things to do and may obsfucate what it is we are attempting to accomplish.
3. Increased flexibility and modularity
   Let's say that you have a great website providing a popular service and you are approached by a company who would love to pay you tons of money to serve essentially the same site but using their branding and site layout. If you have used HTML::Template, this is fairly easy. Either one of you can change copies of your current site layout to look the way they want it to look and then you can change your code to determine which template is served to the user. However, if important portions of your Perl code are intermixed with the display, this becomes a very difficult if not impossible task and would involve a major code revision. Likewise if your company decides to roll out a new product. How nice would it be to reuse some of your modules (such as your stats or contact management modules) and just give the data a new face.

While there are a lot of pluses to moving towards a separation of HTML and Perl code, there are some downsides.

1. HTML::Template is simple
   I don't necessarily find this a failing of the module but I definitely have been annoyed by it myself. The base HTML::Template module allows for value substitution, if-else and unless statements (based on whether a variable is true), and loops. So unless what you want to include in your template can be based on just two states, if this variable is true, show this, otherwise show that, creating templates can be difficult for involved pages. However, I often also find this more a result of the laziness of the programmer than a fault of the module. The issue is that programmers tend to view page creation in terms of how they gather and modify the underlying data. In other words, the data processing and display are intertwined. However, when this is impossible or undesirable, some additional flexibility is supplied by the module HTML::Template::Expr. However, I would caution everyone to use it sparingly as it has the distinct possibility of confusing your web designer to the point where he/she will not be able to understand the HTML file anymore.
2. Sometimes completely separating HTML from Perl code makes things more difficult
   An excellent example of this problem is a select menu. It is perfectly possible to create a select menu using HTML::Template. However, the process may be more painful than necessary especially since CGI::popup_menu works really well. Either solution will lose some features that the other has. Where to draw the line is really a matter of taste, and preferably, company policy.

With solutions such as HTML::Template, not only do you have a better chance at allowing nonprogrammers edit your HTML, your Perl code will probably contain fewer lines and will probably be easier to read. In addition, properly implemented, I believe that template solutions can make site redesigns feasible. And as the web continues to evolve, this is going to become incredibly important.