我的项目当前的结构是把 HTML 模板放在项目根目录下的 templates/
目录中。
我的 HTTP 请求处理程序位于文件系统树的较深层级。
go.mod
templates/webpp/*.html
templates/admin-dashboard/*html
cmd/webapp/main.go
cmd/admin-dashboard/main.go
app/webapp/handlers/handler.go
理想情况下,我希望能够以以下方式使用go:embed:
//go:embed ../../templates
或者
///go:embed $PROJECT_ROOT/templates
不幸的是,这些方法都不存在。go doc embed
指出:
这些模式是相对于包含源文件的包目录进行解释的。路径分隔符是斜杠,即使在Windows系统上也是如此。模式不能包含“。”、“..”或空路径元素,也不能以斜杠开头或结尾。
我可以重新定位模板(但我不想这么做,因为在某些模式下,我的Web应用程序需要相对于运行的二进制文件查看它们)。例如:
webapp <-- binary uses templates at runtime
templates/*.html <-- editable HTML files
因此,我可以让我的构建脚本在编译之前将它们复制到指定位置,但这似乎过于繁琐; 如果我绕过构建脚本,或者忘记或混淆了构建顺序,我可能会得到一个嵌入了v1“旧模板”的v2二进制文件。
或者,我可以将templates/
目录制作成一个包,并导出一个embed.FS
,然后将其注入为我的应用程序的依赖项,但现在我的代码重新结构化以适应嵌入过程。
go:embed是否有可能在未来允许相对于项目根目录的某种类型的嵌入,或者这会引发安全问题?
go:embed是一个很棒的功能,但感觉我被迫使用它- 不管是强制复制、重定位、将我的模板集分解为不同的目录,还是调整我的应用程序以使用依赖项注入。
最佳实践是什么?
go:embed
指令移动到模板目录中会导致依赖注入。你可以以完全相同的方式使用它。唯一改变的是你需要添加一个额外的导入语句,并且FS值现在是包限定的。 - undefined