协作框架--低成本而可靠的实现功能扩展
协作框架–低成本而可靠的实现功能扩展
在【申请预算】一文中，笔者指出申请的重要性，而随着管理的细化，为了提高作业效率，那可能就会有各种申请要被定制出来。那么新增加的申请能否简单一致且低成本的、可靠的融入到现有的管理体系中呢？！
这就要求提供一种便于低成本、快速扩展的机制来应对新增的申请类型，以及其它类似的问题。
针对此种需求，jxTMS提供了一种称为框架法的跨capa协作机制来解决实现低成本、可靠的功能扩展。
首先，此类问题本质上都是跨模块【在jxTMS中是capa】的协作。
其次，有一个主capa实现主体功能，如申请功能中，需实现主要的申请界面、提供基本的申请工作流、提供支撑性功能【如同意、拒绝、转某人、打回做补充说明等】、提供必要的辅助功能【如日志、现场数据保存、历史快照回播等】。
然后，主capa依据上述主体功能，设置预定的互操作点，然后根据主体功能的行为逻辑，为各个互操作点定义接口。
最后，需要扩展的子capa，只需要：
-
根据本扩展所要实现的功能特点，来一一具体的实现这些接口
-
并注册到主capa中
就简便而可靠的完成了功能扩展。
根据上述认识，jxTMS提供了称之为【框架法】的功能扩展机制。
协作框架的行为逻辑
协作框架本质上就是两个capa之间的互操作。其中实现基础功能的叫做主capa，增加扩展能力的叫做子capa。
主capa实现基础功能，包括web主界面和一整套行为逻辑。然后：
1、在web界面中，为子capa的扩展保留一个空白的div。如申请的web界面定义中：
//框架中显示细节
web viewOtherApproveBrief parent approveBrief type div;
其中的approveBrief就是主capa为查看申请而设计的web界面，在approveBrief中为调用子capa所扩展的自己的专用界面而预留一个viewOtherApproveBrief的div。各子capa自己扩展的界面全部都显示在其中。
2、在整套的行为逻辑中，为回调子capa保留接口，并约定语义。如创建申请的行为逻辑是：
其中为调用子capa约定了两个接口：一个是显示界面时的viewApprove操作，一个是提交申请时的approveActive->newApprove操作。后者会进一步细分是因为还有：
-
拒绝申请时的：approveActive->reject
-
同意申请时的：approveActive->accept
此外，前文讲了审批权限的检查，所以在显示用户审批界面时，还会调用approveCheck->checkRight来检查用户可以点击哪些按钮。
子capa使用协作框架
为使用主capa所定义的协作框架，子capa只需要：
1、定义自己的专用web界面及其prepareDisp事件函数，就如同不知道会被嵌入主capa中
2、重载coOP函数来实现主capa所要求的cmd接口，如实现预算的taskBudget：
def coOP(self,db,ctx,coType,active):
if coType == 'approveActive':
if active == 'newApprove':
...处理创建一个预算申请
if active == 'accept':
...处理同意预算申请
if active == 'reject':
...处理拒绝预算申请
return jxJson.TRUE
3、向主capa进行注册，由于jxTMS的代码都是可随时修改并可动态的热机刷新，所以协作框架的注册应在本capa的initAtLoad函数中，以在每次修改代码并热机刷新后即刻生效。如实现预算的taskBudget：
#每次重新加载代码时执行
def initAtLoad(self,db,org):
#注册查看接口
org.registerCapaCoOP('task.approve','viewApprove','task.budget',
'viewBudget','预算'.decode('utf-8'))
#注册操作接口
org.registerCapaCoOP('task.approve','approveActive','task.budget',
'操作时用不到'.decode('utf-8'),'预算'.decode('utf-8'))
大家可以看到，预算申请只注册了viewApprove和approveActive两个接口类型，而没有注册approveCheck接口类型，所以大家就可以自己为预算申请注册自己的approveCheck->checkRight来进行自己的预算审批权限设置了。