Django的HTML表单类中一些神奇的怪异现象

在Django中，HTML表单的定义似乎是传统的方法；每个表单是一个Python类，字段是类定义中的变量。这看起来像这样，从我们的Django网络应用程序 中提取一个骨架。

class RequestForm(forms.Form):
  login = forms.CharField([...])
  name  = forms.CharField([...])
  email = forms.EmailField([...])
  aup_agree = forms.BooleanField([...])

你用初始数据（当你第一次显示表单时）或者用来自POST 或GET 表单的数据来实例化一个RequestForm 的实例，然后在上面调用各种标准的 Django API 函数，如此反复。这在Django文档中都有涉及。

直到现在我才想起，我们写出来的这个Python类的定义有点像一个谎言。Django模型类的工作原理和它们的外观一样，例如Request的模型版本有一个Request.login 属性，就像它的类定义那样。而表单则明显不同，虽然我们在这里设置了看起来像类的属性，但我们实际的RequestForm 类和类的实例并没有，比如说，RequestForm.login 属性。我们在这里定义的所有表单字段都会被卷走，放在 Form.fields.

从某种程度上说，这是有记录的，而且可能是最安全的选择，因为数据最终来自一个不受信任的来源（即HTTP请求）。这也意味着你基本上不会意外地将表单实例用作模型实例（例如，通过将错误的东西传递给某些函数）；如果你尝试，它将会出现属性错误。

("大部分 "是因为你可以在RequestForm实例上创建一个login 属性，如果你写到它，所以如果一个写到模型实例字段的函数意外地交给一个表单实例，它可能至少有一半的工作。)

在另一个层面上，这也是Django 的类非 Python 魔法的 另一种方式。 看起来像类属性的东西甚至不是属性；它们只是消失了。传统的Python知识在处理Django时并不像它看起来那样有用，你必须了解API（或查找它），甚至对于那些看起来应该是基本和直接的东西。

(对于这里的权衡是否值得，我已经没有什么看法了）。我们的Django应用只是在工作，这才是我们真正关心的事情）。