Hmmm...

CGI::Pretty inherits from CGI so it loads CGI.pm. No improvement there. It goes through extra work to maintain nicely formatted HTML, so no improvement there. It sends lots of extra whitespace down the pipe, which can be a huge slowdown as pages get big and complex. (As a slight reprieve the excess compresses well for users on modems.)

There is one reason and one reason only for using CGI::Pretty. And that is that you want to be able to read and understand the output HTML. (Which is not a bad reason, all things considered.) But performance is made worse, not better.

   CGI.pm is good for handling the query ...
   but using it to generate the HTML is nearly 
   impossible to maintain.

It's all just a matter of personal preference, and probably depends somewhat on what sort of HTML code you're generating.

buckaduck

It is a fact in any project with more than one user. Either it is open source, and there will be lots of maintainers, or it is a commercial project and will also have other maintainers. So, rather than being an opinion, it is a general known fact in programming that mixing languages in a single file is less maintainable than having seperate files for seperate technologies.

The part that is opinion is, if it is important enough to make it so that it can last. Maybe it is a page that won't be around long anyway. Or maybe it is a personal project. Or a project for a perl-centric website where there will always be people who can maintain it. But it is still good to acknowledge the real life difficulties of each choice.

Like most categorical statements, this is false.

There is a real cost to setting up a framework that nicely separates different kinds of code. This cost is seen in additional up front complexity in design, the need to be sure that tools which are used for each component play well with whatever system (eg templating) you use to get the components to interact, additional layers to worry about, etc.

Now I do not deny that when you mix languages together, that makes that piece unmaintainable unless you have people who understand and can easily switch between all languages in question. I likewise would agree that any good program is factored and a natural factoring into kinds of tasks should show a fault line where you switch languages. Furthermore I absolutely agree that the decision of whether or not to separate your HTML from your code has huge implications for how you continue to work from then on.

However I strongly disagree that the trade-offs are so clear that in any project with more than one user it is best to split along that line. I even disagree that the answer is always obvious for projects with many users and multiple developers. For very large projects with ongoing maintainance and customization going on among separate teams, it would be insane to not have that split. For small tasks of the form, "Gimme a working web interface to do X, it doesn't have to be pretty." it would be insane to insist on that split. Between these clear extremes there are definitely some shades of grey.

I still humbly disagree. Separating Perl and HTML into separate files does not have inherent advantages -- unless it is a multiuser project AND some of the users are HTML designers but not programmers.

This is naturally the case when developing (as you say) a commercial project or an open source product. But I refuse to believe that the majority of Perl/CGI programs fall into these categories. I'm not just talking about short-term web pages or personal web pages, but intranet web pages and applications where the HTML is simple enough for the programmer(s) to handle.

Is this really that uncommon? Am I alone in being a Perl programmer who can handle his own HTML without outside interference from non-programming web designers?

buckaduck