in reply to Re: Re: Re: Re: Re: Code Critique
in thread Code Critique

Excellent questions.

It is unfortunate that people tend to avoid answering this kind of question. The reason is that there are not simple good answers. But saying nothing can make pro-template people look a little religious. Templating is great for all of these reasons! Good luck getting any concrete advice on doing it though.

The short answer is that templating is just a form of modularizing, and so you approach it like you would any other modularization. Define your division of labour into components. Define your interfaces. Then stick to them.

Unfortunately that glib answer, while correct, is seriously misleading.

Yes, templating is just another form of modularization. Modularization should, of course, be the bread and butter of any decent programmer. You should spend your days breaking problems up into components, defining interfaces to each component, then putting them together into programs. As is pointed out above, modularization with templating techniques is good for the various reasons that modularization is always good. It is a natural opportunity for modularizing because it allows you to divide tasks naturally along lines where the kinds of knowledge which are needed are very different. But it is unfortunately a hard place to modularize for many good reasons:

  1. We aren't as good at modularization as we could be.

    While modularization is good, in practice most programmers are somewhat inconsistent in doing it. We violate encapsulation, set up poorly chosen interfaces, don't get time to think about design, or may not even realize how much we don't understand program design. For most problems we can do all of this and mull through. But it means that when we need to modularize, the mental muscles you need to think through issues are not as well worked as you want them to be.

  2. It is also a language boundary.

    Modularizing is easier when both sides are the same language because interaction between them is more straightforward, and is likely to be the same on both sides. But in this case you are crossing a language boundary, and so interaction mechanics are different on each side. Plus the people on different sides are likely to be using radically different toolkits, making the difference even sharper. One set of interfaces just became two sets, that don't know how to talk directly. There are solutions, but what they are depend on your templating tool.

  3. There are different people on each side.

    It always complicates interactions hugely when you add to the mix the need for people with different ideas to cooperate.

  4. The two sides have different skillsets.

    When people with similar skills cooperate, they may disagree but it is at least relatively easy for one to explain the concerns they have to the other - the other has an experience base where they are likely to understand and figure out where to give and take. They might even offer good suggestions. Cooperating across a lack of common ground makes it harder to resolve issues.

  5. The other side is likely to have much less experience with modularization.

    As a programmer you are likely to think about modularization. In a lot of ways it is a big part of the mental toolkit through which you earn your bread and butter. The same is less likely to be true of the kind of graphics person who you may wind up interacting with on the other side. They learn how to use tools, how to achieve effects, and about how those effects affect people's reactions. They have less practice with, for instance, techniques for keeping changes synchronized across multiple places.

That is quite a list of problems. And there isn't a single solution that I know of. Rather there are hard decisions, and how you need to make them depends on what you are doing. There are a range of solutions from generating HTML in code (eg CGI's autogeneration methods - easy for the programmer but makes it impossible for anyone who is not a programmer to work with it) to having the UI people using Dreamweaver with predefined components, some of which happen to be parametrized with callbacks to data sources programmers need to supply. I have used quite a few different solutions on this spectrum, and I strongly suspect that for any possibility I could find a situation in which I would choose to use it.

But there are some principles that I think can guide people in figuring out how to handle this problem.

A bit late, a lot long, but hopefully this answer will be helpful whenever you try to use templating. (I fear it will be most useful when you are trying to figure out why your first attempt didn't turn out as well as you wanted. But that helps your second attempt, so that is officially OK.)