Struttura del progetto per Google App Engine


119

Ho avviato un'applicazione in Google App Engine proprio quando è uscita, per giocare con la tecnologia e lavorare su un progetto a cui pensavo da molto tempo ma che non sono mai riuscito a iniziare. Il risultato è BowlSK . Tuttavia, poiché è cresciuto e sono state aggiunte funzionalità, è diventato davvero difficile mantenere le cose organizzate, principalmente a causa del fatto che questo è il mio primo progetto Python e non ne sapevo nulla fino a quando non ho iniziato a lavorare.

Quello che ho:

  • Il livello principale contiene:
    • tutti i file .py (non sapevo come far funzionare i pacchetti)
    • tutti i modelli .html per le pagine di livello principale
  • sottodirectory:
    • cartelle separate per css, immagini, js, ecc.
    • cartelle che contengono modelli .html per gli URL di tipo sottodirectory

Esempio:
http://www.bowlsk.com/ mappa a HomePage (pacchetto predefinito), modello in "index.html"
http://www.bowlsk.com/games/view-series.html?series=7130 mappa a ViewSeriesPage (di nuovo, pacchetto predefinito), modello in "games / view-series.html"

È brutto. Come posso ristrutturare? Avevo 2 idee:

  • Cartella principale contenente: appdef, indexes, main.py?

    • Sottocartella per il codice. Questo deve essere il mio primo pacchetto?
    • Sottocartella per i modelli. La gerarchia delle cartelle corrisponderebbe alla gerarchia dei pacchetti
    • Sottocartelle individuali per css, immagini, js, ecc.
  • Cartella principale contenente appdef, indexes, main.py?

    • Sottocartella per codice + modelli. In questo modo ho la classe gestore proprio accanto al modello, perché in questa fase sto aggiungendo molte funzionalità, quindi le modifiche a una significano modifiche all'altra. Di nuovo, devo fare in modo che questo nome di cartella sia il primo nome del pacchetto per le mie classi? Vorrei che la cartella fosse "src", ma non voglio che le mie classi siano "src.W qualunquePage"

C'è una buona pratica? Con Django 1.0 all'orizzonte, c'è qualcosa che posso fare ora per migliorare la mia capacità di integrarmi con esso quando diventerà il motore di template GAE ufficiale? Vorrei semplicemente iniziare a provare queste cose e vedere quale sembra migliore, ma il supporto per il refactoring di pyDev non sembra gestire molto bene i movimenti dei pacchetti, quindi sarà probabilmente un compito non banale far funzionare tutto di nuovo.

Risposte:


104

Innanzitutto, ti suggerisco di dare un'occhiata a " Sviluppo rapido con Python, Django e Google App Engine "

GvR descrive un layout di progetto generale / standard a pagina 10 della sua presentazione .

Qui posterò una versione leggermente modificata del layout / struttura da quella pagina. Io stesso seguo praticamente questo schema. Hai anche detto che hai avuto problemi con i pacchetti. Assicurati solo che ciascuna delle tue sottocartelle abbia un file __init__.py. Va bene se è vuoto.

File Boilerplate

  • Questi difficilmente variano tra i progetti
  • app.yaml: indirizza tutte le richieste non statiche a main.py
  • main.py: inizializza l'app e invia tutte le richieste

Lay-out del progetto

  • statico / *: file statici; servito direttamente da App Engine
  • myapp / *. py: codice Python specifico per app
    • views.py, models.py, tests.py, __init__.py e altro ancora
  • modelli / *. html: modelli (o miaapp / modelli / *. html)

Di seguito sono riportati alcuni esempi di codice che potrebbero essere utili:

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)

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

frontend / models.py

from google.appengine.ext import db

class SampleModel(db.Model):

Penso che questo layout funzioni alla grande per progetti nuovi e relativamente piccoli e medi. Per progetti più grandi, suggerirei di suddividere le visualizzazioni e i modelli per avere le proprie sottocartelle con qualcosa come:

Lay-out del progetto

  • statico /: file statici; servito direttamente da App Engine
    • JS / *. js
    • images / * gif |. png | jpg
    • css / *. css
  • myapp /: struttura dell'app
    • modelli / *. py
    • views / *. py
    • test / *. py
    • modelli / *. html: modelli

2
Una volta che si arriva a 20 o 30 visualizzazioni e un paio di "visualizzazioni" che gestiscono solo i post e quindi reindirizzano, le suddividete in file separati? Forse in myapp / views / view1.py, myapp / views / view2.py? O solo il mio sfondo Java / C # che si vede?
Chris Marasti-Georg,

1
Ho modificato il mio post per affrontare progetti più grandi. Spero che aiuti. Tieni presente che in alcuni casi sarà un giudizio.
Fuentesjr,

1
Ho un layout simile, ma uso "app" invece di "miaapp".
Alexander Kojevnikov,

Qualcuno potrebbe fornire un esempio funzionante per un tale layout di progetto? Non ho trovato niente di adatto.
herrherr

16

Il mio solito layout è simile a questo:

  • app.yaml
  • index.yaml
  • request.py: contiene l'app WSGI di base
  • lib
    • __init__.py - funzionalità comuni, inclusa una classe base del gestore delle richieste
  • controller: contiene tutti i gestori. request.yaml li importa.
  • modelli
    • tutti i template django, usati dai controller
  • modello
    • tutte le classi di modelli di datastore
  • statico
    • file statici (css, immagini, ecc.). Mappato a / static da app.yaml

Posso fornire esempi di come appaiono i miei controller app.yaml, request.py, lib / init .py e di esempio, se questo non è chiaro.


5
Ciao Nick, per favore fallo! Devo anche confrontare diverse soluzioni :) Grazie!
Hoang Pham

2
Ciao, vorrei vedere anche alcuni esempi se è possibile. Grazie.

11

Oggi ho implementato un boilerplate del motore di app di Google e l'ho controllato su GitHub. Questo è lungo le linee descritte da Nick Johnson sopra (che lavorava per Google).

Segui questo link gae-boilerplate


1
Puoi espandere un po 'questa risposta? Il collegamento github va benissimo per supportare la tua risposta, ma dovresti almeno provare a introdurlo un po '.
Shog9

1
Il file README.md nella radice gae-boilerplate spiega tutto. github.com/droot/gae-boilerplate/blob/master/README.md
Ed Randall

7

Penso che la prima opzione sia considerata la migliore pratica. E rendi la cartella del codice il tuo primo pacchetto. Il progetto Rietveld sviluppato da Guido van Rossum è un ottimo modello da cui imparare. Dai un'occhiata: http://code.google.com/p/rietveld

Per quanto riguarda Django 1.0, ti consiglio di iniziare a utilizzare il codice del trunk Django invece del GAE integrato nel port django. Ancora una volta, dai un'occhiata a come è fatto a Rietveld.


Qual è il miglior motivo per usare Django? Sto usando WebApp e mi sta servendo bene. Inoltre, spero che Google offra presto una migliore integrazione dei due. Qual è lo svantaggio dell'utilizzo del port Django integrato?
jamtoday

3

Mi piace webpy, quindi l'ho adottato come framework di modelli su Google App Engine.
Le cartelle dei miei pacchetti sono generalmente organizzate in questo modo:

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

Ecco un esempio.


1

Non sono del tutto aggiornato sulle ultime best practice, eccetera quando si tratta di layout del codice, ma quando ho fatto la mia prima applicazione GAE, ho usato qualcosa lungo la tua seconda opzione, dove il codice e i modelli sono uno accanto all'altro.

C'erano due ragioni per questo: uno, teneva il codice e il modello nelle vicinanze, e in secondo luogo, avevo il layout della struttura della directory che imitava quello del sito web - rendendo (per me) un po 'più facile anche ricordare dove fosse tutto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.