I’ve just been involved in a discussion on LinkedIn that I thought deserved a wider audience (I have no idea how well that link works if you’re not a member or or logged in to LinkedIn).
A couple of days ago, someone asked for advice on the best way to include HTML in a Perl program. They got a lot of good advice (basically – don’t do that, use a templating system instead). And then this morning, someone came in and said:
use CGI module, u don’t need to write a single HTML tag..just use CGI Methods…
I did a bit of a double take at that point. I thought we’d all stopped using CGI.pm’s HTML generation methods back in the last millennium. I replied saying that, but this chap was adamant that CGI.pm worked for him. He asked me to explain why I was so against his approach.
This was my reply:
I never said that it didn’t work. I just think that it’s a really limited way to build things and you’d be better off taking a more flexible approach right from the start.
My main objection is the separation of concerns. The logic of your application is separate to the display layer. It’s quite possible that the display of the application will need to change in the future. And that all becomes easier if the HTML is stored separately from code.
This leads to other problems too:
As I hinted at above, CGI.pm only has pretty basic support for HTML. It’s really hard to create a great-looking web application using CGI.pm. In fact, I wouldn’t be surprised if CGI.pm was largely responsible for the terrible web sites that the Perl community has been building for itself for most of the last twenty years.
Your project might well have HTML experts who know how to create good looking web pages. Expecting them to do it by editing Perl code is a bad idea. Front end developers need to know HTML, CSS and Javascript. Why force them to understand Perl as well?
Even if you’re the only developer on a project (as I often am for my personal projects) there are advantages to separating your work into “front-end task” and “back-end tasks”. I find it really helps me switch my mindset to the appropriate skills if I switch from editing a Perl source file to editing an HTML template.
It makes your Perl code more complicated than it needs to be. Seriously, try moving the HTML out of the code and into a template. See how much simpler your code becomes.
It’s unlikely that your CGI-generated pages will make up all of the web site. There will almost certainly be static pages too. If you use a tool like the Template Toolkit then you can generate static pages from the same set of templates that your CGI programs use. That way it’s easier to maintain a consistent look and feel across all of the pages on the site.
I’m not saying “don’t use CGI.pm” (well, I am a bit – but that’s a different story). The CGI bits of CGI.pm (for example the bits that give you access to the incoming parameters or let you set the outgoing headers) are great. It’s just the HTML generation stuff that I strongly recommend that you don’t use.
I’ve just remembered an article that I wrote in 2001 that might also help. The first half is about cookies, but the second half demonstrates using Templates instead of the HTML generation methods. I hope it shows how much simpler it makes things
See http://mag-sol.com/articles/cgi3.html
Does that help at all?
I think that pretty much sums up my objections. Did I miss anything obvious? Or am I completely wrong and many of you are still using the HTML generation methods in CGI.pm to do this?
The Perl community on LinkedIn is a fascinating place. I should really write a blog post about it.
I use CGI.pm all the time to generate html , just not complicated html , it has it’s usage. But for a complicated web site with lots of formatting you can’t beat a template system of some type. HTML::Template.pm is my go to method of creating a web site. It’s nice to be able to separate the look and feel from the core logic .
I maintain CGI.pm, and I don’t use or recommend the HTML generation functions. Minimal work is being done to keep them up to date with changing HTML specs. For that matter, I would recommend folks consider solutions based on PSGI before starting a project now with CGI.pm
Hi Dave,
Thanks for your cogent arguments. If I were an actual web developer developing for the general public on any website of decent size, I would bother to learn some sort of templating framework like you mention. Heck, I would take the time and effort to learn a modern web programming language that is actually in use these days. The websites that I develop have a low concurrent user count, relatively small apps (scripts are not large or very complicated), and are primarily all HTML2&3 basic stuff and black text on white background. My userbase loves the the ease of raw functionality of this 90’s era stuff to get the job done quickly and easily and does not need the latest bells and whistles. Its very rare that I really need anything from HTML5. Wanted to provide a use-case here that still exists and probably will as long as all browsers continue to fully support the HTML2&3 features. Until that stops, CGI::HTML::Functions should still continue to exist. I’m not saying they need to be updated at all, just continue to exist in their current form.
Hi Tim, thanks for your input.
Just to be clear, the fact that your code uses the HTML generation functions doesn’t effect your users at all. It is only the people who are maintaining your sites who even know how they are written.
I have no objections at all to people wanting to use basic-looking HTML to build their sites. But even on a site like that, I strongly believe that using the HTML generation functions makes things more complicated than they need to be – and switching to a templating system would make the site easier to maintain (I do, however, realise that there’s going to be a small effort required to get upto speed on the templating system).
Dave – what is the easiest, quickest to learn templating system out there now that would handle the basic HTML2&3 stuff? I want to spend absolutely minimal effort on this if I’m going to do it.
I would always recommend the Template Toolkit. But I suspect that Text::Template might be easier – not least because the templating language is Perl.