Permalink
Browse files

Refs #7864 -- Updates to documentation for the oldforms/newforms switch.

 * Moved forms.txt to oldforms.txt
 * Moved newforms.txt to forms.txt
 * Updated links and most references to "newforms" (there are a few sections that need a more significant rewrite).


git-svn-id: http://code.djangoproject.com/svn/django/trunk@8020 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
1 parent f284745 commit 24aa08f486d7fa7fbfc91b35dd41aadeb0c900da @gdub gdub committed Jul 21, 2008
View
@@ -76,7 +76,7 @@ Requires the sites_ contrib package to be installed as well.
formtools
=========
-A set of high-level abstractions for Django forms (django.newforms).
+A set of high-level abstractions for Django forms (django.forms).
django.contrib.formtools.preview
--------------------------------
View
@@ -115,6 +115,6 @@ change:
.. _template language: ../templates/
.. _transactions: ../transactions/
.. _url dispatch: ../url_dispatch/
-.. _forms and validation: ../forms/
+.. _forms and validation: ../oldforms/
.. _serialization: ../serialization/
.. _authentication: ../authentication/
View
@@ -517,7 +517,7 @@ It's your responsibility to provide the login form in a template called
template context variables:
* ``form``: A ``Form`` object representing the login form. See the
- `newforms documentation`_ for more on ``Form`` objects.
+ `forms documentation`_ for more on ``FormWrapper`` objects.
* ``next``: The URL to redirect to after successful login. This may contain
a query string, too.
* ``site_name``: The name of the current ``Site``, according to the
@@ -557,7 +557,7 @@ block::
{% endblock %}
-.. _newforms documentation: ../newforms/
+.. _forms documentation: ../forms/
.. _site framework docs: ../sites/
Other built-in views
@@ -111,7 +111,7 @@ into the precise details of what ``Field`` can do later on; for now, suffice it
to say that everything descends from ``Field`` and then customizes key pieces
of the class behavior.
-.. _form fields: ../newforms/#fields
+.. _form fields: ../forms/#fields
It's important to realize that a Django field class is not what is stored in
your model attributes. The model attributes contain normal Python objects. The
@@ -493,8 +493,8 @@ This assumes we're imported a ``MyFormField`` field class (which has its own
default widget). This document doesn't cover the details of writing custom form
fields.
-.. _helper functions: ../newforms/#generating-forms-for-models
-.. _forms documentation: ../newforms/
+.. _helper functions: ../forms/#generating-forms-for-models
+.. _forms documentation: ../forms/
``get_internal_type(self)``
~~~~~~~~~~~~~~~~~~~~~~~~~~~
View
@@ -20,13 +20,13 @@ For this reason, Django provides a few helper functions that let you create a
``form_for_model()``
--------------------
-The method ``django.newforms.form_for_model()`` creates a form based on the
+The method ``django.forms.form_for_model()`` creates a form based on the
definition of a specific model. Pass it the model class, and it will return a
``Form`` class that contains a form field for each model field.
For example::
- >>> from django.newforms import form_for_model
+ >>> from django.forms import form_for_model
# Create the form class.
>>> ArticleForm = form_for_model(Article)
@@ -93,11 +93,11 @@ the full list of conversions:
As you might expect, the ``ForeignKey`` and ``ManyToManyField`` model field
types are special cases:
- * ``ForeignKey`` is represented by ``django.newforms.ModelChoiceField``,
+ * ``ForeignKey`` is represented by ``django.forms.ModelChoiceField``,
which is a ``ChoiceField`` whose choices are a model ``QuerySet``.
* ``ManyToManyField`` is represented by
- ``django.newforms.ModelMultipleChoiceField``, which is a
+ ``django.forms.ModelMultipleChoiceField``, which is a
``MultipleChoiceField`` whose choices are a model ``QuerySet``.
In addition, each generated form field has attributes set as follows:
@@ -228,7 +228,7 @@ Using an alternate base class
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want to add custom methods to the form generated by
-``form_for_model()``, write a class that extends ``django.newforms.BaseForm``
+``form_for_model()``, write a class that extends ``django.forms.BaseForm``
and contains your custom methods. Then, use the ``form`` argument to
``form_for_model()`` to tell it to use your custom form as its base class.
For example::
@@ -412,8 +412,8 @@ note is that the form display in the ``GET`` branch of the function
will use the values from the ``message`` instance as initial values for the
form field.
-.. _contact form: ../newforms/#simple-view-example
-.. _`simple example view`: ../newforms/#simple-view-example
+.. _contact form: ../forms/#simple-view-example
+.. _`simple example view`: ../forms/#simple-view-example
When should you use ``form_for_model()`` and ``form_for_instance()``?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
View
@@ -13,7 +13,7 @@ Python class.
Overview
=========
-Given a ``django.newforms.Form`` subclass that you define, this application
+Given a ``django.forms.Form`` subclass that you define, this application
takes care of the following workflow:
1. Displays the form as HTML on a Web page.
@@ -65,7 +65,7 @@ How to use ``FormPreview``
from myapp.preview import SomeModelFormPreview
from myapp.models import SomeModel
- from django import newforms as forms
+ from django import forms
...and add the following line to the appropriate model in your URLconf::
View
@@ -17,7 +17,7 @@ etc.
The term "wizard," in this context, is `explained on Wikipedia`_.
.. _explained on Wikipedia: http://en.wikipedia.org/wiki/Wizard_%28software%29
-.. _forms: ../newforms/
+.. _forms: ../forms/
How it works
============
@@ -41,7 +41,7 @@ Usage
This application handles as much machinery for you as possible. Generally, you
just have to do these things:
- 1. Define a number of ``django.newforms`` ``Form`` classes -- one per wizard
+ 1. Define a number of ``django.forms`` ``Form`` classes -- one per wizard
page.
2. Create a ``FormWizard`` class that specifies what to do once all of your
forms have been submitted and validated. This also lets you override some
@@ -55,8 +55,8 @@ Defining ``Form`` classes
=========================
The first step in creating a form wizard is to create the ``Form`` classes.
-These should be standard ``django.newforms`` ``Form`` classes, covered in the
-`newforms documentation`_.
+These should be standard ``django.forms`` ``Form`` classes, covered in the
+`forms documentation`_.
These classes can live anywhere in your codebase, but convention is to put them
in a file called ``forms.py`` in your application.
@@ -65,7 +65,7 @@ For example, let's write a "contact form" wizard, where the first page's form
collects the sender's e-mail address and subject, and the second page collects
the message itself. Here's what the ``forms.py`` might look like::
- from django import newforms as forms
+ from django import forms
class ContactForm1(forms.Form):
subject = forms.CharField(max_length=100)
@@ -78,7 +78,7 @@ the message itself. Here's what the ``forms.py`` might look like::
data between pages, you may not include a ``FileField`` in any form except the
last one.
-.. _newforms documentation: ../newforms/
+.. _forms documentation: ../forms/
Creating a ``FormWizard`` class
===============================
@@ -94,7 +94,7 @@ which specifies what should happen when the data for *every* form is submitted
and validated. This method is passed two arguments:
* ``request`` -- an HttpRequest_ object
- * ``form_list`` -- a list of ``django.newforms`` ``Form`` classes
+ * ``form_list`` -- a list of ``django.forms`` ``Form`` classes
In this simplistic example, rather than perform any database operation, the
method simply renders a template of the validated data::
@@ -209,7 +209,7 @@ Default implementation::
def prefix_for_step(self, step):
return str(step)
-.. _form prefix documentation: ../newforms/#prefixes-for-forms
+.. _form prefix documentation: ../forms/#prefixes-for-forms
``render_hash_failure``
~~~~~~~~~~~~~~~~~~~~~~~
Oops, something went wrong.

0 comments on commit 24aa08f

Please sign in to comment.