Google App Engineのプロジェクト構造
-
09-06-2019 - |
質問
私は、Google App Engine のアプリケーションがリリースされた直後に、そのテクノロジーを試し、長い間考えていたが着手できなかったペット プロジェクトに取り組むために、アプリケーションを開始しました。結果は ボウルSK. 。しかし、成長し、機能が追加されるにつれて、物事を整理しておくことが非常に難しくなりました。これは主に、これが私にとって初めての 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、インデックス、main.py?
- コードのサブフォルダー。これは最初のパッケージでなければなりませんか?
- テンプレートのサブフォルダー。フォルダー階層はパッケージ階層と一致します
- CSS、画像、JS などの個別のサブフォルダー。
appdef、indexes、main.pyを含むメインフォルダー?
- コードとテンプレートのサブフォルダー。このようにして、テンプレートのすぐ隣にハンドラー クラスが配置されます。この段階では多くの機能を追加するため、一方を変更すると他方も変更されることになります。繰り返しになりますが、このフォルダー名をクラスの最初のパッケージ名にする必要がありますか?フォルダーを「src」にしたいのですが、クラスを「src.WhateverPage」にしたくありません。
ベストプラクティスはありますか?Django 1.0 が目前に迫っていますが、それが公式の GAE テンプレート エンジンになったときに統合する能力を向上させるために今できることはありますか?私は単にこれらのことを試し始めて、どれがより良いと思われるかを確認するだけですが、pyDev のリファクタリング サポートはパッケージの移動をあまりうまく処理していないようです。そのため、これらすべてを再び機能させるのは簡単ではない作業になる可能性があります。
解決
まずは「」をご覧いただければと思います。Python、Django、Google App Engine による迅速な開発"
GvR は、彼の著書の 10 ページで一般的/標準的なプロジェクト レイアウトについて説明しています。 スライドプレゼンテーション.
ここでは、そのページのレイアウト/構造を少し変更したバージョンを投稿します。私自身もほぼこのパターンに従います。パッケージに問題があるともおっしゃっていましたね。各サブフォルダーに __init__.py ファイルがあることを確認してください。空いていれば大丈夫です。
定型ファイル
- これらはプロジェクト間でほとんど変わりません
- app.yaml:すべての非静的リクエストを main.py に送信します
- main.py:アプリを初期化し、すべてのリクエストを送信します
プロジェクトのレイアウト
- 静的/*:静的ファイル。App Engine によって直接提供される
- myapp/*.py:アプリ固有の Python コード
- views.py、models.py、tests.py、__init__.py など
- テンプレート/*.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):
このレイアウトは、新しいプロジェクトや比較的小規模から中規模のプロジェクトに最適だと思います。大規模なプロジェクトの場合は、ビューとモデルを分割して、次のような独自のサブフォルダーを作成することをお勧めします。
プロジェクトのレイアウト
- 静的/:静的ファイル。App Engine によって直接提供される
- js/*.js
- 画像/*.gif|png|jpg
- css/*.css
- myapp/:アプリの構造
- モデル/*.py
- ビュー/*.py
- テスト/*.py
- テンプレート/*.html:テンプレート
他のヒント
私の通常のレイアウトは次のようになります。
- app.yaml
- インデックス.yaml
- request.py - 基本的な WSGI アプリが含まれています
- ライブラリ
__init__.py
- リクエストハンドラー基本クラスを含む共通機能
- コントローラー - すべてのハンドラーが含まれます。request.yaml はこれらをインポートします。
- テンプレート
- コントローラーによって使用されるすべての Django テンプレート
- モデル
- すべてのデータストア モデル クラス
- 静的
- 静的ファイル (CSS、画像など)。app.yaml によって /static にマッピングされる
app.yaml、request.py、lib/ の例を提供できます。初期化これが明確でない場合は、.py とサンプル コントローラーは次のようになります。
今日はGoogle App Engineのボイラープレートを実装し、githubで確認しました。これは、上記の Nick Johnson (元 Google で働いていた) が説明した方針に沿っています。
このリンクに従ってください ゲイ定型文
最初のオプションがベストプラクティスであると考えられます。そして、code フォルダーを最初のパッケージにします。Guido van Rossum によって開発された Rietveld プロジェクトは、学ぶべき非常に優れたモデルです。見てください: http://code.google.com/p/rietveld
Django 1.0 に関しては、django ポートに組み込まれた GAE の代わりに Django トランク コードを使用し始めることをお勧めします。もう一度、リートフェルトでそれがどのように行われるかを見てください。
コード レイアウトに関しては、私は最新のベスト プラクティスなどについて完全に最新の情報を持っているわけではありませんが、最初の GAE アプリケーションを作成したときは、コードとテンプレートが隣り合う 2 番目のオプションに沿ったものを使用しました。
これには 2 つの理由がありました。1 つは、コードとテンプレートを近くに置いたこと、もう 1 つは、ディレクトリ構造のレイアウトを Web サイトのレイアウトに倣わせたため、(私にとって) 何がどこにあるかを少し覚えやすくなったことです。