Christian Reis Reporter
	Description • 23 years ago

Re discussion with Myk, I suggest we start moving the hard-coded HTML code into
templates. Myk suggests we use the Template Toolkit ( see
http://www.template-toolkit.org/ ) and since he's used it already in bug 84338
and it appears to be stable and supported, why not?

The purpose here is to make Bugzilla's install and customization much easier,
and to allow for simpler upgrading, additionally. It does have high impact, of
course, but it can be done in phases.

	Matthew Tuck [:CodeMachine]
	Comment 1 • 23 years ago

I think this was a part of Red Hat's changes, which are also currently in use
over at bugzilla.gnome.org.  We might want to consider taking code from what
they use.

	Myk Melez [:myk] [@mykmelez]
	Comment 2 • 23 years ago

I use the following directory structure for the attachment/request trackers:

templates/
  global/
  attachment/
  request/

Here is what I propose for Bugzilla in general:

template/
  default/
    global/
    [one directory for each major component...]
  custom/

This second directory structure, along with the template search path
"template/default:template/custom", allows installations to customize Bugzilla
UI on a per-template basis without forking any code by placing files in the
"custom" directory that override files with the same name in the "default"
directory.

	Luis Villa
	Comment 3 • 23 years ago

bugzilla.ximian.com uses a subset of the redhat.com modifications that provide
templates for a few key pages (bug_form.pl, enter_bug.cgi, query.cgi, and soon
buglist.cgi). When 2.14 gets released, we'll be porting those changes to that
codebase. Would you guys be interested in those patches as a solution to this bug? 

	Dave Miller [:justdave]
	Comment 4 • 23 years ago

Myk, since you were working on this already for Bugzilla, your call on this one.

	Myk Melez [:myk] [@mykmelez]
	Comment 5 • 23 years ago

I'm very interested in seeing what RedHat has done.  Is there any chance you can
 do a diff of your current setup (or perhaps attach the templates) so I can see
how they did it?

	Luis Villa
	Comment 6 • 23 years ago

A diff will not be simple to do; the changes are substantial and varied, and our
setup is also quite a bit out of sync with CVS (hence my desire to wait until
2.14 is released, and do work based on that.) However, I can definitely attach
some of the complete relevant files in the morning. 

	Myk Melez [:myk] [@mykmelez]
	Comment 7 • 23 years ago

Louie, any progress on attaching those files?  I'm particularly interested in
buglist.cgi.

	Myk Melez [:myk] [@mykmelez]
	Comment 8 • 23 years ago

Although it is possible to write an entire web application using the toolkit's
directive language, complex logic is still easier to read, write, and maintain
when written in Perl, while the directive language works well for variable
substitution, basic looping, and logical operations.

When templatizing Bugzilla, developers should be careful to leave the bulk of
application logic in Perl scripts that generate data structures that they pass
to templates for parsing and display.  The templates should contain only the
minimal logic necessary to present the data.

For more information about this approach, read the following paper on the
Template Toolkit:

http://www.template-toolkit.org/tpc4/paper.html

	Myk Melez [:myk] [@mykmelez]
	Comment 9 • 23 years ago

Moving over to the new "Bugzilla" product, "User Interface" component.

	Myk Melez [:myk] [@mykmelez]
	Comment 10 • 23 years ago

Comments in the IRC channel suggest considering Text::Template for this project.
 Here is more information about Text::Template:

http://search.cpan.org/doc/MJD/Text-Template-1.31/Template.pm

And here are some comments relevant to this consideration:

http://groups.google.com/groups?selm=39e49091.41bb%2425a%40news.op.net&output=gplain

There are a number of differences between the feature sets and installation
requirements of the two packages, but in my opinion the fundamental relevant
difference is that Text::Template uses embedded Perl in templates while Template
Toolkit uses its own simplified directive language.

Both packages satisfy my fundamental goal in this project: to separate logic
from presentation for easy customization of the Bugzilla UI to prevent forking
and keep installations on the branch.

Template Toolkit better satisfies a second goal of this project--to enable
non-programmer UI designers to contribute to Bugzilla--because its simplified
directive language is easier to understand and hack (or ignore) for those
contributors.

	Dave Miller [:justdave]
	Comment 11 • 23 years ago

and Template-Toolkit is also harder to install :-(

However, if we can talk the TT guys into fixing the installation quirks (or help
them with it even :) maybe it won't be an issue.

One thing worth noting for the docs, is install will be much easier if you
answer NO to all the optional stuff.

	Dave Miller [:justdave]
	Comment 12 • 23 years ago

*** Bug 98638 has been marked as a duplicate of this bug. ***

	Matthew Tuck [:CodeMachine]
	Comment 13 • 23 years ago

So far there's been lots of grumbles about dependencies but no one has actually
sent any messages to the list about it as far as I know.

	Jacob Steenhagen
	Comment 14 • 23 years ago

One of the things suposedly fixed in version 2.04c (IIRC) is the CPAN dependancy
reporting.  From what I've gathered, this is a developers only release, so it
didn't make it to CPAN's servers.  I believe 2.05 is supposed to be due out in
the next few days and that should be a "general" release.  Perhaps it will make
it easier :)

	Paul Baker
	Comment 15 • 23 years ago

I have worked extensively with HTML::Template for the last couple years. In fact
I can't think of a project I haven't worked on in the last 2 years that I didn't
use HTML::Template in. One of the nice things about HTML::Template is the
ability to create our own tags through the use of filters.

I have never used Template-Toolkit, but I would definitely like to help in this
effort, especially if you all decide to use HTML::Template.

	Myk Melez [:myk] [@mykmelez]
	Comment 16 • 23 years ago

Paul,

Several folks working on Bugzilla have already made significant headway using
Template Toolkit to templatize parts of the application.  TT also has filters
and just about every other feature I have come to expect from a template system,
along with extensive documentation and an active developer community.

http://www.template-toolkit.org/

I encourage you to take a look at TT and how it is used in Bugzilla (f.e.
attachment.cgi) and participate in the effort to templatize the rest of the app.

	Dave Miller [:justdave]
	Comment 17 • 23 years ago

This is now on the "we really want this for 2.16, but won't hold the release for
it if it's not done by then" list.

	Luis Villa
	Comment 18 • 23 years ago

Paul, FYI: I think part of the motivation for using Text::Template is the
ability to move beyond HTML and use it to generate XML and RDF from the same
data. To me this is one of the /big/ plusses behind moving towards templating.

	David Lawrence [:dkl]
	Comment 19 • 23 years ago

Luis, Let's also make sure that we make the distinction that I pushed for use
of Text::Template but it was decided upon Template-Toolkit which is very
different. Does anyone know if Template-Toolkit can be used for other more
general template processing for generating XML, etc. documents or is it very
closely tied to HTML?

	Dave Miller [:justdave]
	Comment 20 • 23 years ago

recent discussion on the template-toolkit mailing list seems to indicate you can
use it for damn near anything.

	Myk Melez [:myk] [@mykmelez]
	Comment 21 • 23 years ago

Yes, Template Toolkit is very generalizable.  I have patches that use it to
generate RDF descriptions (bug 103778, bug 72837), JavaScript code (bug 72837),
and SQL queries (bug 98801).  I have also developed code that uses it to
generate mail messages and am considering places where it could be used to
generate Perl itself.

	Aleksey Nogin
	Comment 22 • 23 years ago

I've built RedHat RPMs of Template-Toolkit and AppConfig, get them from 
http://nogin.org/RPM/perl-Template.html and http://nogin.org/RPM/perl-AppConfig.html

To be honest I haven't yet tested if they are any good, but at least it's a
place to start.

	Aleksey Nogin
	Comment 23 • 23 years ago

BTW, Template toolkit is now available on CVS:

Date: Mon, 12 Nov 2001 08:54:55 +0000
From: Andy Wardley <abw@kfs.org>
To: templates@template-toolkit.org
Subject: [Templates] CVS access to TT2 code base

After something of a struggle, the TT2 code base is now available under
CVS from tt2.org.

  cvs -d :pserver:cvs@tt2.org:/template-toolkit login
  password: 'cvs'.

To fetch the TT2 source:

  $ cvs -z3 -d :pserver:cvs@tt2.org:/template-toolkit co Template2

(or set CVSROOT=:pserver:cvs@tt2.org:/template-toolkit)

This is now (tentatively) live and includes Aleksey's patch.

Template3 source will be going up in the next few days.

	Dave Miller [:justdave]
	Comment 24 • 23 years ago

I've been convinced that this should be an all-or-nothing process as far as
affecting a released version, since things discovered during parts of the
process might cause things in other places to have to be altered, and the less
we screw with it after a release the better.

	Myk Melez [:myk] [@mykmelez]
	Comment 25 • 23 years ago

Dave, could you elaborate?  Is there a specific problem you think will occur if
we release a version of Bugzilla that contains a combination of templatized and
non-templatized scripts?

	David D. Kilzer (ddk)
	Comment 26 • 23 years ago

While building a Debian package for Template-Toolkit-2.06, the
build kept dying when running ./bin/gifsplash or ./bin/ttree
from the Makefile.  I tracked this down to the fact that neither
of these programs could find the Template Toolkit modules that
were just built into ./blib/arch and ./blib/lib.  This patch
fixes Makefile.PL to include those paths when running those
programs during build.

I believe this affected only those users who didn't already have
a (recent) version of the Template Toolkit module installed.
This patch will aid those building packages (RPM, deb, etc.) or
building and installing the module manually.

The patch will also clean up some temporary files that are
created by the build process, but which are not removed during a
'make clean'.

	Dave Miller [:justdave]
	Comment 27 • 23 years ago

Myk: I'm two months late with the answer to your question (I'm still digging
through bugmail, I finally got smart and wrote a filter to look for bugmail that
mentioned my name in the comments :)

I'm not so sure what I meant anymore, but I'm mostly happy with how it's turning
out, provided we can get the damn patches checked in. :-)

I think I was concerned with templates having a common naming scheme, using
similar techniques to pull variables in, etc.

	Dave Miller [:justdave]
	Comment 28 • 23 years ago

ddk: Did I correctly see that your patch to the Makefile.PL was checked into the
tree for Template-Toolkit?  So 2.07 should include it...

But 2.07 isn't out yet.

How do we need to deal with this?  Should we just toss this patch in contrib,
and mention it in the docs, since 2.07 isn't out yet?  Should we change Bugzilla
to require 2.07 once it's out so the patch won't be needed anymore?

	Aleksey Nogin
	Comment 29 • 23 years ago

Not exactly this patch, but something similar was checke into cvs in December.
The latest development release, 2.06d should have this in...

	Gervase Markham [:gerv]
	Comment 30 • 23 years ago

The dependencies here are out of date. Instead of trying to update them, just
query for 2.16 blocker bugs with "Templat" in the title :-)

Gerv

	Myk Melez [:myk] [@mykmelez]
	Comment 31 • 23 years ago

This isn't really a blocker for 2.16, and the two open bugs it depends on are
targeted at 2.18 and untargeted, respectively.  Reducing severity and pushing it
out.

	Bradley Baetz (:bbaetz)
	Comment 32 • 22 years ago

Comment on attachment 64514 [details] [diff] [review]
Fix Makefile.PL of Template-Toolkit-2.06

This patch got rolled ito the TT source at some point

	Bradley Baetz (:bbaetz)
	Comment 33 • 22 years ago

*** Bug 49225 has been marked as a duplicate of this bug. ***

	Dave Miller [:justdave]
	Comment 34 • 22 years ago

The User Interface component now belongs to Gerv.  Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.

	Dave Miller [:justdave]
	Comment 35 • 22 years ago

Reassigning back to Myk.  That stuff about Gerv taking over the User Interface
component turned out to be short-lived.  Please pardon our confusion, and I'm
very sorry about the spam.

	Gervase Markham [:gerv]
	Comment 36 • 21 years ago

This bug's dependencies are not going to get fixed for 2.18, so neither is this.

Gerv

	Max Kanat-Alexander
	Comment 37 • 20 years ago

*** Bug 238363 has been marked as a duplicate of this bug. ***

	Max Kanat-Alexander
	Comment 38 • 20 years ago

This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.

	Frédéric Buclin
	Comment 39 • 18 years ago

All pages has been templatized.