parts/django/docs/faq/usage.txt
changeset 69 c6bca38c1cbf
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/parts/django/docs/faq/usage.txt	Sat Jan 08 11:20:57 2011 +0530
@@ -0,0 +1,77 @@
+FAQ: Using Django
+=================
+
+Why do I get an error about importing DJANGO_SETTINGS_MODULE?
+-------------------------------------------------------------
+
+Make sure that:
+
+    * The environment variable DJANGO_SETTINGS_MODULE is set to a
+      fully-qualified Python module (i.e. "mysite.settings").
+
+    * Said module is on ``sys.path`` (``import mysite.settings`` should work).
+
+    * The module doesn't contain syntax errors (of course).
+
+    * If you're using mod_python but *not* using Django's request handler,
+      you'll need to work around a mod_python bug related to the use of
+      ``SetEnv``; before you import anything from Django you'll need to do
+      the following::
+
+            os.environ.update(req.subprocess_env)
+
+      (where ``req`` is the mod_python request object).
+
+I can't stand your template language. Do I have to use it?
+----------------------------------------------------------
+
+We happen to think our template engine is the best thing since chunky bacon,
+but we recognize that choosing a template language runs close to religion.
+There's nothing about Django that requires using the template language, so
+if you're attached to ZPT, Cheetah, or whatever, feel free to use those.
+
+Do I have to use your model/database layer?
+-------------------------------------------
+
+Nope. Just like the template system, the model/database layer is decoupled from
+the rest of the framework.
+
+The one exception is: If you use a different database library, you won't get to
+use Django's automatically-generated admin site. That app is coupled to the
+Django database layer.
+
+How do I use image and file fields?
+-----------------------------------
+
+Using a :class:`~django.db.models.FileField` or an
+:class:`~django.db.models.ImageField` in a model takes a few steps:
+
+    #. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as
+       the full path to a directory where you'd like Django to store uploaded
+       files. (For performance, these files are not stored in the database.)
+       Define :setting:`MEDIA_URL` as the base public URL of that directory.
+       Make sure that this directory is writable by the Web server's user
+       account.
+
+    #. Add the :class:`~django.db.models.FileField` or
+       :class:`~django.db.models.ImageField` to your model, making sure to
+       define the :attr:`~django.db.models.FileField.upload_to` option to tell
+       Django to which subdirectory of :setting:`MEDIA_ROOT` it should upload
+       files.
+
+    #. All that will be stored in your database is a path to the file
+       (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
+       convenience :attr:`~django.core.files.File.url` attribute provided by
+       Django. For example, if your :class:`~django.db.models.ImageField` is
+       called ``mug_shot``, you can get the absolute path to your image in a
+       template with ``{{ object.mug_shot.url }}``.
+
+How do I make a variable available to all my templates?
+-------------------------------------------------------
+
+Sometimes your templates just all need the same thing. A common example would
+be dynamically-generated menus. At first glance, it seems logical to simply
+add a common dictionary to the template context.
+
+The correct solution is to use a ``RequestContext``. Details on how to do this
+are here: :ref:`subclassing-context-requestcontext`.