在我研究基于课堂观点的新django文档时,我注意到this example code:
# forms.py
from django import forms
class ContactForm(forms.Form):
name = forms.CharField()
message = forms.CharField(widget=forms.Textarea)
def send_email(self):
# send email using the self.cleaned_data dictionary
pass
将send_email
视为ContactForm
方法的事实让我感到很恼火。我一直认为表单方法应该用于验证目的,使用表单的方法(在本例中为send_email
)应该在 views层中。我在这里错过了什么吗?或者应该更正这个例子?
答案 0 :(得分:4)
这个没有正确的答案。这真的取决于你的编码风格。使用表单不仅仅是验证与在视图中执行此方法一样有效。
上面的例子虽然有一些优点。假设您有一个模型,并且您希望使用不同的形式(具有不同的逻辑)。而不是将逻辑放在视图中并检查现在使用哪个表单,最好将此逻辑放在表单级别上。
答案 1 :(得分:1)
这个例子没有错。除了最简单的情况外,您的表格仅包含清洁方法;大多数表单都进行额外验证和其他操作。最后,它只是一个Python类,你可以做任何你想做的事情;除了DRY之外没有“规则”。
我们有表单方法,可以验证外部服务,调用其他过程并触发工作流程。对于这种复杂的逻辑,最好将其嵌入到表单类中,因为它增加了代码的可重用性。处理视图的开发人员只需将表单类用作库,而不必担心异乎寻常的验证要求。在这种情况下,它实际上促进了DRY。
当我们必须更新逻辑时,我们只更新表单类的“私有”方法(前缀为_
的方法)。这使得“公共”界面(由django记录)保持完整,并且不必更新使用该表单的所有视图代码。
答案 2 :(得分:1)
我第一次遇到同样奇怪的感觉是当我遇到来自LoginForm
的{{1}}时,除了管理传入的凭据之外,还验证用户的浏览器是capable of working with cookies。 / p>
就个人而言,我同意你的看法。我更倾向于认为视图应该是执行发送电子邮件而不是表单的操作的负责人,并且django.contrib.auth
应该是视图中定义的方法。
但是,再一次,你可以很容易地观察到我们很多人如何使用不同的Django或者采用不同的方法来解决相同的问题。由于我们在开发应用程序时考虑到了不同的问题,因此我们很可能对如何使用某些框架组件有不同的理解,这有点没有实际意义。最后,重要的是要承认,有可能以一种定义明确的方式将视图中的一些繁重任务委托给表单。