render_to_response()

render_to_response()

Because it’s such a common idiom to load a template, fill a Context and return an HttpResponse object with the result of the
rendered template, Django provides a shortcut that lets you do those things in one line of code. This shortcut is a function
called render_to_response(), which lives in the module django.shortcuts. Most of the time, you’ll be using render_to_response() rather than loading templates and creating Context and HttpResponse objects manually.

Here’s the ongoing current_datetime example rewritten to use render_to_response():

from django.shortcuts import render_to_response
import datetime
def current_datetime(request):
now = datetime.datetime.now()
return render_to_response('current_datetime.html', {'current_date': now})

What a difference! Let’s step through the code changes:
l We no longer have to import get_template, Template, Context or HttpResponse. Instead, we
import django.shortcuts.render_to_response. The import datetime remains.
l Within the current_datetime function, we still calculate now, but the template loading, context creation, template rendering
and HttpResponse creation is all taken care of by the render_to_response() call. Because render_to_response() returns
an HttpResponse object, we can simply return that value in the view.
The first argument to render_to_response() should be the name of the template to use, relative to your template directory. The
second argument, if given, should be a dictionary to use in creating a Context for that template. If you don’t provide a second
argument, render_to_response() will use an empty dictionary

Django Stuff - 1

Projects vs. apps

What’s the difference between a project and an app? An app is a Web application that does something — e.g., a weblog system, a database of public records or a simple poll app. A project is a collection of configuration and apps for a particular Web site. A project can contain multiple apps. An app can be in multiple projects.

Each model is a Python class that subclasses django.db.models.Model.
Each attribute of the model represents a database field.
Model metadata (non-field information) goes in an inner class named Meta.
Metadata used for Django’s admin site goes into an inner class named Admin

Executing Custon SQL
def my_custom_sql(self):
from django.db import connection
cursor = connection.cursor()
cursor.execute("SELECT foo FROM bar WHERE baz = %s", [self.baz])
row = cursor.fetchone()
return row


How Django processes a request

When a user requests a page from your Django-powered site, this is the algorithm the system follows to determine which Python code to execute:
Django looks at the ROOT_URLCONF setting in your settings file. This should be a string representing the full Python import path to your URLconf. For example: "mydjangoapps.urls".
Django loads that Python module and looks for the variable urlpatterns. This should be a Python list, in the format returned by the function django.conf.urls.defaults.patterns().
Django runs through each URL pattern, in order, and stops at the first one that matches the requested URL.
Once one of the regexes matches, Django imports and calls the given view, which is a simple Python function. The view gets passed a request object as its first argument and any values captured in the regex as remaining arguments.