46 votes

Go, AppEngine : Comment structurer les modèles d'application ?

Comment les gens gèrent-ils l'utilisation de modèles dans leurs applications AppEngine basées sur Go ?

Plus précisément, je suis à la recherche d'une structure de projet qui offre les possibilités suivantes :

  • Structure hiérarchique (répertoire) des modèles et des modèles partiels
  • me permettre d'utiliser des outils/éditeurs HTML sur mes modèles (l'intégration du texte des modèles dans les fichiers xxx.go rend cela difficile)
  • Rechargement automatique du texte du modèle sur le serveur de développement

Les pierres d'achoppement potentielles sont :

  • template.ParseGlob() ne traversera pas récursivement.
  • Pour des raisons de performances, il a été recommandé de ne pas télécharger vos modèles sous forme de fichiers texte bruts (car ces fichiers texte résident sur des serveurs différents de ceux qui exécutent le code).

Veuillez noter que je ne cherche pas un tutoriel/des exemples d'utilisation du paquet de modèles. Il s'agit plutôt d'une question sur la structure de l'application. Ceci étant dit, si vous avez du code qui résout les problèmes ci-dessus, j'aimerais le voir. Merci d'avance.

68voto

Kyle Finley Points 3301

L'une de mes caractéristiques préférées de Go est la possibilité d'ajouter facilement des gestionnaires à l'intérieur des paquets. Cela simplifie grandement le processus d'écriture de code modulaire.

Par exemple :

Structure du fichier

|-- app.yaml
|-- app
|   +-- http.go
|-- templates
|   +-- base.html
+-- github.com
    +-- storeski
        +-- appengine
            |-- products
            |   |-- http.go
            |   +-- templates
            |       |-- list.html
            |       +-- detail.html 
            +-- account
                |-- http.go
                +-- templates
                    |-- overview.html
                    +-- notifications.html 

Chaque paquet a un fichier http.go qui prend en charge un préfixe url. Par exemple, le fichier products paquet sous github.com/storeski/appengine/products posséderait toute url entrante commençant par /products .

Avec cette approche modulaire, il est avantageux de stocker les modèles au sein de l'arborescence de l'entreprise. products paquet. Si vous souhaitez conserver un modèle de base cohérent pour le site, vous pouvez établir une convention dans laquelle vous étendez les éléments suivants templates/base.html .

Exemple

modèles/base.html

<!DOCTYPE HTML>
<html>
  <head>
    <title>{{.Store.Title}}</title>
  </head>

  <body>
    <div id="content">
      {{template "content" .}}
    </div>
  </body>
</html>

github.com/storeski/appengine/produits/templates/list.html

{{define "content"}}
  <h1> Products List </h1>
{{end}}

github.com/storeski/appengine/produits/http.go

func init() {
  http.HandleFunc("/products", listHandler)
}

var listTmpl = template.Must(template.ParseFiles("templates/base.html",
  "github.com/storeski/appengine/products/templates/list.html"))

func listHandler(w http.ResponseWriter, r *http.Request) {

  tc := make(map[string]interface{})
  tc["Store"] = Store
  tc["Products"] = Products

  if err := listTmpl.Execute(w, tc); err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
  }
}

Cette approche est très intéressante car elle rend le partage des applications/paquets trivial. Si j'écris un paquet qui s'occupe de l'authentification et qui prend la propriété de l'application /auth url. Tout développeur qui ajoute ensuite le paquet à son produit Root dispose instantanément de toutes les fonctionnalités. Tout ce qu'il a à faire est de créer un modèle de base ( templates/base.html ) et dirigent leurs utilisateurs vers /auth .

0voto

Jimmy Zelinskie Points 472

Je m'excuse d'avance car ce billet n'est pas vraiment ce que vous recherchez et vous avez peut-être déjà entendu ce que je vais dire un million de fois. Mais c'est mieux que pas de post du tout, alors voilà :

Le Go 1 sera publié très prochainement (dans une semaine ou deux). Je suis certain que App Engine va passer à la prise en charge de Go 1 par rapport à r60 relativement vite après. Les corelibs de template (parmi d'autres librairies) ont été modifiées à plusieurs reprises au cours de cette période. Il est donc difficile de trouver la façon la plus populaire de faire les choses en raison des nombreux changements apportés au langage.

Ceci étant dit, j'ai vu pas mal de personnes s'attaquer à ce problème de différentes manières, mais très peu d'entre elles étaient spécifiques à AppEngine parce que la plupart du travail effectué en Go est maintenu à jour avec le langage (qui est depuis longtemps non compatible avec r60). Si vous voulez voir une partie du code que les gens ont utilisé pour des projets similaires, vous devriez sauter sur IRC et demander. Les templates sont un sujet populaire et je n'ai utilisé que des fonctionnalités de base avec eux -- je n'ai jamais touché aux sets. L'IRC est très convivial et vous pouvez y apprendre beaucoup. C'est certainement la meilleure ressource en dehors de la documentation pour le moment pour ce langage. Au cas où vous ne le sauriez pas déjà, le canal IRC est #go-nuts sur FreeNode.

Merci de votre lecture et bonne chance pour le développement sur App Engine. J'espère que les mises à jour de Go 1 se feront rapidement.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X