Google App Engine的项目结构

问题:Google App Engine的项目结构

我刚问世时就在Google App Engine中启动了一个应用程序,以使用该技术并从事一个我一直想了很久但从未尝试过的宠物项目。结果是BowlSK。但是,随着它的增长和功能的添加,使其变得井井有条变得非常困难-主要是因为这是我的第一个python项目,在开始工作之前我对此一无所知。

我有的:

  • 主级别包含:
    • 所有.py文件(不知道如何使程序包正常工作)
    • 主页面的所有.html模板
  • 子目录:
    • 用于CSS,图片,JS等的单独文件夹。
    • 包含用于子目录类型网址的.html模板的文件夹

示例:
http : //www.bowlsk.com/映射到HomePage(默认包),模板位于“ index.html”
http://www.bowlsk.com/games/view-series.html?series=7130映射到ViewSeriesPage(同样是默认程序包),位于“ games / view-series.html”的模板

真讨厌 我如何重组?我有两个想法:

  • 主文件夹包含:appdef,索引,main.py?

    • 代码的子文件夹。这一定是我的第一个包裹吗?
    • 模板的子文件夹。文件夹层次结构将与包层次结构匹配
    • CSS,图像,JS等的单个子文件夹。
  • 主文件夹包含appdef,索引,main.py?

    • 代码+模板的子文件夹。这样,我就在模板旁边设置了处理程序类,因为在此阶段,我要添加许多功能,因此对一个进行修改意味着对另一个进行了修改。同样,我必须将此文件夹名称作为Class的第一个软件包名称吗?我希望文件夹为“ src”,但我不希望我的Class为“ src.WhateverPage”

有最佳做法吗?随着Django 1.0的出现,当它成为正式的GAE模板引擎时,我现在可以做些什么来提高与它的集成能力?我将简单地开始尝试这些事情,然后看一看似乎更好,但是pyDev的重构支持似乎不能很好地处理程序包的移动,因此使所有这些再次工作可能不是一件容易的事。

I started an application in Google App Engine right when it came out, to play with the technology and work on a pet project that I had been thinking about for a long time but never gotten around to starting. The result is BowlSK. However, as it has grown, and features have been added, it has gotten really difficult to keep things organized – mainly due to the fact that this is my first python project, and I didn’t know anything about it until I started working.

What I have:

  • Main Level contains:
    • all .py files (didn’t know how to make packages work)
    • all .html templates for main level pages
  • Subdirectories:
    • separate folders for css, images, js, etc.
    • folders that hold .html templates for subdirecty-type urls

Example:
http://www.bowlsk.com/ maps to HomePage (default package), template at “index.html”
http://www.bowlsk.com/games/view-series.html?series=7130 maps to ViewSeriesPage (again, default package), template at “games/view-series.html”

It’s nasty. How do I restructure? I had 2 ideas:

  • Main Folder containing: appdef, indexes, main.py?

    • Subfolder for code. Does this have to be my first package?
    • Subfolder for templates. Folder heirarchy would match package heirarchy
    • Individual subfolders for css, images, js, etc.
  • Main Folder containing appdef, indexes, main.py?

    • Subfolder for code + templates. This way I have the handler class right next to the template, because in this stage, I’m adding lots of features, so modifications to one mean modifications to the other. Again, do I have to have this folder name be the first package name for my classes? I’d like the folder to be “src”, but I don’t want my classes to be “src.WhateverPage”

Is there a best practice? With Django 1.0 on the horizon, is there something I can do now to improve my ability to integrate with it when it becomes the official GAE templating engine? I would simply start trying these things, and seeing which seems better, but pyDev’s refactoring support doesn’t seem to handle package moves very well, so it will likely be a non-trivial task to get all of this working again.


回答 0

首先,我建议您看看“ 使用Python,Django和Google App Engine进行快速开发

GvR在幻灯片演示文稿的第10页上描述了常规/标准项目布局。

在这里,我将从该页面发布布局/结构的略微修改版本。我本人几乎遵循这种模式。您还提到了打包方面的问题。只要确保您的每个子文件夹都有一个__init__.py文件即可。如果它为空也可以。

样板文件

  • 这些项目之间几乎没有差异
  • app.yaml:将所有非静态请求定向到main.py
  • main.py:初始化应用并发送所有请求

项目布局

  • static / *:静态文件;由App Engine直接提供
  • myapp / *。py:特定于应用的python代码
    • views.py,models.py,tests.py,__ init__.py等
  • templates / *。html:模板(或myapp / templates / *。html)

以下是一些可能也有帮助的代码示例:

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)

myapp / 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")

myapp / models.py

from google.appengine.ext import db

class SampleModel(db.Model):

我认为这种布局非常适合新的和相对较小的中型项目。对于较大的项目,我建议分解视图和模型以使其具有以下子文件夹:

项目布局

  • static /:静态文件;由App Engine直接提供
    • js / *。js
    • 图片/*.gif|png|jpg
    • css / *。css
  • myapp /:应用程序结构
    • 型号/*.py
    • 视图/*.py
    • 测试/*.py
    • templates / *。html:模板

First, I would suggest you have a look at “Rapid Development with Python, Django, and Google App Engine

GvR describes a general/standard project layout on page 10 of his slide presentation.

Here I’ll post a slightly modified version of the layout/structure from that page. I pretty much follow this pattern myself. You also mentioned you had trouble with packages. Just make sure each of your sub folders has an __init__.py file. It’s ok if its empty.

Boilerplate files

  • These hardly vary between projects
  • app.yaml: direct all non-static requests to main.py
  • main.py: initialize app and send it all requests

Project lay-out

  • static/*: static files; served directly by App Engine
  • myapp/*.py: app-specific python code
    • views.py, models.py, tests.py, __init__.py, and more
  • templates/*.html: templates (or myapp/templates/*.html)

Here are some code examples that may help as well:

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)

myapp/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")

myapp/models.py

from google.appengine.ext import db

class SampleModel(db.Model):

I think this layout works great for new and relatively small to medium projects. For larger projects I would suggest breaking up the views and models to have their own sub-folders with something like:

Project lay-out

  • static/: static files; served directly by App Engine
    • js/*.js
    • images/*.gif|png|jpg
    • css/*.css
  • myapp/: app structure
    • models/*.py
    • views/*.py
    • tests/*.py
    • templates/*.html: templates

回答 1

我通常的布局如下所示:

  • app.yaml
  • index.yaml
  • request.py-包含基本的WSGI应用程序
  • LIB
    • __init__.py -常见功能,包括请求处理程序基类
  • 控制器-包含所有处理程序。request.yaml导入这些。
  • 范本
    • 控制器使用的所有django模板
  • 模型
    • 所有数据存储区模型类
  • 静态的
    • 静态文件(css,图像等)。由app.yaml映射到/ static

如果不清楚,我可以提供一些示例,说明我的app.yaml,request.py,lib / init .py和示例控制器的外观。

My usual layout looks something like this:

  • app.yaml
  • index.yaml
  • request.py – contains the basic WSGI app
  • lib
    • __init__.py – common functionality, including a request handler base class
  • controllers – contains all the handlers. request.yaml imports these.
  • templates
    • all the django templates, used by the controllers
  • model
    • all the datastore model classes
  • static
    • static files (css, images, etc). Mapped to /static by app.yaml

I can provide examples of what my app.yaml, request.py, lib/init.py, and sample controllers look like, if this isn’t clear.


回答 2

我今天实现了一个Google App Engine样板,并在github上进行了检查。这与尼克·约翰逊(Nick Johnson)(曾为Google工作)所描述的思路一致。

点击此链接gae-boilerplate

I implemented a google app engine boilerplate today and checked it on github. This is along the lines described by Nick Johnson above (who used to work for Google).

Follow this link gae-boilerplate


回答 3

我认为第一种选择是最佳实践。并将代码文件夹作为您的第一个软件包。Guido van Rossum开发的Rietveld项目是一个很好的学习模型。看看吧:http : //code.google.com/p/rietveld

关于Django 1.0,建议您开始使用Django主干代码,而不要使用内置在django端口中的GAE。再次,看看Rietveld的工作方式。

I think the first option is considered the best practice. And make the code folder your first package. The Rietveld project developed by Guido van Rossum is a very good model to learn from. Have a look at it: http://code.google.com/p/rietveld

With regard to Django 1.0, I suggest you start using the Django trunk code instead of the GAE built in django port. Again, have a look at how it’s done in Rietveld.


回答 4

我喜欢webpy,因此在Google App Engine上将其用作模板框架。
我的软件包文件夹通常是这样组织的:

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

是一个例子。

I like webpy so I’ve adopted it as templating framework on Google App Engine.
My package folders are typically organized like this:

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

Here is an example.


回答 5

在代码布局方面,我并没有完全了解最新的最佳实践等,但是当我完成第一个GAE应用程序时,我在第二个选项中使用了一些东西,其中代码和模板彼此相邻。

造成这种情况的原因有两个:一是将代码和模板保留在附近,其二,我的目录结构布局与网站的布局相似,这对我来说使它变得更容易一点,也记住所有内容在哪里。

I am not entirely up to date on the latest best practices, et cetera when it comes to code layout, but when I did my first GAE application, I used something along your second option, where the code and templates are next to eachother.

There was two reasons for this – one, it kept the code and template nearby, and secondly, I had the directory structure layout mimic that of the website – making it (for me) a bit easier too remember where everything was.