Well, to beat a dead horse a little... my statement was catagorical, and "smoke alarms are always good to have in your home" is also catagorical. :) (though really, "home" is a qualifier, as was the exception for programming communities I gave, so maybe neither are really catagorical enough to make them probably untrue on that basis.)

I am not sure about your "parallel" idea. With the straight HTML sollution it could be, but also you could just use an SSI for the common chunk, making some sort of intersection.

I think restating the classic problem in the terms of HTML doesn't work, because HTML isn't a programming language, and non-programmers like/need to change the way it looks. That's the point I was trying to make. It is not a point I would be making in a typical programming case; in a typical case, I think that it is okay to expect people to put the time in to understand the tools they are going to use, and that expectation totally changes the values of the tradeoffs. Then I would be looking for the simplest sollution. In web design, though, I am looking for the simplest sollution for two groups of people, and I think the choice ends up being between mediocrity for all (HTML with SSI, or CGI.pm) or seperate quality sollutions for both groups (simple templates).

Does Dream Weaver handle doing things with SSI?

Using SSI is again a step away from having the displayed HTML documents being structured like what your web authoring tools work with directly. Different technology, but same idea and same tradeoffs.

As for whether the classic programming problem is appropriate to HTML, I absolutely disagree with you. Of course it applies. The problem has zero to do with being a programmer, and all that programming brings to it is another problem domain that hits it, and more ways to tackle it.

A general statement of the problem is that whenever information in two places has to be kept in sync, humans tend to make mistakes. Examples of where it arises:

1. Any interface within a program hits it.
2. Changes to code and comments.
3. Having documentation track a working system. (Program, business organization, etc.)
4. Keeping marketing documents presenting the same (current) message.
5. Keeping telephone lists in sync with people's telephone numbers.
6. Keeping references to figures and chapters in a book in sync with where the referred to information is.
7. Keeping URLs in HTML in sync with where the referred to object is.
8. Keeping classifications of books in sync with the current classification system. (Classifications are not totally static.)
and so on.

In other words this is a fundamental issue with content-management. It has nothing to do with programming, and the underlying problem hits people both in and out of programming. Consider carefully what a form letter is. Does it take a programmer to write one? Apparently not. Bosses had form letters drafted up well before people introduced computers into their offices. Some of the most sophisticated uses of document templates that I know of are from lawyers. Publishers have known to push off the actual work of getting the numbering right on footnotes to the typesetter for centuries. Telephone companies have known for decades that it is cheapest to routinely create new telephone books from scratch with almost the same information and give them to everyone (instead of just explaining what changed).

It is all the same problem. Failure to recognize that is IMHO failure to understand what the nature of the problem really is. The only thing that changes is what the tradeoffs are between ways to try to attack it. Programmers in particular encounter it very often in many different ways, and so have an unusually rich set of approaches. But you can tell any editor that keeping information in documents synchronized is a pain, and they will agree.

Now in this case you want the best solution for everyone. Well the best solution for a programmer is going to be to manage complexity by letting them apply their programming skills. The best solution for a web designer will be to pass problems off to the WYSIWYG tool of the day, allowing them to forget about mechanics and concentrate on the overall result. There is no solution that is truly best for the two of them, they want to work with the same things in such different ways.

So you have to accept tradeoffs and compromises. And repeat it as often as you want, my direct experience says that the tradeoff does not always come off with separating code and HTML being a win.

PS: In reference to your comment about project managers, here is my solution. My project manager is a better programmer than I am. I can't tell you how to get into that situation - for me it was luck - but I can tell you that it makes life easier than when I had to deal with people who didn't know what they were doing but thought they did. (I still think that the most pleasant management experience was someone who didn't know how to program and knew that. But he had an uncanny instinct for identifying everything a dumb user would wonder at...)

dreamweaver, what is that? lol

Examples 2,4,5,6,7, and 8 are not the same sort of problem. For example... a phone book and the phone numbers people have can come out of the same database. You have two representations of some data. That is not at all the same type of problem as having data, and processes. I think it's consistent with general programming rules to seperate the data for the processing. That is why we have databases instead of self-modifying programs, isn't it? I doubt the phone company is setting the phone number in the code that generates the phone book. I would imagine they have that defined in seperate files.

Another implementation example is, if you're writing an operating system, your code might have lots and lots of constants hard coded in. If you're writing a user interface, you probably want to move those into a config file.
--
Snazzy tagline here