estrutura do projeto para o Google App Engine

votos
117

Eu comecei uma aplicação no Google App Engine direito quando ele saiu, para jogar com a tecnologia e trabalhar em um projeto de estimação que eu estava pensando por um longo tempo, mas nunca chegado a cerca de partida. O resultado é BowlSK . No entanto, como ele cresceu, e recursos foram adicionados, ele ficou realmente difícil manter as coisas organizadas - principalmente devido ao fato de que este é o meu primeiro projeto de python, e eu não sabia nada sobre isso até que eu comecei a trabalhar.

O que eu tenho:

  • Nível principal contém:
    • todos os arquivos .py (não sabia como fazer pacotes de trabalho)
    • todos os modelos .html para páginas de nível principais
  • subdiretórios:
    • pastas separadas para css, imagens, js, etc.
    • pastas que contêm modelos .html para URLs do tipo subdirecty

Exemplo:
http://www.bowlsk.com/ mapeia para homepage (pacote padrão), modelo em index.html
http://www.bowlsk.com/games/view-series.html?series=7130 mapas para ViewSeriesPage (novamente, o pacote padrão), modelo em jogos / view-series.html

É desagradável. Como faço para reestruturar? Eu tive 2 idéias:

  • Pasta Principal contendo: appdef, índices, main.py?

    • Subpasta para o código. Será que isso tem que ser o meu primeiro pacote?
    • Subpasta para modelos. hierarquia pasta iria corresponder pacote de hierarquia
    • subpastas individuais para css, imagens, js, etc.
  • Pasta Principal contendo appdef, índices, main.py?

    • Subpasta para modelos de código +. Desta forma, eu tenho a classe manipulador ao lado do modelo, porque neste estágio, eu estou adicionando lotes de características, por isso modificações para um modificações médios para o outro. Mais uma vez, tenho de ter este nome da pasta será o primeiro nome do pacote para minhas aulas? Eu gostaria a pasta a ser src, mas eu não quero que minhas aulas para ser src.WhateverPage

Existe uma melhor prática? Com Django 1.0 no horizonte, há algo que eu posso fazer agora para melhorar a minha capacidade de integrar com ele quando ele se torna o motor oficial de templates GAE? Eu poderia simplesmente começar a tentar essas coisas, e vendo o que parece melhor, mas o apoio de refatoração de Pydev não parecem lidar com pacote move muito bem, então ele provavelmente vai ser uma tarefa não-trivial para obter tudo isso funcionar novamente.

Publicado 07/09/2008 em 15:08
fonte usuário
Em outras línguas...                            


6 respostas

votos
102

Primeiro, eu sugiro que você dê uma olhada no " Rápido Desenvolvimento com Python, Django e Google App Engine "

GvR descreve um esquema geral do projeto / padrão na página 10 da sua apresentação de slides .

Aqui eu vou postar uma versão ligeiramente modificada do layout / estrutura a partir dessa página. Eu praticamente seguem este padrão mim. Você também mencionou que você teve problemas com pacotes. Apenas certifique-se cada um dos seus sub-pastas tem um arquivo __init__.py. É ok se o seu vazio.

arquivos clichê

  • Estes dificilmente variam entre projectos
  • app.yaml: direcionar todas as solicitações não-estáticos para main.py
  • main.py: inicializar aplicativo e enviá-lo todos os pedidos

Projeto lay-out

  • / * estáticos: arquivos estáticos; servido directamente pela App Engine
  • . Myapp / * py: app-específica código python
    • views.py, models.py, tests.py, __init__.py, e mais
  • . Templates / * html: modelos (. Ou myapp / templates / * html)

Aqui estão alguns exemplos de código que podem ajudar, bem como:

main.py

import wsgiref.handlers

from google.appengine.ext import webapp
from myapp.views import *

application = webapp.WSGIApplication([
  ('/', IndexHandler),
  ('/foo', FooHandler)
], debug=True)

def main():
  wsgiref.handlers.CGIHandler().run(application)

novaaplicacao / views.py

import os
import datetime
import logging
import time

from google.appengine.api import urlfetch
from google.appengine.ext.webapp import template
from google.appengine.api import users
from google.appengine.ext import webapp
from models import *

class IndexHandler(webapp.RequestHandler):
  def get(self):
    date = "foo"
    # Do some processing        
    template_values = {'data': data }
    path = os.path.join(os.path.dirname(__file__) + '/../templates/', 'main.html')
    self.response.out.write(template.render(path, template_values))

class FooHandler(webapp.RequestHandler):
  def get(self):
    #logging.debug("start of handler")

novaaplicacao / models.py

from google.appengine.ext import db

class SampleModel(db.Model):

Eu acho que este esquema funciona muito bem para novo e relativamente pequeno para projectos de média. Para projetos maiores Sugiro romper os pontos de vista e modelos para ter seus próprios sub-pastas com algo como:

Projeto lay-out

  • arquivos estáticos;: static / servido directamente pela App Engine
    • js / *. js
    • images / * gif |. png | jpg
    • css / *. css
  • / Myapp: estrutura de aplicativo
    • modelos / *. py
    • views / *. py
    • Testes / *. py
    • . Templates / * html: modelos
Respondeu 16/09/2008 em 09:10
fonte usuário

votos
15

Meu layout usual é algo como isto:

  • app.yaml
  • index.yaml
  • request.py - contém o aplicativo básico WSGI
  • lib
    • __init__.py - funcionalidade comum, incluindo uma classe pedido base de manipulador
  • controladores - contém todos os manipuladores. request.yaml importa estes.
  • modelos
    • todos os modelos do Django, usados ​​pelos controladores
  • modelo
    • todas as classes de modelo de armazenamento de dados
  • estático
    • arquivos estáticos (css, imagens, etc). Mapeado para / static por app.yaml

Posso dar exemplos de que o meu app.yaml, request.py, lib / o init .py, e os controladores de amostra semelhante, se isso não é clara.

Respondeu 30/09/2008 em 17:30
fonte usuário

votos
10

Eu implementou um google app engine clichê hoje e verifiquei no github. Este é ao longo das linhas descritas por Nick Johnson acima (que costumava trabalhar para o Google).

Siga este link gae-clichê

Respondeu 21/09/2012 em 18:07
fonte usuário

votos
6

Acho que a primeira opção é considerada a melhor prática. E tornar o código pasta seu primeiro pacote. O projeto Rietveld desenvolvido por Guido van Rossum é um modelo muito bom para aprender. Ter um olhar para ele: http://code.google.com/p/rietveld

Com relação ao Django 1.0, eu sugiro que você começar a usar o código tronco Django em vez do GAE porto construído em Django. Mais uma vez, ter um olhar para como é feito em Rietveld.

Respondeu 15/09/2008 em 23:11
fonte usuário

votos
2

Eu gosto webpy então eu adotei-o como estrutura de modelagem no Google App Engine.
As minhas pastas de pacotes são normalmente organizados desta forma:

app.yaml
application.py
index.yaml
/app
   /config
   /controllers
   /db
   /lib
   /models
   /static
        /docs
        /images
        /javascripts
        /stylesheets
   test/
   utility/
   views/

Aqui é um exemplo.

Respondeu 23/06/2010 em 21:30
fonte usuário

votos
1

Eu não estou totalmente atualizado sobre as últimas melhores práticas, et cetera quando se trata de layout de código, mas quando eu fiz meu primeiro aplicativo GAE, eu usei algo ao longo de sua segunda opção, onde o código e modelos estão ao lado da outra.

Houve duas razões para isso - um, ele manteve o código e modelo nas proximidades, e em segundo lugar, eu tinha o layout estrutura de diretórios imitar a do website - tornando-se (para mim) um pouco mais fácil também se lembrar onde estava tudo.

Respondeu 07/09/2008 em 15:25
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more