[Analysis] Templates: The good, the bad, the ugly

[Jake]

The US Military is often seen as having the ability to police itself and
correct its own problems. While this ability is normally exaggerated, it
does exist to some extent. The reason for this is, in part, the after
action review. After any mission (big or small) comes an honest no holds
barred assesment of how it went from those who participated. The normal
questions are:
1. What was supposed to happen?
2. What did happen?
3. What went right?
4. What went wrong?
5. What could be done better next time?

I thought it might be interesting to bring this concept to Bugzilla,
especially when dealing with large changes. So, allow me to go first.

-=-=-=-=-=-

What was supposed to happen?

Visualization items (eg, the HTML, etc) was supposed to be completly
seperated from code for all content generated by Bugzilla.

What did happen?

HTML (js, xml, etc.) was all grouped into seperate template files,
intersperced with template directives, for all user facing pages generated
by Bugzilla.

What went right?

Before a single bit is sent back to the browser, all data is complete.
This avoids the situation where some piece of information is desired in
the header but can't be placed there because the information hasn't been
processed yet (I seem to remember this situation at least once
pre-templates).

Translation is much easier because all the words seen by the user are in
one place. Previously, there was often a single word (or phrase), a bunch
of perl/database calls/whatever, a couple phrases, more code, more
content, more code, etc.

Bugzilla can now support more than one language on a single installation.
This was not even remotely possible pre-templates.

What went wrong?

While it's true that the presentation and the perl code are now seperate
from each other, there is still a lot of code in the middle of this
presentation. This code is in the form of template directives, some of
which are just as complicated as perl code. Also frustrating is the fact
that the template directives are basically another programming language to
deal with and have no support for context colorization is most common
editors (vim, emacs, etc).

Administrative pages are still not (as far as I'm aware) templates. I
realize that this isn't considered a priority, but it is still a fact.

Templates first came to life in Bugzilla as part of a completely unrelated
patch with little to no discussion beforehand about the implimentation,
template package, etc.).

The process was started in the middle of a development cycle and became
one of the blockers for the next release. Because it was such a huge
undertaking and reviews often took a considerable amount of time (and that
was just finding the reviewer!), the stable release was delayed numerous
times.

Speed. While I haven't run any benchmarks, I've gotta believe that the
introduction of another processing engine (eg, Template Toolkit) had a
negative impact on our speed.

What could be done better next time?

Obviously there won't be a next time for implimenting templates in
Bugzilla, but suggestions here can mostly likely be taken into
consideration for other changes.

It would have been nice if discussion had transpired about methods for
templatization before any work was done/package was chosen. I'm going from
distant memory a lot here, but as I recall there wasn't much discussion
about what was the best plan of attack.

It also would have been nice to have taken the scope of such a change into
consideration before implimenting it. While templates are nice to have, it
would have been possible to release 2.16 without the templates and have
had that been a stated goal for 2.18... possibly even the only stated
goal. It would have given more time for discussion/proof of concept and
would have allowed us to step up the pace of releases (a long stated
goal).

-=-=-=-=-=-

I'd like to hear your comments on my analysis as well as your own
good/bad/improve list (after all, an AAR isn't a one man show :).