[soc2009/model-validation] Merged to trunk at r11603

SECURITY ALERT: Corrected regular expressions for URL and email fields.

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/model-validation@11617 bcc190cf-cafb-0310-a4f2-bffc1f526a37

7 files changed, 71 insertions, 51 deletions

diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt
index 584672e4f0..c1e05eda1d 100644
--- a/docs/ref/contrib/admin/index.txt
+++ b/docs/ref/contrib/admin/index.txt
@@ -25,21 +25,26 @@ Django's admin interface.
 Overview
 ========
 
-There are five steps in activating the Django admin site:
+There are six steps in activating the Django admin site:
 
-    1. Add ``django.contrib.admin`` to your ``INSTALLED_APPS`` setting.
+    1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS`
+       setting.
 
-    2. Determine which of your application's models should be editable in the
+    2. Admin has two dependencies - ``django.contrib.auth`` and
+       ``django.contrib.contenttypes``. If these applications are not
+       in your :setting:`INSTALLED_APPS` list, add them.
+
+    3. Determine which of your application's models should be editable in the
        admin interface.
 
-    3. For each of those models, optionally create a ``ModelAdmin`` class that
+    4. For each of those models, optionally create a ``ModelAdmin`` class that
        encapsulates the customized admin functionality and options for that
        particular model.
 
-    4. Instantiate an ``AdminSite`` and tell it about each of your models and
+    5. Instantiate an ``AdminSite`` and tell it about each of your models and
        ``ModelAdmin`` classes.
 
-    5. Hook the ``AdminSite`` instance into your URLconf.
+    6. Hook the ``AdminSite`` instance into your URLconf.
 
 Other topics
 ------------
@@ -845,7 +850,7 @@ the admin application URL dispatching handler to render the pages that deal
 with model instances CRUD operations. As a result, completely overriding these
 methods will significantly change the behavior of the admin application.
 
-One comon reason for overriding these methods is to augment the context data
+One common reason for overriding these methods is to augment the context data
 that is provided to the template that renders the view. In the following
 example, the change view is overridden so that the rendered template is
 provided some extra mapping data that would not otherwise be available::
diff --git a/docs/ref/contrib/comments/index.txt b/docs/ref/contrib/comments/index.txt
index f6e1553bac..880be34101 100644
--- a/docs/ref/contrib/comments/index.txt
+++ b/docs/ref/contrib/comments/index.txt
@@ -24,13 +24,13 @@ Quick start guide
 
 To get started using the ``comments`` app, follow these steps:
 
-    #. Install the comments framework by adding ``'django.contrib.comments'`` to    
+    #. Install the comments framework by adding ``'django.contrib.comments'`` to
        :setting:`INSTALLED_APPS`.
 
     #. Run ``manage.py syncdb`` so that Django will create the comment tables.
 
     #. Add the comment app's URLs to your project's ``urls.py``:
-   
+
        .. code-block:: python
 
             urlpatterns = patterns('',
@@ -41,9 +41,9 @@ To get started using the ``comments`` app, follow these steps:
 
     #. Use the `comment template tags`_ below to embed comments in your
        templates.
-    
+
 You might also want to examine :ref:`ref-contrib-comments-settings`.
-    
+
 Comment template tags
 =====================
 
@@ -67,20 +67,20 @@ different ways you can specify which object to attach to:
     #. Refer to the object directly -- the more common method. Most of the
        time, you'll have some object in the template's context you want
        to attach the comment to; you can simply use that object.
-       
-       For example, in a blog entry page that has a variable named ``entry``, 
+
+       For example, in a blog entry page that has a variable named ``entry``,
        you could use the following to load the number of comments::
-       
+
             {% get_comment_count for entry as comment_count %}.
-            
+
     #. Refer to the object by content-type and object id. You'd use this method
        if you, for some reason, don't actually have direct access to the object.
-       
+
        Following the above example, if you knew the object ID was ``14`` but
        didn't have access to the actual object, you could do something like::
-       
+
             {% get_comment_count for blog.entry 14 as comment_count %}
-            
+
        In the above, ``blog.entry`` is the app label and (lower-cased) model
        name of the model class.
 
@@ -89,7 +89,7 @@ different ways you can specify which object to attach to:
 Displaying comments
 -------------------
 
-To get a the list of comments for some object, use :ttag:`get_comment_list`::
+To get the list of comments for some object, use :ttag:`get_comment_list`::
 
     {% get_comment_list for [object] as [varname] %}
 
@@ -99,7 +99,7 @@ For example::
     {% for comment in comment_list %}
         ...
     {% endfor %}
-    
+
 This returns a list of :class:`~django.contrib.comments.models.Comment` objects;
 see :ref:`the comment model documentation <ref-contrib-comments-models>` for
 details.
@@ -116,9 +116,9 @@ To count comments attached to an object, use :ttag:`get_comment_count`::
 For example::
 
         {% get_comment_count for event as comment_count %}
-        
+
         <p>This event has {{ comment_count }} comments.</p>
-        
+
 
 Displaying the comment post form
 --------------------------------
@@ -153,7 +153,7 @@ If you want more control over the look and feel of the comment form, you use use
 you can use in the template::
 
     {% get_comment_form for [object] as [varname] %}
-    
+
 A complete form might look like::
 
     {% get_comment_form for event as form %}
@@ -164,7 +164,7 @@ A complete form might look like::
         <td><input type="submit" name="preview" class="submit-post" value="Preview"></td>
       </tr>
     </form>
-    
+
 Be sure to read the `notes on the comment form`_, below, for some special
 considerations you'll need to make if you're using this approach.
 
@@ -185,7 +185,7 @@ Redirecting after the comment post
 
 To specify the URL you want to redirect to after the comment has been posted,
 you can include a hidden form input called ``next`` in your comment form. For example::
- 
+
     <input type="hidden" name="next" value="{% url my_comment_was_posted %}" />
 
 .. _notes-on-the-comment-form:
@@ -198,24 +198,24 @@ should know about:
 
     * It contains a number of hidden fields that contain timestamps, information
       about the object the comment should be attached to, and a "security hash"
-      used to validate this information. If someone tampers with this data -- 
+      used to validate this information. If someone tampers with this data --
       something comment spammers will try -- the comment submission will fail.
-      
+
       If you're rendering a custom comment form, you'll need to make sure to
       pass these values through unchanged.
-      
+
     * The timestamp is used to ensure that "reply attacks" can't continue very
       long. Users who wait too long between requesting the form and posting a
       comment will have their submissions refused.
-      
+
     * The comment form includes a "honeypot_" field. It's a trap: if any data is
       entered in that field, the comment will be considered spam (spammers often
       automatically fill in all fields in an attempt to make valid submissions).
-      
+
       The default form hides this field with a piece of CSS and further labels
       it with a warning field; if you use the comment form with a custom
       template you should be sure to do the same.
-    
+
 .. _honeypot: http://en.wikipedia.org/wiki/Honeypot_(computing)
 
 More information
@@ -230,4 +230,4 @@ More information
    upgrade
    custom
    forms
-   moderation
\ No newline at end of file
+   moderation
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 177df12862..0cb5be4b92 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -844,7 +844,7 @@ define the details of how the relation works.
     current date/time to be chosen.
 
     Instead of a dictionary this can also be a :class:`~django.db.models.Q`
-    object (an object with a :meth:`get_sql` method) for more complex queries.
+    object for more :ref:`complex queries <complex-lookups-with-q>`.
 
     ``limit_choices_to`` has no effect on the inline FormSets that are created
     to display related objects in the admin.
diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt
index 8402567f7a..9bf73f5b85 100644
--- a/docs/ref/models/options.txt
+++ b/docs/ref/models/options.txt
@@ -19,6 +19,17 @@ Available ``Meta`` options
 
 If ``True``, this model will be an :ref:`abstract base class <abstract-base-classes>`.
 
+``app_label``
+-------------
+
+.. attribute:: Options.app_label
+
+If a model exists outside of the standard :file:`models.py` (for instance, if
+the app's models are in submodules of ``myapp.models``), the model must define
+which app it is part of::
+
+    app_label = 'myapp'
+
 ``db_table``
 ------------
 
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index f78ebc506a..efd7c549b8 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -20,7 +20,7 @@ Throughout this reference we'll use the :ref:`example weblog models
 When QuerySets are evaluated
 ============================
 
-Internally, a ``QuerySet`` can be constructed, filter, sliced, and generally
+Internally, a ``QuerySet`` can be constructed, filtered, sliced, and generally
 passed around without actually hitting the database. No database activity
 actually occurs until you do something to evaluate the queryset.
 
@@ -1512,9 +1512,10 @@ regex
 
 Case-sensitive regular expression match.
 
-The regular expression syntax is that of the database backend in use. In the
-case of SQLite, which doesn't natively support regular-expression lookups, the
-syntax is that of Python's ``re`` module.
+The regular expression syntax is that of the database backend in use.
+In the case of SQLite, which has no built in regular expression support,
+this feature is provided by a (Python) user-defined REGEXP function, and
+the regular expression syntax is therefore that of Python's ``re`` module.
 
 Example::
 
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 9df156a6f2..77d991bc1f 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -262,7 +262,7 @@ a subclass of dictionary. Exceptions are outlined here:
 
     Returns the value for the given key. If the key has more than one value,
     ``__getitem__()`` returns the last value. Raises
-    ``django.utils.datastructure.MultiValueDictKeyError`` if the key does not
+    ``django.utils.datastructures.MultiValueDictKeyError`` if the key does not
     exist. (This is a subclass of Python's standard ``KeyError``, so you can
     stick to catching ``KeyError``.)
 
@@ -310,7 +310,7 @@ a subclass of dictionary. Exceptions are outlined here:
            >>> q = QueryDict('a=1&a=2&a=3')
            >>> q.items()
            [('a', '3')]
-           
+
 .. method:: QueryDict.iteritems()
 
     Just like the standard dictionary ``iteritems()`` method. Like
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index 87e1ce3b77..cc203f1817 100644
--- a/docs/ref/signals.txt
+++ b/docs/ref/signals.txt
@@ -8,6 +8,9 @@ A list of all the signals that Django sends.
 
 .. seealso::
 
+    See the documentation on the :ref:`signal dispatcher <topics-signals>` for
+    information regarding how to register for and receive signals.
+
     The :ref:`comment framework <ref-contrib-comments-index>` sends a :ref:`set
     of comment-related signals <ref-contrib-comments-signals>`.
 
@@ -98,7 +101,7 @@ pre_save
 
 .. data:: django.db.models.signals.pre_save
    :module:
-   
+
 This is sent at the beginning of a model's :meth:`~django.db.models.Model.save`
 method.
 
@@ -114,8 +117,8 @@ post_save
 ---------
 
 .. data:: django.db.models.signals.post_save
-   :module: 
-   
+   :module:
+
 Like :data:`pre_save`, but sent at the end of the
 :meth:`~django.db.models.Model.save` method.
 
@@ -135,7 +138,7 @@ pre_delete
 
 .. data:: django.db.models.signals.pre_delete
    :module:
-   
+
 Sent at the beginning of a model's :meth:`~django.db.models.Model.delete`
 method.
 
@@ -151,8 +154,8 @@ post_delete
 -----------
 
 .. data:: django.db.models.signals.post_delete
-   :module: 
-   
+   :module:
+
 Like :data:`pre_delete`, but sent at the end of the
 :meth:`~django.db.models.Model.delete` method.
 
@@ -172,7 +175,7 @@ class_prepared
 
 .. data:: django.db.models.signals.class_prepared
    :module:
-   
+
 Sent whenever a model class has been "prepared" -- that is, once model has
 been defined and registered with Django's model system. Django uses this
 signal internally; it's not generally used in third-party applications.
@@ -241,8 +244,8 @@ request_started
 ---------------
 
 .. data:: django.core.signals.request_started
-   :module: 
-   
+   :module:
+
 Sent when Django begins processing an HTTP request.
 
 Arguments sent with this signal:
@@ -258,7 +261,7 @@ request_finished
 
 .. data:: django.core.signals.request_finished
    :module:
-   
+
 Sent when Django finishes processing an HTTP request.
 
 Arguments sent with this signal:
@@ -271,7 +274,7 @@ got_request_exception
 
 .. data:: django.core.signals.got_request_exception
    :module:
-   
+
 This signal is sent whenever Django encounters an exception while processing an incoming HTTP request.
 
 Arguments sent with this signal:
@@ -295,7 +298,7 @@ template_rendered
 
 .. data:: django.test.signals.template_rendered
    :module:
-   
+
 Sent when the test system renders a template. This signal is not emitted during
 normal operation of a Django server -- it is only available during testing.