mirror of
https://github.com/django/django.git
synced 2025-10-31 09:41:08 +00:00
queryset-refactor: Merged from trunk up to [7122].
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@7124 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
@@ -88,7 +88,7 @@ change:
|
||||
API changes may be necessary.
|
||||
|
||||
- Generic relations will most likely be moved out of core and into the
|
||||
content-types contrib package to avoid core dependancies on optional
|
||||
content-types contrib package to avoid core dependencies on optional
|
||||
components.
|
||||
|
||||
- The comments framework, which is yet undocumented, will likely get a complete
|
||||
|
||||
@@ -215,7 +215,7 @@ each ``TaggedItem`` will have a ``content_object`` field that returns the
|
||||
object it's related to, and you can also assign to that field or use it when
|
||||
creating a ``TaggedItem``::
|
||||
|
||||
>>> from django.contrib.models.auth import User
|
||||
>>> from django.contrib.auth.models import User
|
||||
>>> guido = User.objects.get(username='Guido')
|
||||
>>> t = TaggedItem(content_object=guido, tag='bdfl')
|
||||
>>> t.save()
|
||||
@@ -235,7 +235,7 @@ a "reverse" generic relationship to enable an additional API. For example::
|
||||
``Bookmark`` instances will each have a ``tags`` attribute, which can
|
||||
be used to retrieve their associated ``TaggedItems``::
|
||||
|
||||
>>> b = Bookmark('http://www.djangoproject.com/')
|
||||
>>> b = Bookmark(url='http://www.djangoproject.com/')
|
||||
>>> b.save()
|
||||
>>> t1 = TaggedItem(content_object=b, tag='django')
|
||||
>>> t1.save()
|
||||
|
||||
@@ -5,7 +5,7 @@ Third-party distributions of Django
|
||||
Several third-party distributors are now providing versions of Django integrated
|
||||
with their package-management systems. These can make installation and upgrading
|
||||
much easier for users of Django since the integration includes the ability to
|
||||
automatically install dependancies (like database adapters) that Django
|
||||
automatically install dependencies (like database adapters) that Django
|
||||
requires.
|
||||
|
||||
Typically, these packages are based on the latest stable release of Django, so
|
||||
|
||||
@@ -717,7 +717,7 @@ in Python package syntax, e.g. ``mysite.settings``. If this isn't provided,
|
||||
variable.
|
||||
|
||||
Note that this option is unnecessary in ``manage.py``, because it uses
|
||||
``settings.py`` from the current project by default.
|
||||
``settings.py`` from the current project by default.
|
||||
|
||||
Extra niceties
|
||||
==============
|
||||
@@ -765,9 +765,9 @@ a command that can be executed as an action when you run ``manage.py``::
|
||||
__init__.py
|
||||
explode.py
|
||||
views.py
|
||||
|
||||
|
||||
In this example, the ``explode`` command will be made available to any project
|
||||
that includes the ``fancy_blog`` application in ``settings.INSTALLED_APPS``.
|
||||
that includes the ``blog`` application in ``settings.INSTALLED_APPS``.
|
||||
|
||||
The ``explode.py`` module has only one requirement -- it must define a class
|
||||
called ``Command`` that extends ``django.core.management.base.BaseCommand``.
|
||||
|
||||
@@ -138,7 +138,7 @@ Installing a distribution-specific package
|
||||
Check the `distribution specific notes`_ to see if your
|
||||
platform/distribution provides official Django packages/installers.
|
||||
Distribution-provided packages will typically allow for automatic
|
||||
installation of dependancies and easy upgrade paths.
|
||||
installation of dependencies and easy upgrade paths.
|
||||
|
||||
Installing an official release
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -384,7 +384,7 @@ The admin represents this as an ``<input type="text">`` (a single-line input).
|
||||
``IPAddressField``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
An IP address, in string format (i.e. "24.124.1.30").
|
||||
An IP address, in string format (e.g. "192.0.2.30").
|
||||
|
||||
The admin represents this as an ``<input type="text">`` (a single-line input).
|
||||
|
||||
@@ -952,10 +952,10 @@ the relationship should work. All are optional:
|
||||
``limit_choices_to`` See the description under ``ForeignKey`` above.
|
||||
|
||||
``symmetrical`` Only used in the definition of ManyToManyFields on self.
|
||||
Consider the following model:
|
||||
Consider the following model::
|
||||
|
||||
class Person(models.Model):
|
||||
friends = models.ManyToManyField("self")
|
||||
class Person(models.Model):
|
||||
friends = models.ManyToManyField("self")
|
||||
|
||||
When Django processes this model, it identifies that it has
|
||||
a ``ManyToManyField`` on itself, and as a result, it
|
||||
@@ -1871,7 +1871,7 @@ more simply as::
|
||||
|
||||
If you define a ``__unicode__()`` method on your model and not a ``__str__()``
|
||||
method, Django will automatically provide you with a ``__str__()`` that calls
|
||||
``__unicode()__`` and then converts the result correctly to a UTF-8 encoded
|
||||
``__unicode__()`` and then converts the result correctly to a UTF-8 encoded
|
||||
string object. This is recommended development practice: define only
|
||||
``__unicode__()`` and let Django take care of the conversion to string objects
|
||||
when required.
|
||||
|
||||
@@ -320,3 +320,41 @@ parameter when declaring the form field::
|
||||
...
|
||||
... class Meta:
|
||||
... model = Article
|
||||
|
||||
Form inheritance
|
||||
----------------
|
||||
|
||||
As with basic forms, you can extend and reuse ``ModelForms`` by inheriting
|
||||
them. This is useful if you need to declare extra fields or extra methods on a
|
||||
parent class for use in a number of forms derived from models. For example,
|
||||
using the previous ``ArticleForm`` class::
|
||||
|
||||
>>> class EnhancedArticleForm(ArticleForm):
|
||||
... def clean_pub_date(self):
|
||||
... ...
|
||||
|
||||
This creates a form that behaves identically to ``ArticleForm``, except there's
|
||||
some extra validation and cleaning for the ``pub_date`` field.
|
||||
|
||||
You can also subclass the parent's ``Meta`` inner class if you want to change
|
||||
the ``Meta.fields`` or ``Meta.excludes`` lists::
|
||||
|
||||
>>> class RestrictedArticleForm(EnhancedArticleForm):
|
||||
... class Meta(ArticleForm.Meta):
|
||||
... exclude = ['body']
|
||||
|
||||
This adds the extra method from the ``EnhancedArticleForm`` and modifies
|
||||
the original ``ArticleForm.Meta`` to remove one field.
|
||||
|
||||
There are a couple of things to note, however.
|
||||
|
||||
* Normal Python name resolution rules apply. If you have multiple base
|
||||
classes that declare a ``Meta`` inner class, only the first one will be
|
||||
used. This means the child's ``Meta``, if it exists, otherwise the
|
||||
``Meta`` of the first parent, etc.
|
||||
|
||||
* For technical reasons, a subclass cannot inherit from both a ``ModelForm``
|
||||
and a ``Form`` simultaneously.
|
||||
|
||||
Chances are these notes won't affect you unless you're trying to do something
|
||||
tricky with subclassing.
|
||||
|
||||
@@ -576,7 +576,7 @@ Three things to note about 404 views:
|
||||
in the 404.
|
||||
|
||||
* The 404 view is passed a ``RequestContext`` and will have access to
|
||||
variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` (e.g.
|
||||
variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` setting (e.g.,
|
||||
``MEDIA_URL``).
|
||||
|
||||
* If ``DEBUG`` is set to ``True`` (in your settings module), then your 404
|
||||
|
||||
@@ -30,9 +30,9 @@ Optional arguments
|
||||
``context_instance``
|
||||
The context instance to render the template with. By default, the template
|
||||
will be rendered with a ``Context`` instance (filled with values from
|
||||
``dictionary``). If you need to use `context processors`_, you will want to
|
||||
render the template with a ``RequestContext`` instance instead. Your code
|
||||
might look something like this::
|
||||
``dictionary``). If you need to use `context processors`_, render the
|
||||
template with a ``RequestContext`` instance instead. Your code might look
|
||||
something like this::
|
||||
|
||||
return render_to_response('my_template.html',
|
||||
my_data_dictionary,
|
||||
|
||||
@@ -1406,6 +1406,8 @@ Joins a list with a string, like Python's ``str.join(list)``.
|
||||
last
|
||||
~~~~
|
||||
|
||||
**New in Django development version.**
|
||||
|
||||
Returns the last item in a list.
|
||||
|
||||
length
|
||||
|
||||
@@ -190,6 +190,28 @@ The remaining arguments should be tuples in this format::
|
||||
...where ``optional dictionary`` and ``optional name`` are optional. (See
|
||||
`Passing extra options to view functions`_ below.)
|
||||
|
||||
.. note::
|
||||
Because `patterns()` is a function call, it accepts a maximum of 255
|
||||
arguments (URL patterns, in this case). This is a limit for all Python
|
||||
function calls. This is rarely a problem in practice, because you'll
|
||||
typically structure your URL patterns modularly by using `include()`
|
||||
sections. However, on the off-chance you do hit the 255-argument limit,
|
||||
realize that `patterns()` returns a Python list, so you can split up the
|
||||
construction of the list.
|
||||
|
||||
::
|
||||
|
||||
urlpatterns = patterns('',
|
||||
...
|
||||
)
|
||||
urlpatterns += patterns('',
|
||||
...
|
||||
)
|
||||
|
||||
Python lists have unlimited size, so there's no limit to how many URL
|
||||
patterns you can construct. The only limit is that you can only create 254
|
||||
at a time (the 255th argument is the initial prefix argument).
|
||||
|
||||
url
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user