diff options
| author | Justin Bronn <jbronn@gmail.com> | 2008-02-28 21:24:51 +0000 |
|---|---|---|
| committer | Justin Bronn <jbronn@gmail.com> | 2008-02-28 21:24:51 +0000 |
| commit | 22e016ff6c18a35a450519b94de63033f83e6b4f (patch) | |
| tree | 1e58cc40a636b4e4f3dcf429a5a116c015c36278 /docs | |
| parent | 0b52413cc926446f238fd781b4def6804f64d231 (diff) | |
gis: Merged revisions 7105-7168 via svnmerge from trunk.
git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@7176 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/api_stability.txt | 2 | ||||
| -rw-r--r-- | docs/contenttypes.txt | 4 | ||||
| -rw-r--r-- | docs/db-api.txt | 3 | ||||
| -rw-r--r-- | docs/distributions.txt | 2 | ||||
| -rw-r--r-- | docs/django-admin.txt | 6 | ||||
| -rw-r--r-- | docs/faq.txt | 2 | ||||
| -rw-r--r-- | docs/install.txt | 2 | ||||
| -rw-r--r-- | docs/model-api.txt | 24 | ||||
| -rw-r--r-- | docs/modelforms.txt | 38 | ||||
| -rw-r--r-- | docs/request_response.txt | 2 | ||||
| -rw-r--r-- | docs/serialization.txt | 2 | ||||
| -rw-r--r-- | docs/shortcuts.txt | 6 | ||||
| -rw-r--r-- | docs/templates.txt | 2 | ||||
| -rw-r--r-- | docs/templates_python.txt | 4 | ||||
| -rw-r--r-- | docs/url_dispatch.txt | 22 |
15 files changed, 96 insertions, 25 deletions
diff --git a/docs/api_stability.txt b/docs/api_stability.txt index 5ccf104327..769359b75e 100644 --- a/docs/api_stability.txt +++ b/docs/api_stability.txt @@ -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 diff --git a/docs/contenttypes.txt b/docs/contenttypes.txt index 3ef83f2066..51ca8f0198 100644 --- a/docs/contenttypes.txt +++ b/docs/contenttypes.txt @@ -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() diff --git a/docs/db-api.txt b/docs/db-api.txt index adca8b4d5c..80f8a2d60b 100644 --- a/docs/db-api.txt +++ b/docs/db-api.txt @@ -1605,8 +1605,7 @@ the cache of all one-to-many relationships ahead of time. Example:: print e.blog # Doesn't hit the database; uses cached version. print e.blog # Doesn't hit the database; uses cached version. -``select_related()`` is documented in the "QuerySet methods that return new -QuerySets" section above. +``select_related()`` is documented in the `QuerySet methods that return new QuerySets`_ section above. Backward ~~~~~~~~ diff --git a/docs/distributions.txt b/docs/distributions.txt index 48c30c7068..0c051c8da5 100644 --- a/docs/distributions.txt +++ b/docs/distributions.txt @@ -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 diff --git a/docs/django-admin.txt b/docs/django-admin.txt index 21821ab2e9..e79c105bbd 100644 --- a/docs/django-admin.txt +++ b/docs/django-admin.txt @@ -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``. diff --git a/docs/faq.txt b/docs/faq.txt index cef0508562..3d7db36fbc 100644 --- a/docs/faq.txt +++ b/docs/faq.txt @@ -353,7 +353,7 @@ How do I install mod_python on Windows? 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/2006/04/03/django-on-windows-howto/ +.. _`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 diff --git a/docs/install.txt b/docs/install.txt index 331a5ea8e3..542036e2af 100644 --- a/docs/install.txt +++ b/docs/install.txt @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/model-api.txt b/docs/model-api.txt index 3f908ec158..66fa63e3c6 100644 --- a/docs/model-api.txt +++ b/docs/model-api.txt @@ -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). @@ -784,9 +784,17 @@ you can use the name of the model, rather than the model object itself:: class Manufacturer(models.Model): # ... -Note, however, that you can only use strings to refer to models in the same -models.py file -- you cannot use a string to reference a model in a different -application, or to reference a model that has been imported from elsewhere. +Note, however, that this only refers to models in the same models.py file -- you +cannot use a string to reference a model defined in another application or +imported from elsewhere. + +**New in Django development version:** to refer to models defined in another +application, you must instead explicitially specify the application label. That +is, if the ``Manufacturer`` model above is defined in another application called +``production``, you'd need to use:: + + class Car(models.Model): + manufacturer = models.ForeignKey('production.Manufacturer') Behind the scenes, Django appends ``"_id"`` to the field name to create its database column name. In the above example, the database table for the ``Car`` @@ -952,10 +960,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 @@ -1872,7 +1880,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. diff --git a/docs/modelforms.txt b/docs/modelforms.txt index a99e27fff7..853fb3159e 100644 --- a/docs/modelforms.txt +++ b/docs/modelforms.txt @@ -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. diff --git a/docs/request_response.txt b/docs/request_response.txt index 47c66355e8..e50cfc5ea3 100644 --- a/docs/request_response.txt +++ b/docs/request_response.txt @@ -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 diff --git a/docs/serialization.txt b/docs/serialization.txt index dff33f219f..e901410f1c 100644 --- a/docs/serialization.txt +++ b/docs/serialization.txt @@ -88,7 +88,7 @@ something like:: for deserialized_object in serializers.deserialize("xml", data): if object_should_be_saved(deserialized_object): - obj.save() + deserialized_object.save() In other words, the usual use is to examine the deserialized objects to make sure that they are "appropriate" for saving before doing so. Of course, if you trust your data source you could just save the object and move on. diff --git a/docs/shortcuts.txt b/docs/shortcuts.txt index f1d7f38ffa..005fdc3029 100644 --- a/docs/shortcuts.txt +++ b/docs/shortcuts.txt @@ -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, diff --git a/docs/templates.txt b/docs/templates.txt index c351c951c9..d473a6f06f 100644 --- a/docs/templates.txt +++ b/docs/templates.txt @@ -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 diff --git a/docs/templates_python.txt b/docs/templates_python.txt index f98cfa3249..c6e9223e9f 100644 --- a/docs/templates_python.txt +++ b/docs/templates_python.txt @@ -395,6 +395,8 @@ See the `internationalization docs`_ for more. django.core.context_processors.media ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**New in Django development version** + If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every ``RequestContext`` will contain a variable ``MEDIA_URL``, providing the value of the `MEDIA_URL setting`_. @@ -1014,7 +1016,7 @@ This is not a very common situation, but it's useful if you're rendering a template yourself. For example:: def render(self, context): - t = template.load_template('small_fragment.html') + t = template.loader.get_template('small_fragment.html') return t.render(Context({'var': obj}, autoescape=context.autoescape)) If we had neglected to pass in the current ``context.autoescape`` value to our diff --git a/docs/url_dispatch.txt b/docs/url_dispatch.txt index 6ed7043fd5..789399de8d 100644 --- a/docs/url_dispatch.txt +++ b/docs/url_dispatch.txt @@ -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 --- |
