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.

Like most categorical statements, this is false.

Was that an example? ;)

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.

Well, in the general case I would agree enthusiastically. But in the specific case...

HTML::Template has very little cost. There isn't the design complexity of other template systems, and it really doesn't try to do much. It's about like SSI, with simple loops, and in the CGI instead of the web server. I've never seen or heard of compatability issues. Anything running in apache using CGI.pm can work just as well using HTML::Template, because all you're really changing is the print call(s), and how you generate the strings to print.

I guess I am just too lazy to run from a marginal upfront complexity, if it means less calls on my cell phone, "I updated the login CGI and now nobody can connect!"

Maybe it is just because I usually get idiots for project managers. :) Someday... Someday...

Actually if you look closely, I made sure to make my statement not a categorical statement. That is why I said "most", not "all".

But to the real question. In this specific case I definitely disagree. A set of glorified marked up HTML pages that parallel a set of CGI scripts does not necessarily a maintainable design make. Suppose, for instance, that you are putting together website where several of the pages have a large chunk (say about a third) of the page in common. What approaches would you take? Well here are some options:

1. Maintain the HTML for those pages as HTML.
2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages.
3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common.
Here are some of the maintainability implications.
1. Maintain the HTML for those pages as HTML. Well HTML has no real include mechanism so that common chunk needs to be maintained in parallel between those pages. If that chunk includes dynamic content, this could be an ongoing issue. But you do preserve the ability to use standard HTML WYSIWYG tools to modify the page.
2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages. Tools like the Template::Toolkit make this easy and natural to do. You now lose the maintainance problem of maintaining pages in parallel. However you have also lost the ability for designers to conveniently use WYSIWYG tools on your pages as a whole (they can on each component, but more knowledge is needed to work this way), and now people maintaining the HTML or code needs to understand the layout of your templating system to work on your site.
3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common. Again you lose the maintainance problem of maintaining pages in parallel. On the flip side you now have code and HTML mixed together. But you don't have the conceptual overhead of a template system to work with and the mix of skills required is fairly readily available.
IMHO any one of these solutions could turn up best in a real project depending on the skillsets of available developers, and the scope of what needs to happen. I would be inclined to go with the first in a small site where layout developers have considerable input and want to keep changing the look and feel of the site. I would be inclined to go with the third in a small site where the look and feel of the site was pretty much fixed but there are a lot of developers and a large variety of dynamic content. (Pages almost the same but different data sets and different fields driving it.) I would want to go with the second for any significant site with both ongoing data and design maintainance required.

This is a classic maintainance problem, just restated in terms of the web. Maintaining parallel content either requires ongoing extra work, or it requires that you find a way of factoring your problem. With the web your issue is that the design tools that designers like to use tend to not play well with trying to factor the problem. The three answers I gave trade off differently depending on what resource you can most easily waste: HTML designer's time (on synchronization), programming time (on figuring out how to modify code to produce different HTML), or a bit of everyone's time (on setting up and maintaining a clean separation).

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

The programmer understanding the problem isn't the problem. :)

The problem in the intranet scenario is that it is very regular for another person to try to make changes.

In an ideal world these other people would keep their grubby fingers off... if you know of the secret trick to taming project managers, please post it for me so I can re-simplify my dynamic content methods. :)

--Paris