Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

html/template: ParseFiles throws away files with the same filename base #14320

Closed
bep opened this issue Feb 13, 2016 · 5 comments
Closed

html/template: ParseFiles throws away files with the same filename base #14320

bep opened this issue Feb 13, 2016 · 5 comments
Labels
FrozenDueToAge
Milestone
Go1.7

Comments

@bep
Copy link
Contributor

bep commented Feb 13, 2016 

go version && uname -a
go version go1.6rc2 darwin/amd64
Darwin bep-mac.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

See the file structure and the example program below.

This caught me by surprise; if this is the intended behavior, it should be made clear in the docs. You should also consider to return an error instead of silently doing the wrong thing.

package main

import (
    "fmt"
    "html/template"
)

func main() {

    /*

        /Users/bep/templ:

        ├── t1
        │   ├── t1.tpl
        │   ├── t2.tpl
        │   └── t3.tpl
        └── t2
            ├── t1.tpl
            └── t3.tpl

    */

    filenames := []string{"/Users/bep/templ/t1/t1.tpl",
        "/Users/bep/templ/t1/t2.tpl",
        "/Users/bep/templ/t1/t3.tpl",
        "/Users/bep/templ/t2/t1.tpl",
        "/Users/bep/templ/t2/t3.tpl"}

    templs, err := template.ParseFiles(filenames...)

    fmt.Println(err)                     // => <nil>
    fmt.Println(templs.Name())           // => t1.tpl
    fmt.Println(len(templs.Templates())) // => 3

    for _, templ := range templs.Templates() {
        fmt.Println(templ.Name())
    }

    // =>
    // t1.tpl
    // t2.tpl
    // t3.tpl
}
@bep
Copy link
Contributor Author

bep commented Feb 13, 2016

An added note: The workaround in the case above is to use template.Parse in a loop.

@bradfitz bradfitz added this to the Go1.7 milestone Apr 10, 2016
@adg
Copy link
Contributor

adg commented Apr 11, 2016

When we originally designed ParseFiles it was illegal to redeclare templates, and so it did indeed return an error. With the addition of the new block feature we removed the restriction on template redeclaration, and so now ParseFiles has this subtle behavior. That's not great.

We could patch up ParseFiles so that it does return an error in this instance, but we've already shipped a major Go version with this behavior and so people might be relying on it already.

That leaves us with a documentation fix, which is easily done. I will prepare it now, but I'm not happy about it.

cc @robpike in case he has other ideas.

@gopherbot
Copy link

CL https://golang.org/cl/21824 mentions this issue.

@bep
Copy link
Contributor Author

bep commented Apr 11, 2016

We could patch up ParseFiles so that it does return an error in this instance, but we've already shipped a major Go version with this behavior and so people might be relying on it already.

As you have released more major versions with the correct behavior, I think that argument is a little bit thin. An error is more visible than a note in the doc.

@adg
Copy link
Contributor

adg commented Apr 11, 2016

The new behavior is backward compatible with the old behavior, but not vice versa. We take compatibility very seriously, and cannot make backward incompatible changes without a very good reason. I don't think this meets the bar.

@golang golang locked and limited conversation to collaborators Apr 22, 2017
@rsc rsc unassigned adg Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
4 participants
@bradfitz @bep @adg @gopherbot