Evernote Openbook: public

Django | Writing your first Django app

Sun, 07 Jun 2009 14:27:20 GMT

Writing your first Django app, part 1

Let’s learn by example.

Throughout this tutorial, we’ll walk you through the creation of a basic poll application.

It’ll consist of two parts:

A public site that lets people view polls and vote in them.
An admin site that lets you add, change and delete polls.

We’ll assume you have Django installed already. You can tell Django is installed by running the Python interactive interpreter and typing import django. If that command runs successfully, with no errors, Django is installed.

Where to get help:

If you’re having trouble going through this tutorial, please post a message to django-users or drop by #django on irc.freenode.net to chat with other Django users who might be able to help.

Creating a project

If this is your first time using Django, you’ll have to take care of some initial setup. Namely, you’ll need to auto-generate some code that establishes a Django project – a collection of settings for an instance of Django, including database configuration, Django-specific options and application-specific settings.

From the command line, cd into a directory where you’d like to store your code, then run the command django-admin.py startproject mysite. This will create a mysite directory in your current directory.

Mac OS X permissions

If you’re using Mac OS X, you may see the message “permission denied” when you try to run django-admin.py startproject. This is because, on Unix-based systems like OS X, a file must be marked as “executable” before it can be run as a program. To do this, open Terminal.app and navigate (using the cd command) to the directory where django-admin.py is installed, then run the command chmod +x django-admin.py.

Note

You’ll need to avoid naming projects after built-in Python or Django components. In particular, this means you should avoid using names like django (which will conflict with Django itself) or test (which conflicts with a built-in Python package).

django-admin.py should be on your system path if you installed Django via python setup.py. If it’s not on your p...

Using Django 1.0 on App Engine with Zipimport - Google App Engine - Google Code

Sun, 07 Jun 2009 02:31:53 GMT

Using Django 1.0 on App Engine with Zipimport Dan Sanderson
September 2008

Introduction

Using a Python web application framework with your App Engine application is usually as simple as including the files for the framework with your application's code. However, there is a limit to the number of files that can be uploaded for an application, and the standard distributions for some frameworks exceed this limit or leave little room for application code. You can work around the file limit using Python's "zipimport" feature, which is supported by App Engine as of the 1.1.3 release (September 2008).

This article describes how to use Django 1.0 with Google App Engine using the "zipimport" feature. You can use similar techniques with other frameworks, libraries or large applications.

Introducing zipimport

When your application imports a module, Python looks for the module's code in one of several directories. You can access and change the list of directories Python checks from Python code using sys.path. In App Engine, your handler is called with a path that includes the App Engine API and your application root directory.

If any of the items in sys.path refers to a ZIP-format archive, Python will treat the archive as a directory. The archive contains the .py source files for one or more modules. This feature is supported by a module in the standard library called zipimport, though this module is part of the default import process and you do not need to import this module directly to use it. For more information about zipimport, see the zipimport documentation.

To use module archives with your App Engine application:

Create a ZIP-format archive of the modules you want to bundle.
Put the archive in your application directory.
If necessary, in your handler scripts, add the archive file to sys.path.

For example, if you have a ZIP archive named django.zip with the following files in it:

django/forms/__init__.py django/forms/fields.py django/forms/forms.py django/forms/formsets.py django/forms/models.py ...

A handler script can i...

Using the Google App Engine Helper for Django - Google App Engine - Google Code

Sun, 07 Jun 2009 02:04:10 GMT

Using the Google App Engine Helper for Django Matt Brown
May 2009

Introduction

Google App Engine supports running any WSGI compliant application. Since Django supports this standard it is possible to build (or port existing) Django applications to run on Google App Engine.

This article will walk you through the process of starting a new Django project and getting it running on Google App Engine by reproducing the initial steps of creating the Polls application from the official Django tutorial. At each step the changes required for the App Engine environment are highlighted.

Before getting started you need to ensure that you have installed Python 2.5 and the Google App Engine SDK. The article also assumes you have previous experience with Django itself.

Understanding the Google App Engine and Django Environments

The environment provided by Google App Engine differs from what a Django application expects in two major ways.

Google App Engine does not provide an SQL database so you cannot use Django's standard Model class.
Google App Engine restricts certain module imports and actions that Django tries to perform (such as creating and removing the test database).

We have created a helper that prevents you from needing to worry about most of these differences. The helper works by providing alternative implementations for the portions of Django that do not work with Google App Engine.

Obtaining the Helper

The helper can be downloaded from the open source project at http://code.google.com/p/google-app-engine-django.

Download and extract the helper source archive into a directory called mysite

Within the directory you will see the standard Django project structure (settings.py, urls.py, etc) and a subdirectory (or application in Django terminology) named appengine_django. This is the helper that performs the work of integrating the Django and Google App Engine environments.

Accessing the Google App Engine SDK

The helper needs access to the Google App Engine SDK. If you are running on Mac OS and you used the installer provid...

MetaWeblog & Django

Fri, 05 Jun 2009 06:03:39 GMT

MetaWeblog & Django

Greg Abbas

Sun Jun 11th 2006 in Django, Web

As I mentioned previously, I wanted to integrate Ecto with my new Django-based blog using the "MetaWeblog" remote procedure call API. With an XMLRPC implementation ready to go, the remaining task is to write MetaWeblog methods and hook them up to my blog model. The model is pretty straightforward; for instance, here are the fields for "Post" object:

class Post(models.Model):
    title = models.CharField(maxlength=200)
    slug = models.SlugField(prepopulate_from=('title',))
    pub_date = models.DateTimeField('date published', blank=True, null=True)
    create_date = models.DateTimeField('date created', auto_now_add=True,
        blank=True, null=True)
    update_date = models.DateTimeField('date updated', auto_now=True,
        blank=True, null=True)
    body = models.TextField()
    tags = models.ManyToManyField(Tag)
    author = models.ForeignKey(User)
    status = models.CharField(maxlength=32, choices=STATUS_CHOICES,
        radio_admin=True, default='Draft')

The MetaWeblog API is pretty well documented, but has some features that I'm not quite ready to tackle. For instance, I only have a single user with a single blog, you have to be a "super user" to edit it (no sophisticated authorization scheme yet), and I haven't done media objects (e.g., images) yet either.

Most every method takes "username" and "password" parameters, so I wrote an "authenticated" wrapper function to convert them to a user object (and throw an exception if there are any authentication or authorization issues). Then the various methods are short, because the Django database/model API makes things easy. For instance, the method to get information about a blog post (given a post id) is called "getPost". My implementation looks up the post object by id, and then calls a function to turn it into the struct that MetaWeblog requires:

@public
@authenticated()
def metaWeblog_getPost(user, postid):
    post = Post.objects.get(id=postid)
    return post_struct(post)

def post_struct(post):
    link = fu...

XMLRPC in Django

Fri, 05 Jun 2009 06:03:12 GMT

XMLRPC in Django

Greg Abbas

Sat Jun 3rd 2006 in Django, Python

In setting up a blog server, one of my requirements was that I wanted to use a desktop client to write articles, instead of doing it in an HTML form in a web browser. I accomplished that by purchasing Ecto (which I'm using to type this article) and adding a MetaWeblog interface to the server. Here's the first of two articles on how I did it. Today's article talks about the XMLRPC layer, and the second in this series will conclude with the MetaWeblog implementation itself.

MetaWeblog is a network API for posting blog articles, and it's one of the ways that Ecto can talk to a Blog server. There are some other common blog APIs, including Typepad, Moveable Type, Blogger, and Atom, and I could have chosen any of them. As I mentioned in a previous post, I strongly considered Atom, because it seems to be the newest contender and claims to address some of MetaWeblog's shortcomings. And it's RESTful, which is elegant. But when I tested Ecto with the Atom API, it didn't seem to support images. I don't know whether that's Ecto's fault or Atom's fault, but it would be a problem for me in any case. So I decided to be pragmatic and go with MetaWeblog for now.

MetaWeblog is based on XMLRPC, which (like the name suggests) is a protocol for making remote procedure calls over HTTP. So the first order of business was to add XMLRPC support to Django. I'm not the first person to do that; Amit Upadhyay and Georg "hugo" Bauer have done some good work in this area, and have some excellent ideas about how it ought to fit into Django as you can see from their comments on Django ticket #115. Amit's implementation looked similar to what I had in mind, so I started with his code. Here's what I came up with: xmlrpc.py.

The basic idea of XMLRPC is that a client (like Ecto) makes a procedure call (like "publish new post") by POSTing an XML document over HTTP. The web server (running Django, in this case) parses the XML into a method name and an unmarshalled set of arguments. It then ...

The Atom Syndication Format

Fri, 05 Jun 2009 05:14:15 GMT

Network Working Group M. Nottingham, Editor Request for Comments: 4287 R. Sayre, Editor Category: Standards Track December 2005

The Atom Syndication Format

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

This document specifies Atom, an XML-based Web content and metadata syndication format.

Table of Contents

1. Introduction1.1 Examples1.2 Namespace and Version1.3 Notational Conventions
2. Atom Documents
3. Common Atom Constructs3.1 Text Constructs3.1.1 The "type" Attribute3.1.1.1 Text3.1.1.2 HTML3.1.1.3 XHTML3.2 Person Constructs3.2.1 The "atom:name" Element3.2.2 The "atom:uri" Element3.2.3 The "atom:email" Element3.3 Date Constructs
4. Atom Element Definitions4.1 Container Elements4.1.1 The "atom:feed" Element4.1.2 The "atom:entry" Element4.1.3 The "atom:content" Element4.1.3.1 The "type" Attribute4.1.3.2 The "src" Attribute4.1.3.3 Processing Model4.1.3.4 Examples4.2 Metadata Elements4.2.1 The "atom:author" Element4.2.2 The "atom:category" Element4.2.2.1 The "term" Attribute4.2.2.2 The "scheme" Attribute4.2.2.3 The "label" Attribute4.2.3 The "atom:contributor" Element4.2.4 The "atom:generator" Element4.2.5 The "atom:icon" Element4.2.6 The "atom:id" Element4.2.6.1 Comparing atom:id4.2.7 The "atom:link" Element4.2.7.1 The "href" Attribute4.2.7.2 The "rel" Attribute4.2.7.3 The "type" Attribute4.2.7.4 The "hreflang" Attribute4.2.7.5 The "title" Attribute4.2.7.6 The "length" Attribute4.2.8 The "atom:logo" Element4.2.9 The "atom:published" Element4.2.10 The "atom:rights" Element4.2.11 The "atom:source" Element4.2.12 The "atom:subtitle" ...

The Atom Publishing Protocol

Fri, 05 Jun 2009 05:11:21 GMT

Network Working Group J.C. Gregorio, Editor Request for Comments: 5023 Google Category: Standards Track B. de hOra, Editor NewBay Software October 2007

The Atom Publishing Protocol

Status of this Memo

Abstract

The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format.

Table of Contents

1. Introduction
2. Notational Conventions2.1 XML-Related Conventions2.1.1 Referring to Information Items2.1.2 RELAX NG Schema2.1.3 Use of "xml:base" and "xml:lang"
3. Terminology
4. Protocol Model4.1 Identity and Naming4.2 Documents and Resource Classification4.3 Control and Publishing4.4 Client Implementation Considerations
5. Protocol Operations5.1 Retrieving a Service Document5.2 Listing Collection Members5.3 Creating a Resource5.4 Editing a Resource5.4.1 Retrieving a Resource5.4.2 Editing a Resource5.4.3 Deleting a Resource5.5 Use of HTTP Response Codes
6. Protocol Documents6.1 Document Types6.2 Document Extensibility
7. Category Documents7.1 Example7.2 Element Definitions7.2.1 The "app:categories" Element7.2.1.1 Attributes of "app:categories"
8. Service Documents8.1 Workspaces8.2 Example8.3 Element Definitions8.3.1 The "app:service" Element8.3.2 The "app:workspace" Element8.3.2.1 The "atom:title" Element8.3.3 The "app:collection" Element8.3.3.1 The "href" Attribute8.3.3.2 The "atom:title" Element8.3.4 The "app:accept" Element8.3.5 Usage in Atom Feed Documents8.3.6

MetaWeblog API: MetaWeblog API Specification

Fri, 05 Jun 2009 05:05:57 GMT

MetaWeblog API Specification

Introduction

The MetaWeblog API is an application programming interface that enables software to read and write weblog posts stored on a web server. The API has been implemented as an XML-RPC web service, so there are implementations supporting the API available in many popular programming languages.

The MetaWeblog API is designed to extend the Blogger API, a blogging API that only can read and write the text of weblog posts. An additional API was needed to read and write elements such as a blog post's title, file enclosures, and categories.

Most software that supports the Blogger API also supports the MetaWeblog API, and vice versa.

Data Types

The API employs the data types defined in XML-RPC, including the scalar types base64, boolean, int and string and the composite types array and struct.

Error Handling

Applications that implement the API should use the fault-response scheme defined by XML-RPC. For example, trying to read, write, or edit a post without providing a valid username and password should generate a fault. Applications should display the error string to the user in a dialog box or server log, as appropriate.

Use of RSS 2.0

The API uses a struct to represent a blog post. Within the struct, the components of the post are represented by the elements of an item in the RSS syndication format, adopting the same name and usage as their RSS counterparts. Items in RSS can be extended by elements from namespaces, so the same is permitted in the MetaWeblog API.

There's one exception: Categories are represented by a member named categories in the MetaWeblog API, unlike the RSS element which is named category.

Common Parameters

Several of the API's methods employ the same parameters: blogId, password, postId, publish, and username.

The blogId, password, publish and username parameters are the same as the ones in the Blogger API. The blogId parameter is a string that contains a unique identifier for a blog. The username and password parameters are strings that contain authentication crede...