I started an application in Google App Engine right when it came out, to play with the technology and work on a pet project that I had been thinking about for a long time but never gotten around to starting. The result is BowlSK. However, as it has grown, and features have been added, it has gotten really difficult to keep things organized - mainly due to the fact that this is my first python project, and I didn't know anything about it until I started working.
What I have:
Main Level contains:
all .py files (didn't know how to make packages work)
all .html templates for main level pages
Subdirectories:
separate folders for css, images, js, etc.
folders that hold .html templates for subdirecty-type urls
Example:
http://www.bowlsk.com/ maps to HomePage (default package), template at "index.html"
http://www.bowlsk.com/games/view-series.html?series=7130 maps to ViewSeriesPage (again, default package), template at "games/view-series.html"
It's nasty. How do I restructure? I had 2 ideas:
Main Folder containing: appdef, indexes, main.py?
Subfolder for code. Does this have to be my first package?
Subfolder for templates. Folder heirarchy would match package heirarchy
Individual subfolders for css, images, js, etc.
Main Folder containing appdef, indexes, main.py?
Subfolder for code + templates. This way I have the handler class right next to the template, because in this stage, I'm adding lots of features, so modifications to one mean modifications to the other. Again, do I have to have this folder name be the first package name for my classes? I'd like the folder to be "src", but I don't want my classes to be "src.WhateverPage"
Is there a best practice? With Django 1.0 on the horizon, is there something I can do now to improve my ability to integrate with it when it becomes the official GAE templating engine? I would simply start trying these things, and seeing which seems better, but pyDev's refactoring support doesn't seem to handle package moves very well, so it will likely be a non-trivial task to get all of this working again.
First, I would suggest you have a look at "Rapid Development with Python, Django, and Google App Engine"
GvR describes a general/standard project layout on page 10 of his slide presentation.
Here I'll post a slightly modified version of the layout/structure from that page. I pretty much follow this pattern myself. You also mentioned you had trouble with packages. Just make sure each of your sub folders has an __init__.py file. It's ok if its empty.
Boilerplate files
These hardly vary between projects
app.yaml: direct all non-static requests to main.py
main.py: initialize app and send it all requests
Project lay-out
static/*: static files; served directly by App Engine
myapp/*.py: app-specific python code
views.py, models.py, tests.py, __init__.py, and more
templates/*.html: templates (or myapp/templates/*.html)
Here are some code examples that may help as well:
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):
I think this layout works great for new and relatively small to medium projects. For larger projects I would suggest breaking up the views and models to have their own sub-folders with something like:
Project lay-out
static/: static files; served directly by App Engine
js/*.js
images/*.gif|png|jpg
css/*.css
myapp/: app structure
models/*.py
views/*.py
tests/*.py
templates/*.html: templates
My usual layout looks something like this:
app.yaml
index.yaml
request.py - contains the basic WSGI app
lib
__init__.py - common functionality, including a request handler base class
controllers - contains all the handlers. request.yaml imports these.
templates
all the django templates, used by the controllers
model
all the datastore model classes
static
static files (css, images, etc). Mapped to /static by app.yaml
I can provide examples of what my app.yaml, request.py, lib/init.py, and sample controllers look like, if this isn't clear.
I implemented a google app engine boilerplate today and checked it on github. This is along the lines described by Nick Johnson above (who used to work for Google).
Follow this link gae-boilerplate
I think the first option is considered the best practice. And make the code folder your first package. The Rietveld project developed by Guido van Rossum is a very good model to learn from. Have a look at it: http://code.google.com/p/rietveld
With regard to Django 1.0, I suggest you start using the Django trunk code instead of the GAE built in django port. Again, have a look at how it's done in Rietveld.
I like webpy so I've adopted it as templating framework on Google App Engine.
My package folders are typically organized like this:
app.yaml
application.py
index.yaml
/app
/config
/controllers
/db
/lib
/models
/static
/docs
/images
/javascripts
/stylesheets
test/
utility/
views/
Here is an example.
I am not entirely up to date on the latest best practices, et cetera when it comes to code layout, but when I did my first GAE application, I used something along your second option, where the code and templates are next to eachother.
There was two reasons for this - one, it kept the code and template nearby, and secondly, I had the directory structure layout mimic that of the website - making it (for me) a bit easier too remember where everything was.
Related
I've got two Django apps that will end up sharing a lot of code (both reference an external API and do data manipulation on what that API returns). I'm trying to find out how to properly share code between the two apps.
So far I've been trying to have a third app that's imported by the first two, so my file structure looks something like this:
\MyProject
\app1
__init__.py
views.py
\app2
__init__.py
views.py
\common
__init__.py
myCommonCode.py
But when I try the following from app1 or app2 I don't see myCommonCode.py
import common
print dir(common)
All three apps are included in my INSTALLED_APPS in my settings.py.
I am certain there's something simple I'm missing, I just can't seem to find out what it is. To clarify, I am NOT trying to share the same model at this point, but the same python code for reaching out to an external API.
You don't see a sub-module if you import a package. You have to import it in the
__init__.py or directly:
from common import myCommonCode
Creating a custom tag in Google App Engine Python2.5 with Webapp used to be a joyful experience. Here: Django templates and variable attributes
But now, in Python 2.7 with Webapp2 and Django 1.2, it is a pain in the ass. I can only find bits of information here and there, and some of the methods contradict with each other.
The method described in http://www.john-smith.me/Tag/webapp2 ranks high in Google, but some people claim it is "what a waste of time" Webapp2 custom tags
This one method seems to work
from django.template.loader import add_to_builtins
add_to_builtins('xxxxx')
But I dont know the details. Who can provide a step by step example?
I dont know why there are no official documents about these stuff. I mean, this is not science experiments in which we explore the unknown. There supposed to be some documentation so the developers can save their time.
I had same problem.
The fix:
Create templatetags folder. Add there module with custom tags as explained in Django docs Custom template tags and filters.
Example folder structure:
app.yaml
myapp/
__init__.py
templatetags/
__init__.py
my_tags.py
In settings.py set INSTALLED_APPS to myapp (name of folder which contains templatetags sub-folder):
INSTALLED_APPS = ( 'myapp' )
Now when you call {% load my_tags %} in template Django should also seek the mytags module in myapp/*/templatetags/ folder.
I have multiple Django apps, and I have some code in one of my models.py that really applies to all of the apps. Is there a way to move it somewhere generic, outside of a specific app folder?
Examples of non app specific code I have:
def update_groups(sender, user=None, ldap_user=None, **kwargs):
...
django_auth_ldap.backend.populate_user.connect(update_groups)
A function to correctly identify users, and connect to the correct signal.
I also have a model proxy of django.contrib.admin.models.LogEntry and a modelAdmin of that model proxy so users in the admin site can view the change history. But these really don't belong in any one app's models.py.
Well, just create a python module somewhere in your project and then refference it in your models. To do this, you need a directory with __init__.py file:
helpers/
__init__.py
functions.py
Put your code into the functions.py and in any other place you will be able to:
from helpers.functions import update_groups
post_save.connect(update_groups)
Name of the module is up to you, ofcourse.
You could create a template app that could be used or extended (class hierarchy) by all your other apps that could use that code.
__init__.py in my project's directory seems to be a good place to put this stuff. It gets run right away when the server starts so it's available to everything else. It seems to work fine so far.
I've been developing in Pylons for a little while now and have recently learned they're merging with another framework to create Pyramid.
I've been looking over example code to see the differences and it's causing a bit of confusion...
For example, Controllers have been replaced by Views. Not a big problem... But what I find interesting is there's no directories for these. It's simply one file: views.py.
How does this new MVC structure work? Do I write all my actions into this one file? That could get rather annoying when I have similarly named actions (multiple indexes, for example) :/
Could you point me in the direction of some good tutorials/documentation on how to use this framework?
Since the various view-related configuration methods (config.add_view, config.add_handler) require you to pass a dotted name as the class or function to be used as a view or handler, you can arrange your code however you like.
For example, if your project package name were myproject and wanted to arrange all your views in a Python subpackage within the myproject package named "views" (see http://docs.python.org/tutorial/modules.html#packages) instead of a single views file, you might:
Create a views directory inside your mypackage package.
Move the existing views.py file to a file inside the new views directory named, say,
blog.py.
Create a file within the new views directory named __init__.py (it can be empty,
this just tells Python that the views directory is a package.
Then change the __init__.py of your myproject project (not the __init__.py you just created in the views directory, the one in its parent directory) from something like:
config.add_handler('myhandler', '/my/handler', handler='mypackage.views.MyHandler')
To:
config.add_handler('myhandler', '/my/handler', handler='mypackage.views.blog.MyHandler')
You can then continue to add files to the views directory, and refer to views or handler classes/functions within those files via the dotted name passed as handler= or view=.
Here is one answer that should be pretty straight forward. This question was asked when Pyramid 1.3 wasn't yet out. So forget about python handlers since the new decorator do a pretty good job now.
But just to start: Pyramid doesn't have any common structure. You could possibly write a whole app in one single file if you wanted. In other words, if you liked how pylons was structured, you can go with it. If you prefer to setup your own structure then go for it.
If your site doesn't need more than one file then...GO FOR IT!!! All you really need is that it works.
I personally have a structure like that
- root
- __init__.py # all setup goes there
- security.py # where functions related to ACL and group_finder
- models.py or models/ # where all my models go
- views.py or views/ # where all my views go
- templates
- modelname
- all template related to this resource type
- scripts # where I put my scripts like backup etc
- lib # all utilities goes there
- subscribers # where all events are defined
My view package might sometimes be splitted up in many files where I'd group views by ResourceType.
If you happen to use context to match views instead of routes. You can do some pretty nice things with view_defaults and view_config.
view_defaults sets some default for the class, and view_config sets some more configurations for the defs using defaults provided by view_defaults if present.
It is sometimes beneficial to share certain constants between various code files in a django application.
Examples:
- Name or location of dump file used in various modules\commands etc
- Debug mode on\off for the entire app
- Site specific configuration
What would be the elegant\pythonic way of doing this?
There's already a project-wide settings.py file. This is the perfect place to put your own custom setttings.
you can provide settings in your settings.py like
MY_SETTING = 'value'
and in any module you can fetch it like
from django.conf import settings
settings.MY_SETTING
Create a configuration module.
Configuration.py: (in your project/app source directory)
MYCONST1 = 1
MYCONST2 = "rabbit"
Import it from other source files:
from Configuration import MYCONST1,MYCONST2
...
Django apps are meant to be (more or less) pluggable. Therefore, you are not supposed to hack into the code of an app in order to parametrize what you want (it would be quite a mess if you had to do this ! Imagine you want to upgrade an app you downloaded on internet... you would have to re-hack into the code of the new version ?!?).
For this reason you shouldn't add app-level settings at the app level, but rather put them together somewhere in your project-wide settings.py.