Added some links in /docs/intro/overview.txt
Thanks Claes Ström for the patch.
This commit is contained in:
parent
f7d7d2be4b
commit
bdde7feb26
|
@ -72,6 +72,8 @@ following:
|
||||||
|
|
||||||
For more information on the :ttag:`load` tag, read its documentation.
|
For more information on the :ttag:`load` tag, read its documentation.
|
||||||
|
|
||||||
|
.. _howto-writing-custom-template-filters:
|
||||||
|
|
||||||
Writing custom template filters
|
Writing custom template filters
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
|
|
|
@ -16,9 +16,11 @@ Design your model
|
||||||
=================
|
=================
|
||||||
|
|
||||||
Although you can use Django without a database, it comes with an
|
Although you can use Django without a database, it comes with an
|
||||||
object-relational mapper in which you describe your database layout in Python
|
`object-relational mapper`_ in which you describe your database layout in Python
|
||||||
code.
|
code.
|
||||||
|
|
||||||
|
.. _object-relational mapper: http://en.wikipedia.org/wiki/Object-relational_mapping
|
||||||
|
|
||||||
The :doc:`data-model syntax </topics/db/models>` offers many rich ways of
|
The :doc:`data-model syntax </topics/db/models>` offers many rich ways of
|
||||||
representing your models -- so far, it's been solving two years' worth of
|
representing your models -- so far, it's been solving two years' worth of
|
||||||
database-schema problems. Here's a quick example, which might be saved in
|
database-schema problems. Here's a quick example, which might be saved in
|
||||||
|
@ -57,8 +59,9 @@ tables in your database for whichever tables don't already exist.
|
||||||
Enjoy the free API
|
Enjoy the free API
|
||||||
==================
|
==================
|
||||||
|
|
||||||
With that, you've got a free, and rich, :doc:`Python API </topics/db/queries>` to
|
With that, you've got a free, and rich, :doc:`Python API </topics/db/queries>`
|
||||||
access your data. The API is created on the fly, no code generation necessary:
|
to access your data. The API is created on the fly, no code generation
|
||||||
|
necessary:
|
||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
|
@ -135,9 +138,9 @@ A dynamic admin interface: it's not just scaffolding -- it's the whole house
|
||||||
============================================================================
|
============================================================================
|
||||||
|
|
||||||
Once your models are defined, Django can automatically create a professional,
|
Once your models are defined, Django can automatically create a professional,
|
||||||
production ready :doc:`administrative interface </ref/contrib/admin/index>` -- a Web
|
production ready :doc:`administrative interface </ref/contrib/admin/index>` --
|
||||||
site that lets authenticated users add, change and delete objects. It's as easy
|
a Web site that lets authenticated users add, change and delete objects. It's
|
||||||
as registering your model in the admin site::
|
as easy as registering your model in the admin site::
|
||||||
|
|
||||||
# In models.py...
|
# In models.py...
|
||||||
|
|
||||||
|
@ -173,9 +176,9 @@ application. Django encourages beautiful URL design and doesn't put any cruft
|
||||||
in URLs, like ``.php`` or ``.asp``.
|
in URLs, like ``.php`` or ``.asp``.
|
||||||
|
|
||||||
To design URLs for an app, you create a Python module called a :doc:`URLconf
|
To design URLs for an app, you create a Python module called a :doc:`URLconf
|
||||||
</topics/http/urls>`. A table of contents for your app, it contains a simple mapping
|
</topics/http/urls>`. A table of contents for your app, it contains a simple
|
||||||
between URL patterns and Python callback functions. URLconfs also serve to
|
mapping between URL patterns and Python callback functions. URLconfs also serve
|
||||||
decouple URLs from Python code.
|
to decouple URLs from Python code.
|
||||||
|
|
||||||
Here's what a URLconf might look like for the ``Reporter``/``Article``
|
Here's what a URLconf might look like for the ``Reporter``/``Article``
|
||||||
example above::
|
example above::
|
||||||
|
@ -188,7 +191,7 @@ example above::
|
||||||
(r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
|
(r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
|
||||||
)
|
)
|
||||||
|
|
||||||
The code above maps URLs, as simple regular expressions, to the location of
|
The code above maps URLs, as simple `regular expressions`_, to the location of
|
||||||
Python callback functions ("views"). The regular expressions use parenthesis to
|
Python callback functions ("views"). The regular expressions use parenthesis to
|
||||||
"capture" values from the URLs. When a user requests a page, Django runs
|
"capture" values from the URLs. When a user requests a page, Django runs
|
||||||
through each pattern, in order, and stops at the first one that matches the
|
through each pattern, in order, and stops at the first one that matches the
|
||||||
|
@ -196,6 +199,8 @@ requested URL. (If none of them matches, Django calls a special-case 404 view.)
|
||||||
This is blazingly fast, because the regular expressions are compiled at load
|
This is blazingly fast, because the regular expressions are compiled at load
|
||||||
time.
|
time.
|
||||||
|
|
||||||
|
.. _regular expressions: http://docs.python.org/2/howto/regex.html
|
||||||
|
|
||||||
Once one of the regexes matches, Django imports and calls the given view, which
|
Once one of the regexes matches, Django imports and calls the given view, which
|
||||||
is a simple Python function. Each view gets passed a request object --
|
is a simple Python function. Each view gets passed a request object --
|
||||||
which contains request metadata -- and the values captured in the regex.
|
which contains request metadata -- and the values captured in the regex.
|
||||||
|
@ -233,8 +238,8 @@ The code above loads the ``news/year_archive.html`` template.
|
||||||
|
|
||||||
Django has a template search path, which allows you to minimize redundancy among
|
Django has a template search path, which allows you to minimize redundancy among
|
||||||
templates. In your Django settings, you specify a list of directories to check
|
templates. In your Django settings, you specify a list of directories to check
|
||||||
for templates. If a template doesn't exist in the first directory, it checks the
|
for templates with :setting:`TEMPLATE_DIRS`. If a template doesn't exist in the
|
||||||
second, and so on.
|
first directory, it checks the second, and so on.
|
||||||
|
|
||||||
Let's say the ``news/year_archive.html`` template was found. Here's what that
|
Let's say the ``news/year_archive.html`` template was found. Here's what that
|
||||||
might look like:
|
might look like:
|
||||||
|
@ -265,9 +270,10 @@ character). This is called a template filter, and it's a way to filter the value
|
||||||
of a variable. In this case, the date filter formats a Python datetime object in
|
of a variable. In this case, the date filter formats a Python datetime object in
|
||||||
the given format (as found in PHP's date function).
|
the given format (as found in PHP's date function).
|
||||||
|
|
||||||
You can chain together as many filters as you'd like. You can write custom
|
You can chain together as many filters as you'd like. You can write :ref:`custom
|
||||||
filters. You can write custom template tags, which run custom Python code behind
|
template filters <howto-writing-custom-template-filters>`. You can write
|
||||||
the scenes.
|
:doc:`custom template tags </howto/custom-template-tags>`, which run custom
|
||||||
|
Python code behind the scenes.
|
||||||
|
|
||||||
Finally, Django uses the concept of "template inheritance": That's what the
|
Finally, Django uses the concept of "template inheritance": That's what the
|
||||||
``{% extends "base.html" %}`` does. It means "First load the template called
|
``{% extends "base.html" %}`` does. It means "First load the template called
|
||||||
|
|
Loading…
Reference in New Issue