FAQ
Hey,

I'd like to make a little survey: How acceptable would it be to change
text/template so that it can be "locked", that is, to disallow adding
new templates to a set at some point -- after first execution, for
example?

This is what html/template does, because the contextual escaping
mechanism can't accept changes in the parse tree. Right. I'd like to
move the lock to text/template, so that we have some guarantees to
implement inlining and new features. Long term wise it could greatly
reduce the duplicated code in (html|text)/template and simplify other
things.

The most immediate goal for this change would be to:

* Implement a django-like inheritance mechanism, as discussed in
https://groups.google.com/forum/#!topic/golang-nuts/sa7pqTHI_TU/discussion

But there are some clear benefits in the long-term:

* If we inline all {{template}} calls we would greatly simplify the
contextual escaping mechanism from html/template.
* That would reduce duplicated code in (html|text)/template (they
could practically share execution).
* The engine would be more future-proof and ready for optimizations.
New features can be implemented in text/template only, which takes
care of inlining and reducing the vocabulary to what is recognized by,
say, html/template.

So, what would be a big NO to this idea?

-- rodrigo

Search Discussions

  • Andrew Gerrand at Sep 11, 2012 at 11:04 pm

    On 11 September 2012 05:19, Rodrigo Moraes wrote:
    Hey,

    I'd like to make a little survey: How acceptable would it be to change
    text/template so that it can be "locked", that is, to disallow adding
    new templates to a set at some point -- after first execution, for
    example?

    This is what html/template does, because the contextual escaping
    mechanism can't accept changes in the parse tree. Right. I'd like to
    move the lock to text/template, so that we have some guarantees to
    implement inlining and new features. Long term wise it could greatly
    reduce the duplicated code in (html|text)/template and simplify other
    things.

    The most immediate goal for this change would be to:

    * Implement a django-like inheritance mechanism, as discussed in
    https://groups.google.com/forum/#!topic/golang-nuts/sa7pqTHI_TU/discussion

    But there are some clear benefits in the long-term:

    * If we inline all {{template}} calls we would greatly simplify the
    contextual escaping mechanism from html/template.
    * That would reduce duplicated code in (html|text)/template (they
    could practically share execution).
    * The engine would be more future-proof and ready for optimizations.
    New features can be implemented in text/template only, which takes
    care of inlining and reducing the vocabulary to what is recognized by,
    say, html/template.
    This all sounds great, but...
    So, what would be a big NO to this idea?
    ...it would make text/template incompatible with the way it was at Go 1.0.

    Now, we could try to survey the users of text/template to see if
    anyone is mutating their templates. I suspect that there are at least
    a few people doing this. But even if there weren't, it's a bad
    precedent to break the existing behavior.

    Can we support both immutable and mutable template sets in
    text/template? Seems like a royal pain.

    A difficult situation. :-/

    Andrew
  • Rodrigo Moraes at Sep 12, 2012 at 4:59 am

    On Sep 11, 8:04 pm, Andrew Gerrand wrote:
    Can we support both immutable and mutable template sets in
    text/template? Seems like a royal pain.
    I think we can. I'll also think on an alternative.

    A royal pain is to support two duplicated exec.go doing the same
    thing. That really doesn't smell good; html/template doesn't need
    that, if text/template can guarantee an immutable set. What I mean is:
    html/template can be simpler and less vulnerable to changes in text/
    template. We can do this in a backwards compatible way.

    -- rodrigo

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 10, '12 at 7:19p
activeSep 12, '12 at 4:59a
posts3
users2
websitegolang.org

2 users in discussion

Rodrigo Moraes: 2 posts Andrew Gerrand: 1 post

People

Translate

site design / logo © 2022 Grokbase