Google App Engineのプロジェクト構造

Google App Engineでアプリケーションを開発し始めたとき、そのテクノロジーをいじって、ずっと考えていたペットプロジェクトに取り組みました。結果はBowlSKです。しかし、それが成長し、機能が追加されるにつれて、物事を整理しておくことが本当に難しくなりました。これは主に、これが私の最初のpythonプロジェクトであり、作業を開始するまでそれについて何も知りませんでした。

私が持っているもの：

• メインレベルに含まれるもの：
  • すべての.pyファイル（パッケージを機能させる方法がわかりませんでした）
  • メインレベルページのすべての.htmlテンプレート
• サブディレクトリ：
  • CSS、画像、JSなどの個別のフォルダー
  • サブディレクトリタイプのURLの.htmlテンプレートを保持するフォルダ

例：
http : //www.bowlsk.com/はHomePage（デフォルトパッケージ）にマップされ、テンプレートは "index.html"にあり
ますhttp://www.bowlsk.com/games/view-series.html?series=7130はマップされますViewSeriesPage（ここでも、デフォルトパッケージ）、「games / view-series.html」のテンプレート

それは厄介です。どのように再構成しますか？私には2つのアイデアがありました：

• メインフォルダに含まれるもの：appdef、indexes、main.py？

  • コードのサブフォルダー。これは私の最初のパッケージでなければなりませんか？
  • テンプレートのサブフォルダー。フォルダ階層はパッケージ階層と一致します
  • CSS、画像、JSなどの個々のサブフォルダー

• appdef、indexs、main.pyを含むメインフォルダ？

  • コード+テンプレートのサブフォルダー。このようにして、テンプレートのすぐ隣にハンドラークラスを配置します。この段階では、多くの機能を追加するため、一方の変更は他方の変更を意味します。ここでも、このフォルダー名をクラスの最初のパッケージ名にする必要がありますか？フォルダを「src」にしたいのですが、クラスを「src.WhateverPage」にしたくありません

ベストプラクティスはありますか？地平線上のDjango 1.0で、公式のGAEテンプレートエンジンになったときに、Django 1.0と統合する能力を向上させるために今できることはありますか？私は単にこれらのことを試してみて、どちらがより良いように見えるかを確認しますが、pyDevのリファクタリングサポートはパッケージの移動をうまく処理していないようです。

まず、「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
  • images / *。gif | png | jpg
  • css / *。css
• myapp /：アプリの構造
  • モデル/*.py
  • views / *。py
  • tests / *。py
  • templates / *。html：テンプレート

私の通常のレイアウトは次のようになります。

• app.yaml
• index.yaml
• request.py-基本的なWSGIアプリが含まれています
• lib
  • __init__.py -要求ハンドラ基本クラスを含む一般的な機能
• コントローラ-すべてのハンドラが含まれています。request.yamlはこれらをインポートします。
• テンプレート
  • コントローラーが使用するすべてのdjangoテンプレート
• モデル
  • すべてのデータストアモデルクラス
• 静的
  • 静的ファイル（css、画像など）。app.yamlによって/ staticにマッピングされます

これが明確でない場合、私のapp.yaml、request.py、lib / init .py、およびサンプルコントローラーがどのように見えるかの例を提供できます。

今日、Google App Engineのボイラープレートを実装し、githubで確認しました。これは、（Googleで働いていた）上記のニックジョンソンが述べたとおりです。

このリンクに従いGAE-定型文を

最初のオプションはベストプラクティスと考えられています。そして、コードフォルダーを最初のパッケージにします。Guido van Rossumによって開発されたRietveldプロジェクトは、学ぶべき非常に良いモデルです。それを見てください：http : //code.google.com/p/rietveld

Django 1.0に関しては、GAEに組み込まれているdjangoポートの代わりにDjangoトランクコードを使い始めることをお勧めします。もう一度、リートフェルトでそれがどのように行われるかを見てください。

私はwebpyが好きなので、Google App Engineのテンプレートフレームワークとして採用しました。
私のパッケージフォルダーは通常、次のように構成されています。

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

ここでは一例です。

コードレイアウトに関しては、最新のベストプラクティスなどについては完全に最新ではありませんが、最初のGAEアプリケーションを実行したとき、コードとテンプレートが隣り合っている2番目のオプションに沿って何かを使用しました。

これには2つの理由がありました。1つはコードとテンプレートが近くにあること、もう1つは、ディレクトリ構造のレイアウトがWebサイトのレイアウトを模倣していることです。