|
From: <sub...@co...> - 2005-11-20 22:06:05
|
Author: ianb
Date: 2005-11-20 22:05:46 +0000 (Sun, 20 Nov 2005)
New Revision: 1306
Removed:
FormEncode/trunk/formencode/conftest.py
Modified:
FormEncode/trunk/docs/Validator.txt
FormEncode/trunk/docs/history.txt
FormEncode/trunk/docs/htmlfill.txt
FormEncode/trunk/docs/index.txt
FormEncode/trunk/docs/news.txt
FormEncode/trunk/formencode/api.py
FormEncode/trunk/formencode/compound.py
FormEncode/trunk/formencode/foreach.py
FormEncode/trunk/formencode/formgen.py
FormEncode/trunk/formencode/htmlform.py
FormEncode/trunk/formencode/interfaces.py
FormEncode/trunk/formencode/validators.py
FormEncode/trunk/formencode/variabledecode.py
FormEncode/trunk/setup.cfg
Log:
Proofread all the docs, made links into the generated documentation; extended class's __doc__ with message information; fixed up more docstrings; removed cruft conftest module; made history.txt get generated
Modified: FormEncode/trunk/docs/Validator.txt
===================================================================
--- FormEncode/trunk/docs/Validator.txt 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/docs/Validator.txt 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,10 +1,7 @@
.. comment (set Emacs mode) -*- doctest -*-
>>> import sys
- >>> try:
- ... import formencode
- ... except ImportError:
- ... sys.path.append('/usr/home/ianb/colorstudy.com/FormEncode/trunk')
+ >>> import formencode
+++++++++++++++++++++
FormEncode Validation
@@ -19,26 +16,29 @@
Introduction
============
-TODO
+Validation (which encompasses conversion as well) is the core function
+of FormEncode. FormEncode really tries to *encode* the values from
+one source into another (hence the name). So a Python structure can
+be encoded in a series of HTML fields (a flat dictionary of strings).
+A HTML form submission can in turn be turned into a the original
+Python structure.
Using Validation
================
In FormEncode validation and conversion happen simultaneously.
Frequently you cannot convert a value without ensuring its validity,
-and validation problems can occur in the middle of conversion. In
-many ways, this is meant as a general encoding/decoding system (which
-is where the "Encode" in "FormEncode" comes from).
+and validation problems can occur in the middle of conversion.
-The basic metaphor for validation is *to_python* and *from_python*.
-In this context "Python" is meant to refer to "here" -- the trusted
-application, your own Python objects. The "other" may be a web form,
-an external database, an XML-RPC request, or any data source that is
-not completely trusted or does not map directly to Python's object
-model. *to_python* is the process of taking external data and
-preparing it for internal use, *from_python* generally reverses this
-process (*from_python* is usually the less interesting of the pair,
-but provides some important features).
+The basic metaphor for validation is **to_python** and
+**from_python**. In this context "Python" is meant to refer to "here"
+-- the trusted application, your own Python objects. The "other" may
+be a web form, an external database, an XML-RPC request, or any data
+source that is not completely trusted or does not map directly to
+Python's object model. ``to_python`` is the process of taking
+external data and preparing it for internal use, ``from_python``
+generally reverses this process (``from_python`` is usually the less
+interesting of the pair, but provides some important features).
The core of this validation process is two methods and an exception::
@@ -98,7 +98,7 @@
'bo...@no...'
``Invalid`` exceptions generally give a good, user-readable error
-message about the invalidity of the input. Using the exception gets
+message about the problem with the input. Using the exception gets
more complicated when you use compound data structures (dictionaries
and lists), which we'll talk about later__.
@@ -120,12 +120,12 @@
For instance, imagine a registration form for a website. It takes the
following fields, with restrictions:
-* first_name (not empty)
-* last_name (not empty)
-* email (not empty, valid email)
-* username (not empty, unique)
-* password (reasonably secure)
-* password_confirm (matches password)
+* ``first_name`` (not empty)
+* ``last_name`` (not empty)
+* ``email`` (not empty, valid email)
+* ``username`` (not empty, unique)
+* ``password`` (reasonably secure)
+* ``password_confirm`` (matches password)
There's a couple validators that aren't part of FormEncode, because
they'll be specific to your application::
@@ -140,10 +140,19 @@
... value, state)
... return value
-This overrides ``_to_python`` -- ``formencode.FancyValidator`` adds a
+.. note::
+ `formencode.FancyValidator
+ <class-formencode.api.FancyValidator.html>`_ is the superclass for
+ most validators in FormEncode, and it provides a number of useful
+ features that most validators can use -- for instance, you can pass
+ ``strip=True`` into any of these validators, and they'll strip
+ whitespace from the incoming value before any other validation.
+
+This overrides ``_to_python``: ``formencode.FancyValidator`` adds a
number of extra features, and then calls the private ``_to_python``
-method that you typically write. When if finds an error it raises an
-exception (``formencode.Invalid``), with the error message and the
+method, which is the method you'll typically write. When a validator
+finds an error it raises an exception (`formencode.Invalid
+<class-formencode.api.Invalid.html>`_), with the error message and the
value and "state" objects. We'll talk about state_ later. Here's the
other custom validator, that checks passwords against words in the
standard Unix word file::
@@ -176,20 +185,24 @@
Like any other validator, a ``Registration`` instance will have the
``to_python`` and ``from_python`` methods. The input should be a
dictionary, with keys like ``"first_name"``, ``"password"``, etc. The
-validators will be applied to each of the values of the dictionary.
-*All* the values will be validated, so if there are multiple invalid
-fields you will get information about all of them.
+validators you give as attributes will be applied to each of the
+values of the dictionary. *All* the values will be validated, so if
+there are multiple invalid fields you will get information about all
+of them.
Most validators (anything that subclasses
``formencode.FancyValidator``) will take a certain standard set of
-constructor keyword arguments. See FancyValidator_ for more -- here
-we use ``not_empty=True``.
+constructor keyword arguments. See `FancyValidator
+<class-formencode.api.FancyValidator.html>`_ for more -- here we use
+``not_empty=True``.
-Another notable one is ``All`` -- this is a *compound validator* --
-that is, it's a validator that takes validators as input. Schemas are
-one example; ``All`` takes a list of validators and applies each of
-them in turn. ``Any`` is its compliment, that uses the first passing
-validator in its list.
+Another notable validator is `All
+<class-formencode.compound.All.html>`_ -- this is a *compound
+validator* -- that is, it's a validator that takes validators as
+input. Schemas are one example; in this case ``All`` takes a list of
+validators and applies each of them in turn. `Any
+<class-formencode.compound.Any.html>`_ is its compliment, that uses
+the first passing validator in its list.
.. _pre_validators:
.. _chained_validators:
@@ -197,21 +210,23 @@
``chained_validators`` are validators that are run on the entire
dictionary after other validation is done (``pre_validators`` are
applied before the schema validation). You could actually achieve the
-same thing by using ``All`` with the schema validators
-(``FieldsMatch`` is just another validator that can be applied to
-dictionaries). In this case ``validators.FieldsMatch`` checks that
-the value of the two fields are the same (i.e., that the password
-matches the confirmation).
+same thing by using ``All`` with the schema validators (`FieldsMatch
+<class-formencode.validators.FieldsMatch.html>`_ is just another
+validator that can be applied to dictionaries). In this case
+``validators.FieldsMatch`` checks that the value of the two fields are
+the same (i.e., that the password matches the confirmation).
-Since a Schema is just another kind of validator, you can nest these
-indefinitely, validating dictionaries of dictionaries.
+Since a `Schema <class-formencode.schema.Schema.html>`_ is just
+another kind of validator, you can nest these indefinitely, validating
+dictionaries of dictionaries.
.. _ForEach:
-You can also validate lists of items using ``ForEach``. For example,
-let's say we have a form where someone can edit a list of book
-titles. Each title has an associated book ID, so we can match up the
-new title and the book it is for::
+You can also validate lists of items using `ForEach
+<class-formencode.foreach.ForEach.html>`_. For example, let's say we
+have a form where someone can edit a list of book titles. Each title
+has an associated book ID, so we can match up the new title and the
+book it is for::
>>> class BookSchema(formencode.Schema):
... id = validators.Int()
@@ -232,7 +247,8 @@
We gave a brief introduction to creating a validator earlier
(``UniqueUsername`` and ``SecurePassword``). We'll discuss that a
-little more. Here's another implementation of ``SecurePassword``:
+little more. Here's a more complete implementation of
+``SecurePassword``::
>>> import re
>>> class SecurePassword(validators.FancyValidator):
@@ -270,7 +286,7 @@
a minimum-five-character validator. This makes it easy to also
subclass other validators, giving different default values.
-Unlike the previous implementation we use ``validator_python`` (which
+Unlike the previous implementation we use ``validate_python`` (which
is another method ``FancyValidator`` allows us to use).
``validate_python`` doesn't have any return value, it simply raises an
exception if it needs to. It validates the value *after* it has been
@@ -308,30 +324,35 @@
.. _FancyValidator:
There are several options that most validators support (including your
-own validators, if you subclass from ``FancyValidator``):
+own validators, if you subclass from `FancyValidator
+<class-formencode.api.FancyValidator.html>`_):
``if_empty``:
- If set, then this value will be returned if the input evaluates
- to false (empty list, empty string, None, etc), but not the 0 or
- False objects. This only applies to ``.to_python()``.
+ If set, then this value will be returned if the input evaluates
+ to false (empty list, empty string, None, etc), but not the 0 or
+ False objects. This only applies to ``.to_python()``.
``not_empty``:
- If true, then if an empty value is given raise an error.
- (Both with ``.to_python()`` and also ``.from_python()``
- if ``.validate_python`` is true).
+ If true, then if an empty value is given raise an error.
+ (Both with ``.to_python()`` and also ``.from_python()``
+ if ``.validate_python`` is true).
+``strip``:
+ If true and the input is a string, strip it (occurs before empty
+ tests).
+
``if_invalid``:
- If set, then when this validator would raise Invalid during
- ``.to_python()``, instead return this value.
+ If set, then when this validator would raise Invalid during
+ ``.to_python()``, instead return this value.
``if_invalid_python``:
- If set, when the Python value (converted with
- ``.from_python()``) is invalid, this value will be returned.
+ If set, when the Python value (converted with
+ ``.from_python()``) is invalid, this value will be returned.
-``validate_python``:
- If False (default True), then ``.validate_python()`` and
- ``.validate_other()`` will not be called when
- ``.from_python()`` is used.
+``accept_python``:
+ If True (the default), then ``.validate_python()`` and
+ ``.validate_other()`` will not be called when
+ ``.from_python()`` is used.
State
-----
@@ -349,39 +370,49 @@
just put it in the state object as an attribute, then look for that
attribute in your validator.
-Also, during compound validation (a ``Schema`` or ``ForEach``) the
-state (if not None) will have more instance variables added to it.
-During a ``Schema`` (dictionary) validation the instance variable
-``key`` and ``full_dict`` will be added -- ``key`` is the current key
-(i.e., validator name), and ``full_dict`` is the rest of the values
-being validated. During a ``ForEeach`` (list) validation, ``index``
-and ``full_list`` will be set.
+Also, during compound validation (a `Schema
+<class-formencode.schema.Schema.html>`_ or `ForEach
+<class-formencode.foreach.ForEach.html>`_) the state (if not None)
+will have more instance variables added to it. During a ``Schema``
+(dictionary) validation the instance variable ``key`` and
+``full_dict`` will be added -- ``key`` is the current key (i.e.,
+validator name), and ``full_dict`` is the rest of the values being
+validated. During a ``ForEeach`` (list) validation, ``index`` and
+``full_list`` will be set.
Invalid Exceptions
------------------
-Besides the string error message, ``Invalid`` exceptions have a few
-other instance variables:
+Besides the string error message, `Invalid
+<class-formencode.api.Invalid.html>`_ exceptions have a few other
+instance variables:
-value:
+``value``:
The input to the validator that failed.
-state:
+
+``state``:
The associated state_.
-msg:
+
+``msg``:
The error message (``str(exc)`` returns this)
-error_list:
+
+``error_list``:
If the exception happened in a ``ForEach`` (list) validator, then
this will contain a list of ``Invalid`` exceptions. Each item
from the list will have an entry, either None for no error, or an
exception.
-error_dict:
+
+``error_dict``:
If the exception happened in a ``Schema`` (dictionary) validator,
then this will contain ``Invalid`` exceptions for each failing
field. Passing fields not be included in this dictionary.
-.unpack_errors():
+
+``.unpack_errors()``:
This method returns a set of lists and dictionaries containing
strings, for each error. It's an unpacking of ``error_list``,
- ``error_dict`` and ``msg``.
+ ``error_dict`` and ``msg``. If you get an Invalid exception from
+ a ``Schema``, you probably want to call this method on the
+ exception object.
.. _Messages:
@@ -389,11 +420,11 @@
--------------------------------
All of the error messages can be customized. Each error message has a
-key associated with it, like ``"too_few"`` in the registration example.
-You can overwrite these messages by using you own ``messages = {"key":
-"text"}`` in the class statement, or as an argument when you call a
-class. Either way, you do not lose messages that you do not define,
-you only overwrite ones that you specify.
+key associated with it, like ``"too_few"`` in the registration
+example. You can overwrite these messages by using you own ``messages
+= {"key": "text"}`` in the class statement, or as an argument when you
+call a class. Either way, you do not lose messages that you do not
+define, you only overwrite ones that you specify.
Messages often take arguments, like the number of characters, the
invalid portion of the field, etc. These are always substituted as a
@@ -415,13 +446,15 @@
HTTP/HTML Form Input
--------------------
-The validation expects nested data structures; specifically Schema and
-ForEach deal with these structures well. HTML forms, however, do not
-produce nested structures -- they produce flat structures with keys
-(input names) and associated values.
+The validation expects nested data structures; specifically `Schema
+<class-formencode.schema.Schema.html>`_ and `ForEach
+<class-formencode.foreach.ForEach.html>`_ deal with these structures
+well. HTML forms, however, do not produce nested structures -- they
+produce flat structures with keys (input names) and associated values.
-Validator includes the module ``variabledecode``, which allows you to
-encode nested dictionary and list structures into a flat dictionary.
+Validator includes the module `variabledecode
+<module-formencode.variabledecode.html>`, which allows you to encode
+nested dictionary and list structures into a flat dictionary.
To do this it uses keys with ``"."`` for nested dictionaries, and
``"-int"`` for (ordered) lists. So something like:
@@ -462,9 +495,10 @@
with ``'-int'``, where they are ordered by the integer (the integers
are used for sorting, missing numbers in a sequence are ignored).
-``NestedVariables`` is a validator that decodes and encodes
-dictionaries using this algorithm. You can use it with a Schema's
-`pre_validators`_ attribute.
+`NestedVariables
+<class-formencode.variabledecode.NestedVariables.html>`_ is a
+validator that decodes and encodes dictionaries using this algorithm.
+You can use it with a Schema's `pre_validators`_ attribute.
Of course, in the example we use the data is rather eclectic -- for
instance, Tim Smith doesn't have his name separated into first and
Modified: FormEncode/trunk/docs/history.txt
===================================================================
--- FormEncode/trunk/docs/history.txt 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/docs/history.txt 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,16 +1,18 @@
On Intentions And History
=========================
+:author: Ian Bicking
+
I'm the author of FunFormKit_, a form generation and validation
-package for Webware_. I consider FunFormKit (FFK) to be a very
+package for Webware_. I considered FunFormKit (FFK) to be a very
powerful and complete package, with features that few other form
-validation packages for Python have (as to other languages, I haven't
-researched enough to know). It supports repeating and compound fields
-(which most packages do not), and has a very expressive validation
-system.
+validation packages for Python had (as to other languages, I haven't
+researched enough to know). It supported repeating and compound
+fields (which most packages do not), and had a very expressive
+validation system.
-However, this is not FFK. In fact, it signals a deprecation of FFK
-and does not provide backward compatibility. Why?
+However, this is not FFK. In fact, it is a deprecation of FFK and
+does not provide backward compatibility. Why?
Probably the biggest problem was that FFK didn't support compound
and repeating fields. Adding them made everything *much* more
@@ -20,10 +22,8 @@
Ontop of this was a structure that had too much coupling. Testing was
difficult. I only came to like unit testing after FFK had gone
-through several revisions (and I won't claim to be an addict or
-sufficiently disciplined about unit testing, but at least I'm better
-at it now). FFK was not made with testability in mind. It's hard to
-add later.
+through several revisions. FFK was not made with testability in mind.
+It can be hard to add later.
Also, I wanted to use pieces of FFK without the entire framework.
Validation without the form generation was the biggest one. Alternate
Modified: FormEncode/trunk/docs/htmlfill.txt
===================================================================
--- FormEncode/trunk/docs/htmlfill.txt 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/docs/htmlfill.txt 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,10 +1,6 @@
.. comment (set Emacs mode) -*- doctest -*-
- >>> import sys
- >>> try:
- ... import formencode
- ... except ImportError:
- ... sys.path.append('/usr/home/ianb/colorstudy.com/FormEncode/trunk')
+ >>> import formencode
++++++++
htmlfill
@@ -19,16 +15,12 @@
Introduction
============
-`htmlfill` is a library to fill out forms, both with default values
-and error messages. It's like a template library, but more limited,
-and it can be used with the output from other templates.
+`htmlfill <module-formencode.htmlfill.html>`_ is a library to fill out
+forms, both with default values and error messages. It's like a
+template library, but more limited, and it can be used with the output
+from other templates. It has no prerequesites, and can be used
+without any other parts of FormEncode.
-Prerequisites
--------------
-
-None. I believe it should be Python 2.1 compatible, but I haven't
-tried. If not, that could be easily resolved.
-
Usage
=====
@@ -37,12 +29,8 @@
>>> from formencode import htmlfill
>>> form = '<input type="text" name="fname">'
>>> defaults = {'fname': 'Joe'}
- >>> parser = htmlfill.FillingParser(defaults)
- >>> parser.feed(form)
- >>> parser.close()
- >>> parser.text()
+ >>> htmlfill.render(form, defaults)
'<input type="text" name="fname" value="Joe">'
- >>> parser.close()
The parser looks for HTML input elements (including ``select`` and
``textarea``) and fills in the defaults. The quintessential way to
@@ -50,25 +38,9 @@
return the form to the user with the values they entered, in addition
to errors.
-The parser takes several optional arguments:
+See `formencode.htmlfill.render for more
+<module-formencode.htmlfill.html#render>`_ for more.
-``errors`` (default ``{}``):
- A dictionary of errors to display (see Errors_)
-``use_all_keys`` (default ``False``):
- If true, if defaults contain a key that isn't used by the form an
- error will be raised when ``.close()`` is called.
-``error_class`` (default ``"error"``):
- If a input field has an error in the ``errors`` dictionary, then
- it will have this class added. Note that elements may have
- multiple classes, so this won't remove any class that the element
- already had. You can use this to color invalid fields.
-``error_formatters``:
- This is a dictionary of formatters for errors. See Errors_.
-``add_attributes``:
- This is a dictionary of dictionaries. E.g., ``{'submit':
- {'value': 'Add'}}`` could be used to change the ``value``
- attributes of the submit button.
-
Errors
------
@@ -91,17 +63,21 @@
<span class="error-message">(message)</span><br>
+In addition to explicit error tags, any leftover errors will be placed
+immediately above the associated input field.
+
Valid form templates
--------------------
-When you call ``parser.close()`` the parser will check that you've
-fully used all the defaults and errors that were given in the
-constructor. If not, an ``AssertionError`` will be raised.
+When you call ``parser.close()`` (also called by ``render()``) the
+parser will check that you've fully used all the defaults and errors
+that were given in the constructor if you pass in
+``use_all_keys=True``. If there are leftover fields an
+``AssertionError`` will be raised.
In most cases, htmlfill tries to keep the template the way it found
it, without reformatting it too much. If HTMLParser_ chokes on the
-code, so will htmlfill. Whitespace is being mucked up some right now,
-but I'm not sure why; it's not intentional.
+code, so will htmlfill.
.. _HTMLParser: http://python.org/doc/current/lib/module-HTMLParser.html
Modified: FormEncode/trunk/docs/index.txt
===================================================================
--- FormEncode/trunk/docs/index.txt 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/docs/index.txt 2005-11-20 22:05:46 UTC (rev 1306)
@@ -33,6 +33,7 @@
* `Subway <http://subway.python-hosting.com>`_
* `TurboGears <http://turbogears.org>`_
* `Pylons <http://pylons.groovie.org>`_
+* More? `Email me <ia...@co...>`_
.. image:: http://sourceforge.net/sflogo.php?group_id=91231&type=4
:height: 37
Modified: FormEncode/trunk/docs/news.txt
===================================================================
--- FormEncode/trunk/docs/news.txt 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/docs/news.txt 2005-11-20 22:05:46 UTC (rev 1306)
@@ -4,6 +4,12 @@
SVN trunk
---------
+* Fixed up all the documentation.
+
+* Validator ``__doc__`` attributes will include some
+ automatically-appended information about all the message strings
+ that validator uses.
+
* Deprecated ``formencode.htmlform`` module, because it is dumb.
* Added an ``.all_messages()`` method to all validators, primarily
Modified: FormEncode/trunk/formencode/api.py
===================================================================
--- FormEncode/trunk/formencode/api.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/api.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,4 +1,10 @@
+"""
+Core classes for validation.
+"""
+
import declarative
+import textwrap
+import re
__all__ = ['NoDefault', 'Invalid', 'Validator', 'Identity',
'FancyValidator', 'is_validator']
@@ -106,6 +112,7 @@
cls._messages = cls._messages.copy()
cls._messages.update(cls.messages)
del cls.messages
+ cls._initialize_docstring()
def __init__(self, *args, **kw):
if kw.has_key('messages'):
@@ -166,6 +173,24 @@
"""
return []
+ #@classmethod
+ def _initialize_docstring(cls):
+ """
+ This changes the class's docstring to include information
+ about all the messages this validator uses.
+ """
+ doc = cls.__doc__ or ''
+ doc = [textwrap.dedent(doc).rstrip()]
+ messages = cls._messages.items()
+ messages.sort()
+ doc.append('\n\n**Messages**\n\n')
+ for name, default in messages:
+ default = re.sub(r'(%\(.*?\)[rsifcx])', r'``\1``', default)
+ doc.append('``'+name+'``:\n')
+ doc.append(' '+default+'\n\n')
+ cls.__doc__ = ''.join(doc)
+ _initialize_docstring = classmethod(_initialize_docstring)
+
class _Identity(Validator):
def __repr__(self):
return 'validators.Identity'
Modified: FormEncode/trunk/formencode/compound.py
===================================================================
--- FormEncode/trunk/formencode/compound.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/compound.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,3 +1,7 @@
+"""
+Validators for applying validations in sequence.
+"""
+
from api import *
# @@ ianb 2005-05: should CompoundValidator be included?
Deleted: FormEncode/trunk/formencode/conftest.py
===================================================================
--- FormEncode/trunk/formencode/conftest.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/conftest.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,2 +0,0 @@
-import sys, os
-sys.path.append(os.path.dirname(os.path.dirname(__file__)))
Modified: FormEncode/trunk/formencode/foreach.py
===================================================================
--- FormEncode/trunk/formencode/foreach.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/foreach.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,3 +1,7 @@
+"""
+Validator for repeating items.
+"""
+
from api import NoDefault, Invalid
from compound import CompoundValidator, to_python, from_python
try:
Modified: FormEncode/trunk/formencode/formgen.py
===================================================================
--- FormEncode/trunk/formencode/formgen.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/formgen.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,3 +1,7 @@
+"""
+Experimental extensible form generation
+"""
+
# @@: This is experimental
import fields
Modified: FormEncode/trunk/formencode/htmlform.py
===================================================================
--- FormEncode/trunk/formencode/htmlform.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/htmlform.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,11 +1,10 @@
"""
-.. note::
+Class to encapsulate an HTML form, using htmlfill and
+htmlfill_schemabuilder (deprecated).
+.. note::
This is deprecated, as it's not that helpful.
-Class to encapsulate an HTML form, using htmlfill and
-htmlfill_schemabuilder
-
Usage::
html = '<form action=...>...</form>'
Modified: FormEncode/trunk/formencode/interfaces.py
===================================================================
--- FormEncode/trunk/formencode/interfaces.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/interfaces.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,5 +1,5 @@
"""
-Interfaces for FormEncode
+Interfaces for FormEncode (for documentation purposes only)
"""
class Attribute(object):
Modified: FormEncode/trunk/formencode/validators.py
===================================================================
--- FormEncode/trunk/formencode/validators.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/validators.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -457,7 +457,7 @@
'ABC'
Note that ``.from_python()`` calls (in general) do not validate
- the input:
+ the input::
>>> cap.from_python('abc')
'abc'
@@ -2050,6 +2050,8 @@
You must check the expiration date yourself (there is no
relation between CC number/types and expiration dates).
+ ::
+
>>> cc = CreditCardValidator()
>>> cc.to_python({'ccType': 'visa', 'ccNumber': '4111111111111111'})
{'ccNumber': '4111111111111111', 'ccType': 'visa'}
@@ -2157,3 +2159,8 @@
('1800', 15)],
}
+__all__ = []
+for name, value in globals().items():
+ if isinstance(value, type) and issubclass(value, Validator):
+ __all__.append(name)
+
Modified: FormEncode/trunk/formencode/variabledecode.py
===================================================================
--- FormEncode/trunk/formencode/variabledecode.py 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/formencode/variabledecode.py 2005-11-20 22:05:46 UTC (rev 1306)
@@ -1,10 +1,7 @@
"""
-VariableDecode.py
-Ian Bicking <ia...@co...>
+Takes GET/POST variable dictionary, as might be returned by ``cgi``,
+and turns them into lists and dictionaries.
-Takes GET/POST variable dictionary, as might be returned by
-`cgi`, and turns them into lists and dictionaries.
-
Keys (variable names) can have subkeys, with a ``.`` and
can be numbered with ``-``, like ``a.b-3=something`` means that
the value ``a`` is a dictionary with a key ``b``, and ``b``
Modified: FormEncode/trunk/setup.cfg
===================================================================
--- FormEncode/trunk/setup.cfg 2005-11-20 20:18:46 UTC (rev 1305)
+++ FormEncode/trunk/setup.cfg 2005-11-20 22:05:46 UTC (rev 1306)
@@ -10,6 +10,7 @@
docs = docs/index.txt docs/Validator.txt docs/ToDo.txt
docs/news.txt docs/htmlfill.txt docs/Design.txt
docs/community.txt docs/download.txt
+ docs/history.txt
doc_base = docs/
dest = docs/html
modules = formencode
|