|
1 FAQ: Using Django |
|
2 ================= |
|
3 |
|
4 Why do I get an error about importing DJANGO_SETTINGS_MODULE? |
|
5 ------------------------------------------------------------- |
|
6 |
|
7 Make sure that: |
|
8 |
|
9 * The environment variable DJANGO_SETTINGS_MODULE is set to a |
|
10 fully-qualified Python module (i.e. "mysite.settings"). |
|
11 |
|
12 * Said module is on ``sys.path`` (``import mysite.settings`` should work). |
|
13 |
|
14 * The module doesn't contain syntax errors (of course). |
|
15 |
|
16 * If you're using mod_python but *not* using Django's request handler, |
|
17 you'll need to work around a mod_python bug related to the use of |
|
18 ``SetEnv``; before you import anything from Django you'll need to do |
|
19 the following:: |
|
20 |
|
21 os.environ.update(req.subprocess_env) |
|
22 |
|
23 (where ``req`` is the mod_python request object). |
|
24 |
|
25 I can't stand your template language. Do I have to use it? |
|
26 ---------------------------------------------------------- |
|
27 |
|
28 We happen to think our template engine is the best thing since chunky bacon, |
|
29 but we recognize that choosing a template language runs close to religion. |
|
30 There's nothing about Django that requires using the template language, so |
|
31 if you're attached to ZPT, Cheetah, or whatever, feel free to use those. |
|
32 |
|
33 Do I have to use your model/database layer? |
|
34 ------------------------------------------- |
|
35 |
|
36 Nope. Just like the template system, the model/database layer is decoupled from |
|
37 the rest of the framework. |
|
38 |
|
39 The one exception is: If you use a different database library, you won't get to |
|
40 use Django's automatically-generated admin site. That app is coupled to the |
|
41 Django database layer. |
|
42 |
|
43 How do I use image and file fields? |
|
44 ----------------------------------- |
|
45 |
|
46 Using a :class:`~django.db.models.FileField` or an |
|
47 :class:`~django.db.models.ImageField` in a model takes a few steps: |
|
48 |
|
49 #. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as |
|
50 the full path to a directory where you'd like Django to store uploaded |
|
51 files. (For performance, these files are not stored in the database.) |
|
52 Define :setting:`MEDIA_URL` as the base public URL of that directory. |
|
53 Make sure that this directory is writable by the Web server's user |
|
54 account. |
|
55 |
|
56 #. Add the :class:`~django.db.models.FileField` or |
|
57 :class:`~django.db.models.ImageField` to your model, making sure to |
|
58 define the :attr:`~django.db.models.FileField.upload_to` option to tell |
|
59 Django to which subdirectory of :setting:`MEDIA_ROOT` it should upload |
|
60 files. |
|
61 |
|
62 #. All that will be stored in your database is a path to the file |
|
63 (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the |
|
64 convenience :attr:`~django.core.files.File.url` attribute provided by |
|
65 Django. For example, if your :class:`~django.db.models.ImageField` is |
|
66 called ``mug_shot``, you can get the absolute path to your image in a |
|
67 template with ``{{ object.mug_shot.url }}``. |
|
68 |
|
69 How do I make a variable available to all my templates? |
|
70 ------------------------------------------------------- |
|
71 |
|
72 Sometimes your templates just all need the same thing. A common example would |
|
73 be dynamically-generated menus. At first glance, it seems logical to simply |
|
74 add a common dictionary to the template context. |
|
75 |
|
76 The correct solution is to use a ``RequestContext``. Details on how to do this |
|
77 are here: :ref:`subclassing-context-requestcontext`. |