in reply to Re: Re: Re: Re: Re: Code Critique
in thread Code Critique
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
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
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.
- We aren't as good at modularization as we could
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.
- It is also a language boundary.
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.
- There are different people on each side.
always complicates interactions hugely when you add to
the mix the need for people with different ideas to
- The two sides have different skillsets.
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.
- The other side is likely to have much
less experience with modularization.
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.
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
- Pay attention to the trade-offs.
isn't a general solution you can recommend pretty much
across the board (I think there isn't), there usually
are important trade-offs that need to be kept in mind.
Templating is no exception. Templating is a level of
indirection and complicates life for one or both
(probably both) parties. You want the two to be able
to work relatively independently with a minimum of
getting in each other's way. There is, however, going
to be set-up effort, limitations in how each side can
work, and the infrastructure involves up front
complications. What level of effort is acceptable
depends on how complex the end task is, where the
complexity is, what kinds of change requests are
expected, and so on. Virtually the only choice you
don't have here is whether you want to make them. You
will need to make them.
- Someone needs authority to make it work.
of the issues I pointed out involve the need for
cooperation between people with different needs and
backgrounds. Unless someone is ready to say, No, you
must play by the rules. it is guaranteed that people
working at cross-purposes will accidentally undermine
the necessary infrastructure. And the result will be a
Big Ball of Mud.
- The UI people need to be component aware.
You asked how you structure things so that the data can
go in in any way the UI person wants. Wrong question.
In order to cooperate both sides must meet in the
middle. Components that have programmatic data inputs
take programmer effort to produce and customize. While
the UI person may be able to place them, adjust various
parameters in them (eg data source, colors, borders,
etc), there will be inevitable limits. The programmers
can offer black box components, and can work with the
UI people to make sure that appropriate components are
available, but components need to remain
black if separation is to be maintained. (It is going,
of course, to be much easier for everyone if the tools
that the UI people use can be taught to understand the
components which are available and work directly with
- There needs to be a clear division of types of
If you are going to create a division of
content and presentation, each type of thing needs to
clearly fall on one side or the other. Look at this
site for instance. Navigation is clearly controlled
programmatically. Layout of nodelets likewise. UI
people can create images, create new themes, create
layout for new nodelets etc. But you could not just
create a few new pages in Dreamweaver with a custom
look and feel, drop them into the site, and have things
That is a reasonable choice for a simple content-driven
site. If you had more types of pages to offer and the
content was less important, then you might want to let
the UI people control overall layout much more freely.
Whatever choice you make, initial choices here are
going to drive the kinds of interfaces each side has to
live with, which is going to decide what kinds of
restrictions each lives with.
- Keep your interface clean.
As stated in my glib answer, this is fundamentally a
modularization problem, and the answer is to proceed as
you always do with modularization - define a division,
define an interface across that division, and program
to that interface. That is still, despite all of the
additional problems and complications, fundamentally
correct. And the key, as always with modularization,
lies in defining a clean interface. The additional
issues make that harder, which means keeping that in
mind becomes more important, not less.