今天分享的这个案例跟性能无关,是属于一个业务架构设计方面的。可能对少数用户会有参考作用。
在我们的业务系统中,有些动作为了避免误操作,经常会需要有二次确认的提示对话框。常用见的是删除记录的时候,会有提示,要你再次确认删除才会真正执行。像我们系统中就会有很多这种二次确认的提示,像取消单据、重置单据、锁定单据等。
按照平常的开发思路,这种提示框是通过向导来完成的,定义一个向导的模型,然后定义一个字段用来显示文字内容,再定义一个方法来执行确认按钮的执行。
class Dlg(models.TransientModel):_name = "base.wizard.confirm"_description = "操作确认向导"help_text = fields.Char("提示",size=200)@api.multidef action_ok(self):#这里写确认时执行的业务代码
这种方法比较死板,有多少种二次确认的情况,就需要定义多少个向导,增加了开发量,但代码又都是复制、粘贴,开发人员除了机械运动,没有多少成就感。为了减化这个开发工作,我们可以把相同的业务剥离、抽象出来,把变化的业务通过参数的方式来传递。得益于在python中,函数也可以作为参数这个功能,我们把二次确认的功能做了一个新的设计:
class Dlg(models.TransientModel):_name = "base.wizard.confirm"_description = "操作确认向导"help_text = fields.Char(u"提示",size=200)@api.multidef action_ok(self):obj = self._context["src_model"]method = self._context["src_method"]getattr(self.env[obj].browse(self._context["active_ids"]),method)()@api.modeldef msg(self,src_model,src_method,ids,help_text):res = self.create({"help_text": help_text})return {'name': "确认执行此操作吗?",'res_id': res.id,'view_type': 'form','res_model': self._name,'view_id': False,'target': 'new','context': {'active_ids': ids,'src_model':src_model,'src_method':src_method},'type': 'ir.actions.act_window',}
这样,所有二次确认的业务都可以共用这一个数据模型。这里加了一个msg方法,给其它业务需要二次确认的时候调用。
这样点击确认按钮执行什么业务逻辑,由你传入的参数所决定。这个向导只是一个中间衔接的作用。如:
@api.multidef action_confirm_state_cancel(self):return self.env["base.wizard.confirm"].msg(self._name, "action_state_cancel", self.id,"确认需要取消该样本检测吗?")@api.multidef action_state_cancel(self):self.write({"state": "cancel"})
在操作界面上,用户点取消,执行action_confirm_state_cancel,弹出向导窗体,在向导界面上按确认按钮,执行传入的参数action_state_cancel方法。
这样要扩充其它业务模型的二次确认操作就很简单了。
文章转载自Odoo哥,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




