Which option is best, 1 or 2?
哪个选项最好,1还是2?
1.
class TopicForm(forms.Form):
name = forms.CharField(required=True)
body = RichTextFormField(required=True)
def save(self, request):
t = models.Topic(user=request.user,
site=get_current_site(request),
name=self.cleaned_data['name'],
body=self.cleaned_data['body'])
t.slug = slugify(self.name)
t.body_html = seo.nofollow(seo.noindex(self.body))
t.ip = utils.get_client_ip(request)
t.save()
or 2.
class Topic(models.Model):
...
def save(self, *args, **kwargs):
self.slug = slugify(self.name)
self.body_html = seo.nofollow(seo.noindex(self.body))
self.ip = utils.get_client_ip(request)
super(Topic, self).save(*args, **kwargs)
4 个解决方案
#1
4
The difference is that the first version is only applied when modifying objects through the form, while the second is applied whenever the model is saved (though that is still a subset of all the ways in which database rows can be modified in Django). Even if you currently only create objects through forms, I think it's still a useful distinction to keep in mind.
不同之处在于第一个版本仅在通过表单修改对象时应用,而第二个版本仅在保存模型时应用(尽管这仍然是Django中可以修改数据库行的所有方式的子集)。即使您目前只通过表单创建对象,我认为记住它仍然是一个有用的区别。
It looks to me like a mixture of the two makes sense in your case. A slug
is something that you will always want to set based on name
- that is, it's inherent to the model itself. On the other hand, the idea of a client_ip
seems inexorably tied to the notion of creating an object with a form via a web request.
在我看来,两者的混合物在你的情况下是有意义的。 slu is是你总是想根据名字设置的东西 - 也就是说,它是模型本身所固有的。另一方面,client_ip的想法似乎无情地与通过Web请求创建具有表单的对象的概念联系在一起。
Of course, you are in a better position to know about the specifics of this model, but that is the general way I would approach the question.
当然,你可以更好地了解这个模型的具体细节,但这是我接近这个问题的一般方法。
#2
0
It depends. If this should be applied to every models, then it is better in the model. It will assure you that every Topic
object will have correct values, even those you are edited from the admin interface.
这取决于。如果这应该应用于每个模型,那么它在模型中更好。它将向您保证每个Topic对象都具有正确的值,即使是从管理界面编辑的值也是如此。
The form should be use only to check data from the user and the model is appropriate to automatize this kind of task (generate data before saving the object). Be careful, this shouldn't raise Exception or invalidate data however.
该表单应仅用于检查来自用户的数据,并且该模型适合于自动化此类任务(在保存对象之前生成数据)。请注意,这不应该引发异常或使数据无效。
#3
0
Personally I would prefer the second option. The model should define the business logic too, while forms should just handle user I/O. This way your application will keep consistent even if used in a programmatic way (imported and called from other code).
我个人更喜欢第二种选择。模型也应该定义业务逻辑,而表单应该只处理用户I / O.这样,即使以编程方式使用(从其他代码导入和调用),您的应用程序也将保持一致。
#4
0
You shouldnt use 2. its better to use a signal like pre-save or post-save
你不应该使用2.它更好地使用像预存或后保存的信号
Source: https://docs.djangoproject.com/en/dev/topics/signals/
@receiver(pre_save, sender=Topic)
def topic_pre_save_handler(sender, instance, **kwargs):
instance.slug = slugify(self.name)
instance.body_html = seo.nofollow(seo.noindex(self.body))
instance.ip = utils.get_client_ip(request)
#1
4
The difference is that the first version is only applied when modifying objects through the form, while the second is applied whenever the model is saved (though that is still a subset of all the ways in which database rows can be modified in Django). Even if you currently only create objects through forms, I think it's still a useful distinction to keep in mind.
不同之处在于第一个版本仅在通过表单修改对象时应用,而第二个版本仅在保存模型时应用(尽管这仍然是Django中可以修改数据库行的所有方式的子集)。即使您目前只通过表单创建对象,我认为记住它仍然是一个有用的区别。
It looks to me like a mixture of the two makes sense in your case. A slug
is something that you will always want to set based on name
- that is, it's inherent to the model itself. On the other hand, the idea of a client_ip
seems inexorably tied to the notion of creating an object with a form via a web request.
在我看来,两者的混合物在你的情况下是有意义的。 slu is是你总是想根据名字设置的东西 - 也就是说,它是模型本身所固有的。另一方面,client_ip的想法似乎无情地与通过Web请求创建具有表单的对象的概念联系在一起。
Of course, you are in a better position to know about the specifics of this model, but that is the general way I would approach the question.
当然,你可以更好地了解这个模型的具体细节,但这是我接近这个问题的一般方法。
#2
0
It depends. If this should be applied to every models, then it is better in the model. It will assure you that every Topic
object will have correct values, even those you are edited from the admin interface.
这取决于。如果这应该应用于每个模型,那么它在模型中更好。它将向您保证每个Topic对象都具有正确的值,即使是从管理界面编辑的值也是如此。
The form should be use only to check data from the user and the model is appropriate to automatize this kind of task (generate data before saving the object). Be careful, this shouldn't raise Exception or invalidate data however.
该表单应仅用于检查来自用户的数据,并且该模型适合于自动化此类任务(在保存对象之前生成数据)。请注意,这不应该引发异常或使数据无效。
#3
0
Personally I would prefer the second option. The model should define the business logic too, while forms should just handle user I/O. This way your application will keep consistent even if used in a programmatic way (imported and called from other code).
我个人更喜欢第二种选择。模型也应该定义业务逻辑,而表单应该只处理用户I / O.这样,即使以编程方式使用(从其他代码导入和调用),您的应用程序也将保持一致。
#4
0
You shouldnt use 2. its better to use a signal like pre-save or post-save
你不应该使用2.它更好地使用像预存或后保存的信号
Source: https://docs.djangoproject.com/en/dev/topics/signals/
@receiver(pre_save, sender=Topic)
def topic_pre_save_handler(sender, instance, **kwargs):
instance.slug = slugify(self.name)
instance.body_html = seo.nofollow(seo.noindex(self.body))
instance.ip = utils.get_client_ip(request)