Despite googling I can't find any documentation for the Django HOST_DOMAIN setting in the settings.py.
I am going through a settings.py file I have been given and this is the only part of the file I am not 100% clear on.
You can find out what are all the django specific settings at the settings reference which lists all the settings variables (and their defaults) that are set by django.
Since settings.py is just any other Python module, you are free to define your own variables and import them in your code with:
from django.conf import settings
settings.MY_CUSTOM_SETTING
Third party applications can also define their own settings, which you can modify by entering the specific value in settings.py.
It sounds like HOST_DOMAIN is one such custom setting.
That is not a Django setting.
It's perfectly good practice to define your own project-specific settings inside settings.py, and that is presumably what the original developer did here.
In a.py ,I imported django's settings.py,I Need to Modify settings.DEBUG .
but how to do it in python script?
I did this but nothing changed , settings.DEBUG=False
https://docs.djangoproject.com/en/dev/topics/settings/#altering-settings-at-runtime I think this is you want.
Just like it saied:
from django.conf import settings
settings.DEBUG = True # Don't do this!
The only place you should assign to settings is in a settings file.
Good luck!
You might want to do a bit of research about different ways of doing 'local' settings for django.
There are lots of different ways. The way I do it is described in detail at Modular Django Settings.
I was wondering about whether it is better to import variables into your view from the settings.py file? or better to create a configuration file with the variables that are needed?
I tend to like to write configuration files for my Django applications, read, and import the variables from there when necessary. For example:
.configrc
[awesomeVariables]
someMagicNumber = 7
views.py
from ConfigParser import SafeConfigParser
#Open and parse the file
config = SafeConfigParser()
config.read(pathToConfig)
#Get variable
magicNumber = config.get('awesomeVariables', 'someMagicNumber'))
However, I've noticed some programmers prefer the following :
settings.py
SOME_MAGIC_NUMBER=7
views.py
import settings
magicNumber = settings.SOME_MAGIC_NUMBER
I was curious as to the pros and cons of the different methods? Can importing variables directly from your settings compromise the integrity of the architecture?
It's a judgement call. Using the settings module is the "Django way", although you should do from django.conf import settings; settings.MY_SETTING, which will respect DJANGO_SETTINGS_MODULE. But Django is just Python; there's nothing that will stop you from using ConfigParser. In the interest of having only one place where such things are defined, I'd recommend putting it in the Django settings file - but if you have a reason not to, don't.
Using a config file is completely un-Django. Settings go in settings.py. Period. For app-specific settings, you simply set a default in your app and allow the user to override in their project's settings.py:
from django.conf import settings
SOME_MAGIC_NUMBER = settings.SOME_MAGIC_NUMBER if hasattr(settings, 'SOME_MAGIC_NUMBER') else 0
# Where `0` is the default value
There also an app for storing settings dynamically in db. Maybe you find it usefull .
django-constance
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.
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.