google app engine - standard - ¿Es posible tener plantillas anidadas en Go usando la biblioteca estándar?(Motor de aplicaciones de Google)
google app engine tutorial español (4)
He estado volviendo a esta respuesta durante días, finalmente mordí la bala y escribí una pequeña capa de abstracción / preprocesador para esto. Básicamente
- Agrega la palabra clave ''extends'' a las plantillas.
- Permite anular las llamadas ''definir'' (por lo tanto, son posibles los valores predeterminados para la reglamentación)
- Permite llamadas de ''plantilla'' no definidas, solo dan una cadena vacía
- Establece el valor predeterminado de. en ''plantilla'' llama a. del padre
¿Cómo puedo obtener plantillas anidadas como Jinja en el tiempo de ejecución de Python? TBC, lo que quiero decir es ¿cómo puedo heredar un conjunto de plantillas de una plantilla base, solo archivar en bloques de las plantillas base, como lo hace Jinja / django-templates? ¿Es posible usar solo html/template en la biblioteca estándar?
Si eso no es una posibilidad, ¿cuáles son mis alternativas? El bigote parece ser una opción, pero ¿me estaría perdiendo esas agradables características sutiles de html/template como el escape sensible al contexto, etc.? ¿Qué otras alternativas hay?
(Medio ambiente: Google App Engin, Go runtime v1, Dev - Mac OSx lion)
Gracias por leer.
Sí, es posible. Un html.Template es en realidad un conjunto de archivos de plantilla. Si ejecuta un bloque definido en este conjunto, tiene acceso a todos los otros bloques definidos en este conjunto.
Si crea un mapa de dichos conjuntos de plantillas por su cuenta, tiene básicamente la misma flexibilidad que ofrece Jinja / Django. La única diferencia es que el paquete html/template no tiene acceso directo al sistema de archivos, por lo que debe analizar y componer las plantillas por su cuenta.
Considere el siguiente ejemplo con dos páginas diferentes ("index.html" y "other.html") que ambas heredan de "base.html":
// Content of base.html:
{{define "base"}}<html>
<head>{{template "head" .}}</head>
<body>{{template "body" .}}</body>
</html>{{end}}
// Content of index.html:
{{define "head"}}<title>index</title>{{end}}
{{define "body"}}index{{end}}
// Content of other.html:
{{define "head"}}<title>other</title>{{end}}
{{define "body"}}other{{end}}
Y el siguiente mapa de conjuntos de plantillas:
tmpl := make(map[string]*template.Template)
tmpl["index.html"] = template.Must(template.ParseFiles("index.html", "base.html"))
tmpl["other.html"] = template.Must(template.ParseFiles("other.html", "base.html"))
Ahora puede renderizar su página "index.html" llamando
tmpl["index.html"].Execute("base", data)
y puede presentar su página "other.html" llamando
tmpl["other.html"].Execute("base", data)
Con algunos trucos (por ejemplo, una convención de nomenclatura consistente de sus archivos de plantilla), incluso es posible generar el mapa tmpl automáticamente.
Use Pongo , que es un superconjunto de Go Templates que admite las etiquetas {{extends}} y {{block}} para la herencia de plantillas, al igual que Django.
tenga en cuenta que cuando ejecuta su plantilla base, debe pasar los valores a las plantillas secundarias, aquí simplemente paso ".", para que todo se transmita.
la plantilla uno muestra {{.}}
{{define "base"}}
<html>
<div class="container">
{{.}}
{{template "content" .}}
</div>
</body>
</html>
{{end}}
la plantilla dos muestra {{.domains}} que se pasa al padre.
{{define "content"}}
{{.domains}}
{{end}}
Tenga en cuenta que si usáramos {{template "content".}} En lugar de {{template "content".}}, No podríamos acceder a .domains desde la plantilla de contenido.
DomainsData := make(map[string]interface{})
DomainsData["domains"] = domains.Domains
if err := groupsTemplate.ExecuteTemplate(w, "base", DomainsData); err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
}