mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
Massive reorganization of the docs. See the new docs online at http://docs.djangoproject.com/.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8506 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
103
docs/faq/admin.txt
Normal file
103
docs/faq/admin.txt
Normal file
@@ -0,0 +1,103 @@
|
||||
.. _faq-admin:
|
||||
|
||||
FAQ: The admin
|
||||
==============
|
||||
|
||||
I can't log in. When I enter a valid username and password, it just brings up the login page again, with no error messages.
|
||||
---------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
The login cookie isn't being set correctly, because the domain of the cookie
|
||||
sent out by Django doesn't match the domain in your browser. Try these two
|
||||
things:
|
||||
|
||||
* Set the ``SESSION_COOKIE_DOMAIN`` setting in your admin config file
|
||||
to match your domain. For example, if you're going to
|
||||
"http://www.example.com/admin/" in your browser, in
|
||||
"myproject.settings" you should set ``SESSION_COOKIE_DOMAIN = 'www.example.com'``.
|
||||
|
||||
* Some browsers (Firefox?) don't like to accept cookies from domains that
|
||||
don't have dots in them. If you're running the admin site on "localhost"
|
||||
or another domain that doesn't have a dot in it, try going to
|
||||
"localhost.localdomain" or "127.0.0.1". And set
|
||||
``SESSION_COOKIE_DOMAIN`` accordingly.
|
||||
|
||||
I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error.
|
||||
-----------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
If you're sure your username and password are correct, make sure your user
|
||||
account has ``is_active`` and ``is_staff`` set to True. The admin site only
|
||||
allows access to users with those two fields both set to True.
|
||||
|
||||
How can I prevent the cache middleware from caching the admin site?
|
||||
-------------------------------------------------------------------
|
||||
|
||||
Set the :setting:``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting to ``True``. See the
|
||||
:ref:`cache documentation <topics-cache>` for more information.
|
||||
|
||||
How do I automatically set a field's value to the user who last edited the object in the admin?
|
||||
-----------------------------------------------------------------------------------------------
|
||||
|
||||
At this point, Django doesn't have an official way to do this. But it's an oft-requested
|
||||
feature, so we're discussing how it can be implemented. The problem is we don't want to couple
|
||||
the model layer with the admin layer with the request layer (to get the current user). It's a
|
||||
tricky problem.
|
||||
|
||||
One person hacked up a `solution that doesn't require patching Django`_, but note that it's an
|
||||
unofficial solution, and there's no guarantee it won't break at some point.
|
||||
|
||||
.. _solution that doesn't require patching Django: http://lukeplant.me.uk/blog.php?id=1107301634
|
||||
|
||||
How do I limit admin access so that objects can only be edited by the users who created them?
|
||||
---------------------------------------------------------------------------------------------
|
||||
|
||||
See the answer to the previous question.
|
||||
|
||||
My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_python.
|
||||
---------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
See :ref:`serving the admin files <howto-deployment-modpython-serving-the-admin-files`
|
||||
in the "How to use Django with mod_python" documentation.
|
||||
|
||||
My "list_filter" contains a ManyToManyField, but the filter doesn't display.
|
||||
----------------------------------------------------------------------------
|
||||
|
||||
Django won't bother displaying the filter for a ``ManyToManyField`` if there
|
||||
are fewer than two related objects.
|
||||
|
||||
For example, if your ``list_filter`` includes ``sites``, and there's only one
|
||||
site in your database, it won't display a "Site" filter. In that case,
|
||||
filtering by site would be meaningless.
|
||||
|
||||
How can I customize the functionality of the admin interface?
|
||||
-------------------------------------------------------------
|
||||
|
||||
You've got several options. If you want to piggyback on top of an add/change
|
||||
form that Django automatically generates, you can attach arbitrary JavaScript
|
||||
modules to the page via the model's ``class Admin`` ``js`` parameter. That
|
||||
parameter is a list of URLs, as strings, pointing to JavaScript modules that
|
||||
will be included within the admin form via a ``<script>`` tag.
|
||||
|
||||
If you want more flexibility than simply tweaking the auto-generated forms,
|
||||
feel free to write custom views for the admin. The admin is powered by Django
|
||||
itself, and you can write custom views that hook into the authentication
|
||||
system, check permissions and do whatever else they need to do.
|
||||
|
||||
If you want to customize the look-and-feel of the admin interface, read the
|
||||
next question.
|
||||
|
||||
The dynamically-generated admin site is ugly! How can I change it?
|
||||
------------------------------------------------------------------
|
||||
|
||||
We like it, but if you don't agree, you can modify the admin site's
|
||||
presentation by editing the CSS stylesheet and/or associated image files. The
|
||||
site is built using semantic HTML and plenty of CSS hooks, so any changes you'd
|
||||
like to make should be possible by editing the stylesheet. We've got a
|
||||
:ref:`guide to the CSS used in the admin <obsolete-admin-css>` to get you started.
|
||||
|
||||
How do I create users without having to edit password hashes?
|
||||
-------------------------------------------------------------
|
||||
|
||||
If you'd like to use the admin site to create users, upgrade to the Django
|
||||
development version, where this problem was fixed on Aug. 4, 2006.
|
||||
|
||||
You can also use the Python API. See :ref:`creating users <topics-auth-creating-users>` for full info.
|
||||
30
docs/faq/contributing.txt
Normal file
30
docs/faq/contributing.txt
Normal file
@@ -0,0 +1,30 @@
|
||||
.. _faq-contributing:
|
||||
|
||||
FAQ: Contributing code
|
||||
======================
|
||||
|
||||
How can I get started contributing code to Django?
|
||||
--------------------------------------------------
|
||||
|
||||
Thanks for asking! We've written an entire document devoted to this question.
|
||||
It's titled :ref:`Contributing to Django <internals-contributing>`.
|
||||
|
||||
I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
|
||||
--------------------------------------------------------------------------------------------
|
||||
|
||||
Don't worry: We're not ignoring you!
|
||||
|
||||
It's important to understand there is a difference between "a ticket is being
|
||||
ignored" and "a ticket has not been attended to yet." Django's ticket system
|
||||
contains hundreds of open tickets, of various degrees of impact on end-user
|
||||
functionality, and Django's developers have to review and prioritize.
|
||||
|
||||
On top of that: the people who work on Django are all volunteers. As a result,
|
||||
the amount of time that we have to work on the framework is limited and will
|
||||
vary from week to week depending on our spare time. If we're busy, we may not
|
||||
be able to spend as much time on Django as we might want.
|
||||
|
||||
Besides, if your feature request stands no chance of inclusion in Django, we
|
||||
won't ignore it -- we'll just close the ticket. So if your ticket is still
|
||||
open, it doesn't mean we're ignoring you; it just means we haven't had time to
|
||||
look at it yet.
|
||||
256
docs/faq/general.txt
Normal file
256
docs/faq/general.txt
Normal file
@@ -0,0 +1,256 @@
|
||||
.. _faq-general:
|
||||
|
||||
FAQ: General
|
||||
============
|
||||
|
||||
Why does this project exist?
|
||||
----------------------------
|
||||
|
||||
Django grew from a very practical need: World Online, a newspaper Web
|
||||
operation, is responsible for building intensive Web applications on journalism
|
||||
deadlines. In the fast-paced newsroom, World Online often has only a matter of
|
||||
hours to take a complicated Web application from concept to public launch.
|
||||
|
||||
At the same time, the World Online Web developers have consistently been
|
||||
perfectionists when it comes to following best practices of Web development.
|
||||
|
||||
In fall 2003, the World Online developers (Adrian Holovaty and Simon Willison)
|
||||
ditched PHP and began using Python to develop its Web sites. As they built
|
||||
intensive, richly interactive sites such as Lawrence.com, they began to extract
|
||||
a generic Web development framework that let them build Web applications more
|
||||
and more quickly. They tweaked this framework constantly, adding improvements
|
||||
over two years.
|
||||
|
||||
In summer 2005, World Online decided to open-source the resulting software,
|
||||
Django. Django would not be possible without a whole host of open-source
|
||||
projects -- `Apache`_, `Python`_, and `PostgreSQL`_ to name a few -- and we're
|
||||
thrilled to be able to give something back to the open-source community.
|
||||
|
||||
.. _Apache: http://httpd.apache.org/
|
||||
.. _Python: http://www.python.org/
|
||||
.. _PostgreSQL: http://www.postgresql.org/
|
||||
|
||||
What does "Django" mean, and how do you pronounce it?
|
||||
-----------------------------------------------------
|
||||
|
||||
Django is named after `Django Reinhardt`_, a gypsy jazz guitarist from the 1930s
|
||||
to early 1950s. To this day, he's considered one of the best guitarists of all time.
|
||||
|
||||
Listen to his music. You'll like it.
|
||||
|
||||
Django is pronounced **JANG**-oh. Rhymes with FANG-oh. The "D" is silent.
|
||||
|
||||
We've also recorded an `audio clip of the pronunciation`_.
|
||||
|
||||
.. _Django Reinhardt: http://en.wikipedia.org/wiki/Django_Reinhardt
|
||||
.. _audio clip of the pronunciation: http://red-bean.com/~adrian/django_pronunciation.mp3
|
||||
|
||||
Is Django stable?
|
||||
-----------------
|
||||
|
||||
Yes. World Online has been using Django for more than three years. Sites built
|
||||
on Django have weathered traffic spikes of over one million hits an hour and a
|
||||
number of Slashdottings. Yes, it's quite stable.
|
||||
|
||||
Does Django scale?
|
||||
------------------
|
||||
|
||||
Yes. Compared to development time, hardware is cheap, and so Django is
|
||||
designed to take advantage of as much hardware as you can throw at it.
|
||||
|
||||
Django uses a "shared-nothing" architecture, which means you can add hardware
|
||||
at any level -- database servers, caching servers or Web/application servers.
|
||||
|
||||
The framework cleanly separates components such as its database layer and
|
||||
application layer. And it ships with a simple-yet-powerful
|
||||
:ref:`cache framework <topics-cache>`.
|
||||
|
||||
Who's behind this?
|
||||
------------------
|
||||
|
||||
Django was developed at `World Online`_, the Web department of a newspaper in
|
||||
Lawrence, Kansas, USA.
|
||||
|
||||
`Adrian Holovaty`_
|
||||
Adrian is a Web developer with a background in journalism. He was lead
|
||||
developer at World Online for 2.5 years, during which time Django was
|
||||
developed and implemented on World Online's sites. Now he works for
|
||||
washingtonpost.com building rich, database-backed information sites, and
|
||||
continues to oversee Django development. He likes playing guitar (Django
|
||||
Reinhardt style) and hacking on side projects such as `chicagocrime.org`_.
|
||||
He lives in Chicago.
|
||||
|
||||
On IRC, Adrian goes by ``adrian_h``.
|
||||
|
||||
`Jacob Kaplan-Moss`_
|
||||
Jacob is a whipper-snapper from California who spends equal time coding and
|
||||
cooking. He's lead developer at World Online and actively hacks on various
|
||||
cool side projects. He's contributed to the Python-ObjC bindings and was
|
||||
the first guy to figure out how to write Tivo apps in Python. Lately he's
|
||||
been messing with Python on the PSP. He lives in Lawrence, Kansas.
|
||||
|
||||
On IRC, Jacob goes by ``jacobkm``.
|
||||
|
||||
`Simon Willison`_
|
||||
Simon is a well-respected Web developer from England. He had a one-year
|
||||
internship at World Online, during which time he and Adrian developed
|
||||
Django from scratch. The most enthusiastic Brit you'll ever meet, he's
|
||||
passionate about best practices in Web development and has maintained a
|
||||
well-read Web-development blog for years at http://simon.incutio.com.
|
||||
He works for Yahoo UK, where he managed to score the title "Hacker Liason."
|
||||
He lives in London.
|
||||
|
||||
On IRC, Simon goes by ``SimonW``.
|
||||
|
||||
`Wilson Miner`_
|
||||
Wilson's design-fu makes us all look like rock stars. By day, he's an
|
||||
interactive designer for `Apple`_. Don't ask him what he's working on, or
|
||||
he'll have to kill you. He lives in San Francisco.
|
||||
|
||||
On IRC, Wilson goes by ``wilsonian``.
|
||||
|
||||
.. _`World Online`: http://code.djangoproject.com/wiki/WorldOnline
|
||||
.. _`Adrian Holovaty`: http://www.holovaty.com/
|
||||
.. _`washingtonpost.com`: http://www.washingtonpost.com/
|
||||
.. _`chicagocrime.org`: http://www.chicagocrime.org/
|
||||
.. _`Simon Willison`: http://simon.incutio.com/
|
||||
.. _`simon.incutio.com`: http://simon.incutio.com/
|
||||
.. _`Jacob Kaplan-Moss`: http://www.jacobian.org/
|
||||
.. _`Wilson Miner`: http://www.wilsonminer.com/
|
||||
.. _`Apple`: http://www.apple.com/
|
||||
|
||||
Which sites use Django?
|
||||
-----------------------
|
||||
|
||||
The Django wiki features a consistently growing `list of Django-powered sites`_.
|
||||
Feel free to add your Django-powered site to the list.
|
||||
|
||||
.. _list of Django-powered sites: http://code.djangoproject.com/wiki/DjangoPoweredSites
|
||||
|
||||
.. _mtv:
|
||||
|
||||
Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
|
||||
-----------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
Well, the standard names are debatable.
|
||||
|
||||
In our interpretation of MVC, the "view" describes the data that gets presented
|
||||
to the user. It's not necessarily *how* the data *looks*, but *which* data is
|
||||
presented. The view describes *which data you see*, not *how you see it.* It's
|
||||
a subtle distinction.
|
||||
|
||||
So, in our case, a "view" is the Python callback function for a particular URL,
|
||||
because that callback function describes which data is presented.
|
||||
|
||||
Furthermore, it's sensible to separate content from presentation -- which is
|
||||
where templates come in. In Django, a "view" describes which data is presented,
|
||||
but a view normally delegates to a template, which describes *how* the data is
|
||||
presented.
|
||||
|
||||
Where does the "controller" fit in, then? In Django's case, it's probably the
|
||||
framework itself: the machinery that sends a request to the appropriate view,
|
||||
according to the Django URL configuration.
|
||||
|
||||
If you're hungry for acronyms, you might say that Django is a "MTV" framework
|
||||
-- that is, "model", "template", and "view." That breakdown makes much more
|
||||
sense.
|
||||
|
||||
At the end of the day, of course, it comes down to getting stuff done. And,
|
||||
regardless of how things are named, Django gets stuff done in a way that's most
|
||||
logical to us.
|
||||
|
||||
<Framework X> does <feature Y> -- why doesn't Django?
|
||||
-----------------------------------------------------
|
||||
|
||||
We're well aware that there are other awesome Web frameworks out there, and
|
||||
we're not averse to borrowing ideas where appropriate. However, Django was
|
||||
developed precisely because we were unhappy with the status quo, so please be
|
||||
aware that "because <Framework X> does it" is not going to be sufficient reason
|
||||
to add a given feature to Django.
|
||||
|
||||
Why did you write all of Django from scratch, instead of using other Python libraries?
|
||||
--------------------------------------------------------------------------------------
|
||||
|
||||
When Django was originally written a couple of years ago, Adrian and Simon
|
||||
spent quite a bit of time exploring the various Python Web frameworks
|
||||
available.
|
||||
|
||||
In our opinion, none of them were completely up to snuff.
|
||||
|
||||
We're picky. You might even call us perfectionists. (With deadlines.)
|
||||
|
||||
Over time, we stumbled across open-source libraries that did things we'd
|
||||
already implemented. It was reassuring to see other people solving similar
|
||||
problems in similar ways, but it was too late to integrate outside code: We'd
|
||||
already written, tested and implemented our own framework bits in several
|
||||
production settings -- and our own code met our needs delightfully.
|
||||
|
||||
In most cases, however, we found that existing frameworks/tools inevitably had
|
||||
some sort of fundamental, fatal flaw that made us squeamish. No tool fit our
|
||||
philosophies 100%.
|
||||
|
||||
Like we said: We're picky.
|
||||
|
||||
We've documented our philosophies on the
|
||||
:ref:`design philosophies page <misc-design-philosophies>`.
|
||||
|
||||
Do you have any of those nifty "screencast" things?
|
||||
---------------------------------------------------
|
||||
|
||||
You can bet your bottom they're on the way. But, since we're still hammering
|
||||
out a few points, we want to make sure they reflect the final state of things
|
||||
at Django 1.0, not some intermediary step. In other words, we don't want to
|
||||
spend a lot of energy creating screencasts yet, because Django APIs will shift.
|
||||
|
||||
Is Django a content-management-system (CMS)?
|
||||
--------------------------------------------
|
||||
|
||||
No, Django is not a CMS, or any sort of "turnkey product" in and of itself.
|
||||
It's a Web framework; it's a programming tool that lets you build Web sites.
|
||||
|
||||
For example, it doesn't make much sense to compare Django to something like
|
||||
Drupal_, because Django is something you use to *create* things like Drupal.
|
||||
|
||||
Of course, Django's automatic admin site is fantastic and timesaving -- but
|
||||
the admin site is one module of Django the framework. Furthermore, although
|
||||
Django has special conveniences for building "CMS-y" apps, that doesn't mean
|
||||
it's not just as appropriate for building "non-CMS-y" apps (whatever that
|
||||
means!).
|
||||
|
||||
.. _Drupal: http://drupal.org/
|
||||
|
||||
When will you release Django 1.0?
|
||||
---------------------------------
|
||||
|
||||
See our `version one roadmap`_ for the detailed timeline. We're aiming for
|
||||
September 2, 2008.
|
||||
|
||||
.. _version one roadmap: http://code.djangoproject.com/wiki/VersionOneRoadmap
|
||||
|
||||
How can I download the Django documentation to read it offline?
|
||||
---------------------------------------------------------------
|
||||
|
||||
The Django docs are available in the ``docs`` directory of each Django tarball
|
||||
release. These docs are in ReST (ReStructured Text) format, and each text file
|
||||
corresponds to a Web page on the official Django site.
|
||||
|
||||
Because the documentation is `stored in revision control`_, you can browse
|
||||
documentation changes just like you can browse code changes.
|
||||
|
||||
Technically, the docs on Django's site are generated from the latest development
|
||||
versions of those ReST documents, so the docs on the Django site may offer more
|
||||
information than the docs that come with the latest Django release.
|
||||
|
||||
.. _stored in revision control: http://code.djangoproject.com/browser/django/trunk/docs
|
||||
|
||||
Where can I find Django developers for hire?
|
||||
--------------------------------------------
|
||||
|
||||
Consult our `developers for hire page`_ for a list of Django developers who
|
||||
would be happy to help you.
|
||||
|
||||
You might also be interested in posting a job to http://djangogigs.com/ .
|
||||
If you want to find Django-capable people in your local area, try
|
||||
http://djangopeople.net/ .
|
||||
|
||||
.. _developers for hire page: http://code.djangoproject.com/wiki/DevelopersForHire
|
||||
75
docs/faq/help.txt
Normal file
75
docs/faq/help.txt
Normal file
@@ -0,0 +1,75 @@
|
||||
.. _faq-help:
|
||||
|
||||
FAQ: Getting Help
|
||||
=================
|
||||
|
||||
How do I do X? Why doesn't Y work? Where can I go to get help?
|
||||
--------------------------------------------------------------
|
||||
|
||||
If this FAQ doesn't contain an answer to your question, you might want to
|
||||
try the `django-users mailing list`_. Feel free to ask any question related
|
||||
to installing, using, or debugging Django.
|
||||
|
||||
If you prefer IRC, the `#django IRC channel`_ on the Freenode IRC network is an
|
||||
active community of helpful individuals who may be able to solve your problem.
|
||||
|
||||
.. _`django-users mailing list`: http://groups.google.com/group/django-users
|
||||
.. _`#django IRC channel`: irc://irc.freenode.net/django
|
||||
|
||||
Why hasn't my message appeared on django-users?
|
||||
-----------------------------------------------
|
||||
|
||||
django-users_ has a lot of subscribers. This is good for the community, as
|
||||
it means many people are available to contribute answers to questions.
|
||||
Unfortunately, it also means that django-users_ is an attractive target for
|
||||
spammers.
|
||||
|
||||
In order to combat the spam problem, when you join the django-users_ mailing
|
||||
list, we manually moderate the first message you send to the list. This means
|
||||
that spammers get caught, but it also means that your first question to the
|
||||
list might take a little longer to get answered. We apologize for any
|
||||
inconvenience that this policy may cause.
|
||||
|
||||
.. _django-users: http://groups.google.com/group/django-users
|
||||
|
||||
Nobody on django-users answered my question! What should I do?
|
||||
--------------------------------------------------------------
|
||||
|
||||
Try making your question more specific, or provide a better example of your
|
||||
problem.
|
||||
|
||||
As with most open-source mailing lists, the folks on django-users_ are
|
||||
volunteers. If nobody has answered your question, it may be because nobody
|
||||
knows the answer, it may be because nobody can understand the question, or it
|
||||
may be that everybody that can help is busy. One thing you might try is to ask
|
||||
the question on IRC -- visit the `#django IRC channel`_ on the Freenode IRC
|
||||
network.
|
||||
|
||||
You might notice we have a second mailing list, called django-developers_ --
|
||||
but please don't e-mail support questions to this mailing list. This list is
|
||||
for discussion of the development of Django itself. Asking a tech support
|
||||
question there is considered quite impolite.
|
||||
|
||||
.. _django-developers: http://groups.google.com/group/django-developers
|
||||
|
||||
I think I've found a bug! What should I do?
|
||||
-------------------------------------------
|
||||
|
||||
Detailed instructions on how to handle a potential bug can be found in our
|
||||
:ref:`Guide to contributing to Django <reporting-bugs>`.
|
||||
|
||||
I think I've found a security problem! What should I do?
|
||||
--------------------------------------------------------
|
||||
|
||||
If you think you've found a security problem with Django, please send a message
|
||||
to security@djangoproject.com. This is a private list only open to long-time,
|
||||
highly trusted Django developers, and its archives are not publicly readable.
|
||||
|
||||
Due to the sensitive nature of security issues, we ask that if you think you
|
||||
have found a security problem, *please* don't send a message to one of the
|
||||
public mailing lists. Django has a
|
||||
:ref:`policy for handling security issues <reporting-security-issues>`;
|
||||
while a defect is outstanding, we would like to minimize any damage that
|
||||
could be inflicted through public knowledge of that defect.
|
||||
|
||||
.. _`policy for handling security issues`: ../contributing/#reporting-security-issues
|
||||
16
docs/faq/index.txt
Normal file
16
docs/faq/index.txt
Normal file
@@ -0,0 +1,16 @@
|
||||
.. _faq-index:
|
||||
|
||||
==========
|
||||
Django FAQ
|
||||
==========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
general
|
||||
install
|
||||
usage
|
||||
help
|
||||
models
|
||||
admin
|
||||
contributing
|
||||
108
docs/faq/install.txt
Normal file
108
docs/faq/install.txt
Normal file
@@ -0,0 +1,108 @@
|
||||
.. _faq-install:
|
||||
|
||||
FAQ: Installation
|
||||
=================
|
||||
|
||||
How do I get started?
|
||||
---------------------
|
||||
|
||||
#. `Download the code`_.
|
||||
#. Install Django (read the :ref:`installation guide <intro-install>`).
|
||||
#. Walk through the :ref:`tutorial <intro-tutorial01>`.
|
||||
#. Check out the rest of the :ref:`documentation <index>`, and `ask questions`_ if you
|
||||
run into trouble.
|
||||
|
||||
.. _`Download the code`: http://www.djangoproject.com/download/
|
||||
.. _ask questions: http://www.djangoproject.com/community/
|
||||
|
||||
How do I fix the "install a later version of setuptools" error?
|
||||
---------------------------------------------------------------
|
||||
|
||||
Just run the ``ez_setup.py`` script in the Django distribution.
|
||||
|
||||
What are Django's prerequisites?
|
||||
--------------------------------
|
||||
|
||||
Django requires Python_ 2.3 or later. No other Python libraries are required
|
||||
for basic Django usage.
|
||||
|
||||
For a development environment -- if you just want to experiment with Django --
|
||||
you don't need to have a separate Web server installed; Django comes with its
|
||||
own lightweight development server. For a production environment, we recommend
|
||||
`Apache 2`_ and mod_python_, although Django follows the WSGI_ spec, which
|
||||
means it can run on a variety of server platforms.
|
||||
|
||||
If you want to use Django with a database, which is probably the case, you'll
|
||||
also need a database engine. PostgreSQL_ is recommended, because we're
|
||||
PostgreSQL fans, and MySQL_, `SQLite 3`_, and Oracle_ are also supported.
|
||||
|
||||
.. _Python: http://www.python.org/
|
||||
.. _Apache 2: http://httpd.apache.org/
|
||||
.. _mod_python: http://www.modpython.org/
|
||||
.. _WSGI: http://www.python.org/peps/pep-0333.html
|
||||
.. _PostgreSQL: http://www.postgresql.org/
|
||||
.. _MySQL: http://www.mysql.com/
|
||||
.. _`SQLite 3`: http://www.sqlite.org/
|
||||
.. _Oracle: http://www.oracle.com/
|
||||
|
||||
Do I lose anything by using Python 2.3 versus newer Python versions, such as Python 2.5?
|
||||
----------------------------------------------------------------------------------------
|
||||
|
||||
No. Django itself is guaranteed to work with any version of Python from 2.3
|
||||
and higher.
|
||||
|
||||
If you use a Python version newer than 2.3, you will, of course, be able to
|
||||
take advantage of newer Python features in your own code, along with the speed
|
||||
improvements and other optimizations that have been made to the Python language
|
||||
itself. But the Django framework itself should work equally well on 2.3 as it
|
||||
does on 2.4 or 2.5.
|
||||
|
||||
Do I have to use mod_python?
|
||||
----------------------------
|
||||
|
||||
Although we recommend mod_python for production use, you don't have to use it,
|
||||
thanks to the fact that Django uses an arrangement called WSGI_. Django can
|
||||
talk to any WSGI-enabled server. Other non-mod_python deployment setups are
|
||||
FastCGI, SCGI or AJP. See
|
||||
:ref:`How to use Django with FastCGI, SCGI or AJP <howto-deployment-fastcgi>`
|
||||
for full information.
|
||||
|
||||
Also, see the `server arrangements wiki page`_ for other deployment strategies.
|
||||
|
||||
If you just want to play around and develop things on your local computer, use
|
||||
the development Web server that comes with Django. Things should Just Work.
|
||||
|
||||
.. _WSGI: http://www.python.org/peps/pep-0333.html
|
||||
.. _server arrangements wiki page: http://code.djangoproject.com/wiki/ServerArrangements
|
||||
|
||||
How do I install mod_python on Windows?
|
||||
---------------------------------------
|
||||
|
||||
* For Python 2.4, grab mod_python from `win32 build of mod_python for
|
||||
Python 2.4`_.
|
||||
* For Python 2.4, check out this `Django on Windows howto`_.
|
||||
* For Python 2.3, grab mod_python from http://www.modpython.org/ and read
|
||||
`Running mod_python on Apache on Windows2000`_.
|
||||
* Also, try this (not Windows-specific) `guide to getting mod_python
|
||||
working`_.
|
||||
|
||||
.. _`win32 build of mod_python for Python 2.4`: http://www.lehuen.com/nicolas/index.php/2005/02/21/39-win32-build-of-mod_python-314-for-python-24
|
||||
.. _`Django on Windows howto`: http://thinkhole.org/wp/django-on-windows/
|
||||
.. _`Running mod_python on Apache on Windows2000`: http://groups-beta.google.com/group/comp.lang.python/msg/139af8c83a5a9d4f
|
||||
.. _`guide to getting mod_python working`: http://www.dscpl.com.au/articles/modpython-001.html
|
||||
|
||||
Will Django run under shared hosting (like TextDrive or Dreamhost)?
|
||||
-------------------------------------------------------------------
|
||||
|
||||
See our `Django-friendly Web hosts`_ page.
|
||||
|
||||
.. _`Django-friendly Web hosts`: http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts
|
||||
|
||||
Should I use the official version or development version?
|
||||
---------------------------------------------------------
|
||||
|
||||
The Django developers improve Django every day and are pretty good about not
|
||||
checking in broken code. We use the development code (from the Subversion
|
||||
repository) directly on our servers, so we consider it stable. With that in
|
||||
mind, we recommend that you use the latest development code, because it
|
||||
generally contains more features and fewer bugs than the "official" releases.
|
||||
94
docs/faq/models.txt
Normal file
94
docs/faq/models.txt
Normal file
@@ -0,0 +1,94 @@
|
||||
.. _faq-models:
|
||||
|
||||
FAQ: Databases and models
|
||||
=========================
|
||||
|
||||
How can I see the raw SQL queries Django is running?
|
||||
----------------------------------------------------
|
||||
|
||||
Make sure your Django ``DEBUG`` setting is set to ``True``. Then, just do
|
||||
this::
|
||||
|
||||
>>> from django.db import connection
|
||||
>>> connection.queries
|
||||
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
|
||||
'time': '0.002'}]
|
||||
|
||||
``connection.queries`` is only available if ``DEBUG`` is ``True``. It's a list
|
||||
of dictionaries in order of query execution. Each dictionary has the following::
|
||||
|
||||
``sql`` -- The raw SQL statement
|
||||
``time`` -- How long the statement took to execute, in seconds.
|
||||
|
||||
``connection.queries`` includes all SQL statements -- INSERTs, UPDATES,
|
||||
SELECTs, etc. Each time your app hits the database, the query will be recorded.
|
||||
|
||||
Can I use Django with a pre-existing database?
|
||||
----------------------------------------------
|
||||
|
||||
Yes. See :ref:`Integrating with a legacy database <howto-legacy-databases>`.
|
||||
|
||||
If I make changes to a model, how do I update the database?
|
||||
-----------------------------------------------------------
|
||||
|
||||
If you don't mind clearing data, your project's ``manage.py`` utility has an
|
||||
option to reset the SQL for a particular application::
|
||||
|
||||
manage.py reset appname
|
||||
|
||||
This drops any tables associated with ``appname`` and recreates them.
|
||||
|
||||
If you do care about deleting data, you'll have to execute the ``ALTER TABLE``
|
||||
statements manually in your database. That's the way we've always done it,
|
||||
because dealing with data is a very sensitive operation that we've wanted to
|
||||
avoid automating. That said, there's some work being done to add partially
|
||||
automated database-upgrade functionality.
|
||||
|
||||
Do Django models support multiple-column primary keys?
|
||||
------------------------------------------------------
|
||||
|
||||
No. Only single-column primary keys are supported.
|
||||
|
||||
But this isn't an issue in practice, because there's nothing stopping you from
|
||||
adding other constraints (using the ``unique_together`` model option or
|
||||
creating the constraint directly in your database), and enforcing the
|
||||
uniqueness at that level. Single-column primary keys are needed for things such
|
||||
as the admin interface to work; e.g., you need a simple way of being able to
|
||||
specify an object to edit or delete.
|
||||
|
||||
How do I add database-specific options to my CREATE TABLE statements, such as specifying MyISAM as the table type?
|
||||
------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
We try to avoid adding special cases in the Django code to accommodate all the
|
||||
database-specific options such as table type, etc. If you'd like to use any of
|
||||
these options, create an :ref:`SQL initial data file <initial-sql>` that
|
||||
contains ``ALTER TABLE`` statements that do what you want to do. The initial
|
||||
data files are executed in your database after the ``CREATE TABLE`` statements.
|
||||
|
||||
For example, if you're using MySQL and want your tables to use the MyISAM table
|
||||
type, create an initial data file and put something like this in it::
|
||||
|
||||
ALTER TABLE myapp_mytable ENGINE=MyISAM;
|
||||
|
||||
As explained in the :ref:`SQL initial data file <initial-sql>` documentation,
|
||||
this SQL file can contain arbitrary SQL, so you can make any sorts of changes
|
||||
you need to make.
|
||||
|
||||
Why is Django leaking memory?
|
||||
-----------------------------
|
||||
|
||||
Django isn't known to leak memory. If you find your Django processes are
|
||||
allocating more and more memory, with no sign of releasing it, check to make
|
||||
sure your ``DEBUG`` setting is set to ``True``. If ``DEBUG`` is ``True``, then
|
||||
Django saves a copy of every SQL statement it has executed.
|
||||
|
||||
(The queries are saved in ``django.db.connection.queries``. See
|
||||
`How can I see the raw SQL queries Django is running?`_.)
|
||||
|
||||
To fix the problem, set ``DEBUG`` to ``False``.
|
||||
|
||||
If you need to clear the query list manually at any point in your functions,
|
||||
just call ``reset_queries()``, like this::
|
||||
|
||||
from django import db
|
||||
db.reset_queries()
|
||||
65
docs/faq/usage.txt
Normal file
65
docs/faq/usage.txt
Normal file
@@ -0,0 +1,65 @@
|
||||
.. _faq-usage:
|
||||
|
||||
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 ``FileField`` or an ``ImageField`` in a model takes a few steps:
|
||||
|
||||
#. In your settings file, define ``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
|
||||
``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 ``FileField`` or ``ImageField`` to your model, making sure
|
||||
to define the ``upload_to`` option to tell Django to which subdirectory
|
||||
of ``MEDIA_ROOT`` it should upload files.
|
||||
|
||||
#. All that will be stored in your database is a path to the file
|
||||
(relative to ``MEDIA_ROOT``). You'll most likely want to use the
|
||||
convenience ``get_<fieldname>_url`` function provided by Django. For
|
||||
example, if your ``ImageField`` is called ``mug_shot``, you can get the
|
||||
absolute URL to your image in a template with
|
||||
``{{ object.get_mug_shot_url }}``.
|
||||
Reference in New Issue
Block a user