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

[Myk Melez]

As the guy who decided on TT for Bugzilla, I guess I should weigh in.

Jake wrote:

>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.
>  
>
Sounds like a good idea.

>Visualization items (eg, the HTML, etc) was supposed to be completly
>seperated from code for all content generated by Bugzilla.  
>
I would say the goal was to separate Bugzilla presentation code from 
business logic, which doesn't necessarily mean separating all code from 
all content (see below for more details).

>What went right?
>  
>
Besides the benefits you mentioned, Bugzilla is now much easier to hack 
in many ways.  Also, it may have reduced installation-specific forking 
by breaking code into smaller chunks and separating chunks that 
installations are more likely to fork (presentation) from those they're 
less likely to fork (business logic).  That's pretty hard to measure, 
however, since the total number of forked installations could remain the 
same even as upgrading those installations gets easier.

>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.
>
Separating logic from presentation is not a goal in and of itself but a 
means for furthering other goals, like code quality and flexibility and 
ease of development.

There will always be logic in our presentation code, partly because it's 
necessary (f.e. for looping over lists of items to display or 
conditionally displaying content) and partly because domain-specific 
template languages like TT are a better tool for some jobs (f.e. 
filtering content).  So logic in our presentational code isn't a sign 
that something "went wrong," it's a necessary element of that code.

> This code is in the form of template directives, some of
>which are just as complicated as perl code.
>
Some TT directives can be as complicated as some Perl constructs, but TT 
is still much simpler than Perl overall.  Sadly, we do sometimes write 
overcomplicated template code, and we do sometimes write template code 
when we should have written Perl code instead.  But that's not a failure 
of templatization, it's our failure as programmers and reviewers, and we 
don't necessarily do better in any other Bugzilla code.  Hopefully we 
improve the situation over time, however.

>Also frustrating is the fact
>that the template directives are basically another programming language to
>deal with
>
Like HTML, Javascript, and SQL, you mean?  The Mozilla project has a 
philosophy, "use the right tool for the job", so it uses C++ code for 
logic where performance or resource consumption matters, Javascript 
otherwise and to glue things together, XUL to describe presentation, CSS 
to style it, and also XBL, HTML, XML, RDF, and IDL for various purposes.

I think this is the right strategy for Bugzilla too, and in addition to 
Perl for most of our logic, SQL for database manipulation, and HTML for 
presentation, a template language is an invaluable tool for generating 
HTML output from Perl, and much better than its alternatives (Perl in 
HTML or HTML in Perl).

>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.).
>
Agreed.  The first templatization support should have been implemented 
in a separate patch that the unrelated patch depended upon.

>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.
>
This has nothing to do with templatization per se, but was rather a 
project management decision about the templatization effort.  And 
although it was perhaps the wrong decision, note that we made it because 
there were other things we wanted for that release that depended upon 
templatization or were made significantly easier by it, like localizability.

>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.  
>
I ran some benchmarks on code I templatized, and templatization does 
have a performance cost.  That's not something that went wrong, however, 
but a tradeoff we made intentionally in order to get the benefits of 
templatization.  It's a downside to the project, not a failure of it.

>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.  
>
There was some discussion.  In particular, I remember talking with Tara 
Hernandez, who was sceptical that templatization would significantly 
reduce installation forking.

Nonetheless, it's true there wasn't general discussion of the sort that 
takes place today on this list.  I reviewed the available template 
languages for Perl, picked the best one, and wrote a patch that used 
it.  Perhaps more discussion would have been beneficial in some way, but 
it's not clear how, since TT was and still is by far the premiere 
template language available for Perl, and templatization in general 
seemed back then and still seems today to be desirable.

>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).
>
Agreed.  Actually, I think templatization didn't need to be a stated 
goal for any release.  Bugzilla works perfectly well partially 
templatized.  But note that templatization was useful or necessary for 
other stated goals like localizability, and I think that's why it was 
made to block the release, not just for its own sake (which would have 
been a mistake).

-myk