This is an interesting problem, isn't it? I remembered I had similar paradox when I was working in the bill printing industry, when I had to choose between a template driven model and data driven model for the new bill printing engine.

I chose the template driven model that populates the contents of the bill via data callbacks, because I believe the less cohesion between the look & feel of the form and data calculation/processing, the better is the maintainability of the project. (We had artists to design form templates and programmers to do data merge programs.)

For example, the bill template can have table variables, simple lookup's, complex paragraph lookup's, calculations, etc., each identified by a unique name/id. The data feeding code has a simple callback that matches the unique name/id of the form variable with a set of business rules.

The beauty of this model is that the form design and prototyping can go ahead before any programming is done (because the package contains a template designer and previewer), and the programmer is simply required to generate required data according to variable name/id on the form according to some business logic. And of cause changing the position of an item on the form can be done by the artist, without any programmer input. This cuts down the development cycle of a bill by more than two-three folds.

The template driven model can be applied to all kinds of different output templates - HTML, XML, Postscript, Simple E-mail, etc., without major rework.

To balance between how much coding and how much template for the project is an art, a joy, isn't it? It all depends on the nature of project, the complexity of the form, etc. A successful design, an efficient design can deliver great satisfaction to everyone working on the project.