Projektstruktur für Google App Engine


119

Ich habe eine Anwendung in Google App Engine gestartet, als sie herauskam, um mit der Technologie zu spielen und an einem Haustierprojekt zu arbeiten, über das ich lange nachgedacht hatte, das ich aber nie gestartet habe. Das Ergebnis ist BowlSK . Da es jedoch gewachsen ist und Funktionen hinzugefügt wurden, ist es wirklich schwierig geworden, die Dinge organisiert zu halten - hauptsächlich aufgrund der Tatsache, dass dies mein erstes Python-Projekt ist und ich nichts davon wusste, bis ich anfing zu arbeiten.

Was ich habe:

  • Hauptebene enthält:
    • alle .py-Dateien (wusste nicht, wie Pakete funktionieren)
    • Alle HTML-Vorlagen für Seiten der Hauptebene
  • Unterverzeichnisse:
    • separate Ordner für CSS, Bilder, JS usw.
    • Ordner mit HTML-Vorlagen für URLs vom Typ Unterverzeichnis

Beispiel:
http://www.bowlsk.com/ wird HomePage (Standardpaket) zugeordnet, Vorlage unter "index.html"
http://www.bowlsk.com/games/view-series.html?series=7130 wird zugeordnet ViewSeriesPage (wieder Standardpaket), Vorlage unter "games / view-series.html"

Es ist fies. Wie restrukturiere ich? Ich hatte 2 Ideen:

  • Hauptordner mit: appdef, indexes, main.py?

    • Unterordner für Code. Muss dies mein erstes Paket sein?
    • Unterordner für Vorlagen. Die Ordner-Hierarchie würde der Paket-Hierarchie entsprechen
    • Einzelne Unterordner für CSS, Bilder, JS usw.
  • Hauptordner mit appdef, indexes, main.py?

    • Unterordner für Code + Vorlagen. Auf diese Weise habe ich die Handler-Klasse direkt neben der Vorlage, da ich in dieser Phase viele Funktionen hinzufüge, sodass Änderungen an einer Funktion Änderungen an der anderen bedeuten. Muss dieser Ordnername der erste Paketname für meine Klassen sein? Ich möchte, dass der Ordner "src" ist, aber ich möchte nicht, dass meine Klassen "src.WhateverPage" sind.

Gibt es eine bewährte Methode? Kann ich mit Django 1.0 am Horizont jetzt etwas tun, um meine Integrationsfähigkeit zu verbessern, wenn es zur offiziellen GAE-Template-Engine wird? Ich würde einfach anfangen, diese Dinge auszuprobieren und zu sehen, was besser erscheint, aber die Refactoring-Unterstützung von pyDev scheint Paketbewegungen nicht sehr gut zu handhaben, so dass es wahrscheinlich eine nicht triviale Aufgabe sein wird, all dies wieder zum Laufen zu bringen.

Antworten:


104

Zunächst würde ich vorschlagen, dass Sie sich " Rapid Development with Python, Django und Google App Engine " ansehen.

GvR beschreibt ein allgemeines / Standard-Projektlayout auf Seite 10 seiner Folienpräsentation .

Hier werde ich eine leicht modifizierte Version des Layouts / der Struktur von dieser Seite veröffentlichen. Ich folge diesem Muster ziemlich genau. Sie haben auch erwähnt, dass Sie Probleme mit Paketen hatten. Stellen Sie einfach sicher, dass jeder Ihrer Unterordner eine __init__.py-Datei enthält. Es ist in Ordnung, wenn es leer ist.

Boilerplate-Dateien

  • Diese variieren kaum zwischen den Projekten
  • app.yaml: Leitet alle nicht statischen Anforderungen an main.py
  • main.py: App initialisieren und alle Anfragen senden

Projektlayout

  • statisch / *: statische Dateien; wird direkt von App Engine bereitgestellt
  • myapp / *. py: App-spezifischer Python-Code
    • views.py, models.py, tests.py, __init__.py und mehr
  • Vorlagen / *. html: Vorlagen (oder myapp / templates / *. html)

Hier sind einige Codebeispiele, die ebenfalls hilfreich sein können:

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):

Ich denke, dieses Layout eignet sich hervorragend für neue und relativ kleine bis mittlere Projekte. Für größere Projekte würde ich vorschlagen, die Ansichten und Modelle aufzuteilen, um eigene Unterordner mit folgenden Elementen zu haben:

Projektlayout

  • statische /: statische Dateien; wird direkt von App Engine bereitgestellt
    • js / *. js
    • images / *. gif | png | jpg
    • css / *. css
  • myapp /: App-Struktur
    • Modelle / *. py
    • Ansichten / *. py
    • Tests / *. py
    • Vorlagen / *. html: Vorlagen

2
Wenn Sie 20 oder 30 Ansichten und ein paar "Ansichten" erhalten, die nur Beiträge verarbeiten und dann umleiten, teilen Sie sie in separate Dateien auf? Vielleicht in myapp / views / view1.py, myapp / views / view2.py? Oder dass nur mein Java / C # -Hintergrund durchscheint?
Chris Marasti-Georg

1
Ich habe meinen Beitrag bearbeitet, um größere Projekte anzusprechen. Ich hoffe das hilft. Denken Sie daran, dass es sich in einigen Fällen um ein Urteil handelt.
fuentesjr

1
Ich habe ein ähnliches Layout, verwende aber "app" anstelle von "myapp".
Alexander Kojevnikov

Könnte jemand ein funktionierendes Beispiel für ein solches Projektlayout liefern? Ich habe nichts Passendes gefunden.
Herrherr

16

Mein übliches Layout sieht ungefähr so ​​aus:

  • app.yaml
  • index.yaml
  • request.py - enthält die grundlegende WSGI-App
  • lib
    • __init__.py - Gemeinsame Funktionalität, einschließlich einer Basisklasse für Anforderungshandler
  • Controller - enthält alle Handler. request.yaml importiert diese.
  • Vorlagen
    • Alle Django-Vorlagen, die von den Controllern verwendet werden
  • Modell-
    • alle Datenspeichermodellklassen
  • statisch
    • statische Dateien (CSS, Bilder usw.). Von app.yaml auf / static abgebildet

Ich kann Beispiele dafür bereitstellen, wie meine app.yaml-, request.py-, lib / init .py- und Beispiel-Controller aussehen, wenn dies nicht klar ist.


5
Hallo Nick, bitte mach es! Ich muss auch zwischen verschiedenen Lösungen vergleichen :) Danke!
Hoang Pham

2
Hallo, ich würde auch gerne einige Beispiele sehen, wenn das möglich ist. Vielen Dank.

11

Ich habe heute ein Google App Engine Boilerplate implementiert und es auf Github überprüft. Dies entspricht den oben beschriebenen Vorgaben von Nick Johnson (der früher für Google gearbeitet hat).

Folgen Sie diesem Link gae-boilerplate


1
Können Sie diese Antwort etwas erweitern? Der Github-Link ist gut und gut, um Ihre Antwort zu unterstützen, aber Sie sollten zumindest versuchen, ihn ein wenig einzuführen.
Shog9

1
Die README.md im Stammverzeichnis von gae-boilerplate erklärt alles. github.com/droot/gae-boilerplate/blob/master/README.md
Ed Randall

7

Ich denke, die erste Option wird als die beste Vorgehensweise angesehen. Und machen Sie den Codeordner zu Ihrem ersten Paket. Das von Guido van Rossum entwickelte Rietveld-Projekt ist ein sehr gutes Modell, von dem man lernen kann. Schauen Sie sich das an: http://code.google.com/p/rietveld

In Bezug auf Django 1.0 schlage ich vor, dass Sie den Django-Trunk-Code anstelle des im Django-Port integrierten GAE verwenden. Schauen Sie sich noch einmal an, wie es in Rietveld gemacht wird.


Was ist der beste Grund, Django zu verwenden? Ich habe WebApp verwendet und es hat mir gut getan. Außerdem hoffe ich, dass Google bald eine bessere Integration der beiden anbieten wird. Was ist der Nachteil bei der Verwendung des eingebauten Django-Hafens?
jamtoday

3

Ich mag Webpy, deshalb habe ich es als Vorlagen-Framework in Google App Engine übernommen.
Meine Paketordner sind normalerweise folgendermaßen organisiert:

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

Hier ist ein Beispiel.


1

Ich bin nicht ganz auf dem neuesten Stand der neuesten Best Practices und so weiter, wenn es um das Code-Layout geht, aber als ich meine erste GAE-Anwendung durchgeführt habe, habe ich etwas in Ihrer zweiten Option verwendet, bei der Code und Vorlagen nebeneinander liegen.

Dafür gab es zwei Gründe: Zum einen wurde der Code und die Vorlage in der Nähe gehalten, und zum anderen ließ ich das Layout der Verzeichnisstruktur das der Website nachahmen - was es (für mich) ein bisschen einfacher machte, sich auch daran zu erinnern, wo sich alles befand.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.