367784 - (bz-template-logic) Separate logic and presentation in templates

Status: NEW

(Bugzilla :: User Interface, enhancement)

Description

[Max Kanat-Alexander]

One of our goals for the future of Bugzilla is to make it easier to customize and make plugins for.

It should also be easier to localize.

One of the problems with our templates is that they mix up logic and presentation a lot. It's OK to have logic in template code, but it should be in separate files from the presentation code.

For example, right now we have bug/field.html.tmpl that contains logic for fields, and bug/edit.html.tmpl that contains presentation for fields. That's good! However, bug/edit.html.tmpl also contains some field logic, and that should be moved *out* of that template and into bug/field.html.tmpl.

We should also be creating other tempalates like bug/field.html.tmpl to hold advanced logic and separate that logic from the presentation of the page.

Having these logic templates is useful to plugin authors.
Having logic removed from the presentation is useful for localizers.

Comment 1

[Max Kanat-Alexander]

Some people may say "All logic should be in CGIs!!"

That's not very workable for us, though--we really do have logic that needs to be in the templates, like bug/field.html.tmpl, where we have to make decisions about a field object and display it differently depending on what type of field it is.

Also, we want to make templates more flexible by always passing *objects* instead of just values, and since we pass objects, sometimes we need to have a little logic to deal with them. (For example, if we have an array of objects, sometimes we need template logic to create an array of just their names, since Template-Toolkit doesn't have a "map" function.)

Comment 2

[Max Kanat-Alexander]

Note that one particularly good thing to remove from presentation templates is JavaScript--localizers don't have to customize that, and plugin authors may want to re-use it.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #1)
> Some people may say "All logic should be in CGIs!!"

But that's a small mind hobgoblin.  Some logic makes sense in templates.


> Also, we want to make templates more flexible by always passing *objects*
> instead of just values, and since we pass objects, sometimes we need to have a
> little logic to deal with them. (For example, if we have an array of objects,
> sometimes we need template logic to create an array of just their names, since
> Template-Toolkit doesn't have a "map" function.)

For this particular case I'd recommend we define a custom "map" virtual method as a TT plugin.


Also, cc:ing Gerv, who architected the current localization scheme, for his opinion on proposed changes.

Comment 4

[Gervase Markham [:gerv]]

When we originally discussed where the split should be between CGIs and templates, we also considered whether we wanted a further split, between templates and text strings.

We decided that this was not worth doing - the extra level of indirection provided would only be useful if you could get to a point where translators could translate the application by editing string files only, and those string files could then be used in more than one release of Bugzilla. It didn't seem feasible to achieve such a strong separation then.

I'm not sure it's entirely feasible now either and, even if it was, it would be a great deal of work for little or no benefit.

Why do applications (such as Firefox) structure their code with strings in external files? To make translation easier. However, there's a lot of baggage that goes along with that. You need to make sure that there's a mechanism for dealing with strings with parameters in ("Search returned [23] bugs"), and different word orders and gender.

What benefit do localisers get? They can perhaps use their localisations with multiple releases - but this only works if the development team has a string freeze on stable branches. So far, the Bugzilla development team haven't committed to this - with good reason, as they are a major pain. 

It might possibly be a little easier to do the localisation - but the major benefit there is when you have localisers who aren't techies. Given that Bugzilla is a piece of software development software, our localisers are generally all techies themselves and are not fazed by editing text in TT templates without messing up the TT directives.

[We did, of course, decide that it was worth making it possible to do the limited and common substitution of renaming "bugs" as something else - and that works and is possible today, and is often used. This is definitely the low-hanging fruit.]

So while I agree with Max's goals of making Bugzilla easier to customise and make plugins for, I am not convinced that the practical step he is proposing in this bug to go towards meeting that goal will actually help - or that the reward will be worth the effort. Perhaps he would like to try convincing me? :-)

Gerv

Comment 5

[Max Kanat-Alexander]

(In reply to comment #4)
> When we originally discussed where the split should be between CGIs and
> templates, we also considered whether we wanted a further split, between
> templates and text strings.

  Right, we would never do that, unless Template-Toolkit got gettext support. This isn't about that, it's about separating logic and presentation by moving some logic stuff into separate templates. For example, using bug/field.html.tmpl everywhere that we can instead of reproducing that code in a million places.

Comment 6

[Gervase Markham [:gerv]]

OK. I have no issues with rearranging our templates to improve code reuse - assuming that there's not a performance or understandability penalty.

Gerv

Comment 7

[Marc Schumann [:Wurblzap]]

For me as a localizer, I'd of course see complete orthogonality between text, logic and presentation. I understand we're not ready for this.

However, I do benefit already whenever changes in logic CVS-merge well into translated templates. Resolving conflicts is the most time-consuming part of a release.
(In the special case of a template which does not need translation at all, I can even omit it from translation completely and let Bugzilla fall back on the original one.)

Comment 8

[Xavier OTTOLINI]

It would be interesting to select the localization files as a plug in.

Comment 9

[Frédéric Buclin]

Too late for 3.2.

Comment 10

[Vitaly Fedrushkov]

Thoughts after banzai charge on bug 412161:

Looks like we have several layers here.

1. Heavy logic has been separated already: templates don't call DBI, etc.

2. Rendering HTML _content_ (like form field values from variables) belong to
templates, as this is exactly what TT is for :-)

3. OTOH, HTML _markup_ is sometimes mixed heavily with text: 

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/bugzilla/template/en/default/welcome-admin.html.tmpl&rev=1.4&root=/cvsroot#44

and can be complex enough to obfuscate the sentence:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/bugzilla/template/en/default/account/profile-activity.html.tmpl&rev=1.5&root=/cvsroot#77

however, there _is_ certain usability gain in natural language usage, and we're
moving in that direction.  I really like attachment 345735 [details].

4. Natural language layer.  Manifested here and there by numeric inflection
code snippets, etc.  This is something we're really able to separate and kill. 
Bug 469732 is about that.

Right now layer 3 is most problematic AFAICT.

Comment 11

[Vitaly Fedrushkov]

(In reply to comment #10)
> Thoughts after banzai charge on bug 412161:

Exhaust from said charge can be seen in attachment 356254 [details] [diff] [review].  I don't call the result very readable, just an attempt to separate HTML markup and natural language better.