Структура проекта для Google App Engine


119

Я запустил приложение в Google App Engine сразу после его выхода, чтобы поиграть с технологией и поработать над домашним проектом, о котором я думал долгое время, но так и не успел начать. Результат - BowlSK . Однако по мере того, как он разрастался и добавлялись функции, стало действительно сложно поддерживать порядок - в основном из-за того, что это мой первый проект на Python, и я ничего о нем не знал, пока не начал работать.

Что у меня есть:

  • Основной уровень содержит:
    • все файлы .py (не знал, как заставить пакеты работать)
    • все шаблоны .html для страниц основного уровня
  • подкаталоги:
    • отдельные папки для css, изображений, js и т. д.
    • папки, содержащие шаблоны .html для URL-адресов подкаталога

Пример:
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, indexes, main.py?

    • Подпапка для кода + шаблонов. Таким образом, у меня есть класс обработчика прямо рядом с шаблоном, потому что на этом этапе я добавляю множество функций, поэтому изменения одного означают изменения другого. Опять же, нужно ли, чтобы это имя папки было первым именем пакета для моих классов? Я бы хотел, чтобы папка была "src", но я не хочу, чтобы мои классы были "src.WhateverPage"

Есть лучшая практика? С Django 1.0 на горизонте, могу ли я что-то сделать сейчас, чтобы улучшить мою способность интегрироваться с ним, когда он станет официальным движком шаблонов GAE? Я бы просто начал пробовать эти вещи и смотреть, что кажется лучше, но поддержка рефакторинга pyDev, похоже, не очень хорошо справляется с перемещением пакетов, поэтому, вероятно, будет нетривиальной задачей заставить все это снова работать.

Ответы:


104

Во-первых, я бы посоветовал вам взглянуть на « Быстрая разработка с помощью 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: templates (или 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 /: структура приложения
    • модели / *. ру
    • просмотров / *. ру
    • Тесты / *. ру
    • шаблоны / *. html: шаблоны

2
Как только у вас будет 20 или 30 просмотров и пара «просмотров», которые просто обрабатывают сообщения, а затем перенаправляют, вы разбиваете их на отдельные файлы? Возможно, в myapp / views / view1.py, myapp / views / view2.py? Или просвечивает только мой фон Java / C #?
Крис Марасти-Георг,

1
Я отредактировал свой пост, чтобы обратиться к более крупным проектам. Надеюсь, это поможет. Имейте в виду, что в некоторых случаях это будет приговор.
fuentesjr

1
У меня похожий макет, но я использую «app» вместо «myapp».
Александр Кожевников

Может ли кто-нибудь предоставить рабочий пример такого макета проекта? Ничего подходящего не нашел.
herrherr

16

Мой обычный макет выглядит примерно так:

  • app.yaml
  • index.yaml
  • request.py - содержит базовое приложение WSGI
  • Lib
    • __init__.py - общий функционал, включая базовый класс обработчика запросов
  • контроллеры - содержит все обработчики. request.yaml импортирует их.
  • шаблоны
    • все шаблоны django, используемые контроллерами
  • модель
    • все классы моделей хранилища данных
  • статический
    • статические файлы (css, изображения и т. д.). Сопоставляется с / static с помощью app.yaml

Я могу привести примеры того, как выглядят мои app.yaml, request.py, lib / init .py и образцы контроллеров, если это не ясно.


5
Привет, Ник, сделай это, пожалуйста! Мне тоже нужно сравнить разные решения :) Спасибо!
Хоанг Фам,

2
Привет, я тоже хотел бы увидеть несколько примеров, если это возможно. Спасибо.

11

Сегодня я реализовал шаблон движка Google app и проверил его на github. Это примерно так, как описано выше Ником Джонсоном (который раньше работал в Google).

Перейдите по этой ссылке gae-template


1
Не могли бы вы немного расширить этот ответ? Ссылка на github хороша для поддержки вашего ответа, но вы должны хотя бы попытаться немного ее представить.
Shog9,

1
README.md в корне gae-шаблона объясняет все. github.com/droot/gae-boilerplate/blob/master/README.md
Эд Рэндалл

7

Я думаю, что первый вариант считается лучшим. И сделайте папку с кодом своим первым пакетом. Проект Ритвельда, разработанный Гвидо ван Россумом, - очень хорошая модель, на которой можно учиться. Взгляните на это: http://code.google.com/p/rietveld

Что касается Django 1.0, я предлагаю вам начать использовать магистральный код Django вместо встроенного в порт django GAE. Опять же, посмотрите, как это делается в Ритвельде.


Какая лучшая причина использовать Django? Я использую WebApp, и он мне очень помогает. Кроме того, я надеюсь, что Google когда-нибудь предложит лучшую интеграцию этих двух систем. Каковы недостатки использования встроенного порта Django?
jamtoday

3

Мне нравится webpy, поэтому я использовал его как структуру шаблонов в Google App Engine.
Мои папки с пакетами обычно организованы следующим образом:

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

Вот пример.


1

Я не совсем в курсе последних передовых практик и т. Д., Когда дело доходит до макета кода, но когда я делал свое первое приложение GAE, я использовал кое-что из вашего второго варианта, когда код и шаблоны находятся рядом друг с другом.

Для этого было две причины: во-первых, он держал код и шаблон рядом, а во-вторых, у меня был макет структуры каталогов, имитирующий структуру веб-сайта, что (для меня) немного упрощало запоминание, где все находится.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.