docker版jxTMS使用指南：自动生成代码（二）

本文继续讲解4.0版jxTMS的自动生成代码功能，

整个系列的文章请查看：docker版jxTMS使用指南：4.0版升级内容

docker版本的使用，请参考：docker版jxTMS使用指南

大家先以普通用户ssh登录到jxTMS的docker容器中，看一下【~/codeDefine/demo2/test/，如果是root用户登录则是/var/chroot/home/demoOrg_2255/codeDefine/demo2/test/】目录，会发现只有一个codeSource文件。该文件就是自动代码生成的源文件。

然后使用manager用户登录到jxTMS的web界面，点击快捷栏中的【运维管理->自动生成代码文件】，然后在spaceName中填入demo2，在moduleName中填入test，然后点击按钮【生成】。

再看一下【~/codeDefine/demo2/test/】目录，会发现多了5个文件。

jxTMS会自动生成下述的5个文件：

• capa.py，所以一定要牢记：如果使用代码自动生成，则该模块的目录下一定不要再自己写capa.py！！就保持jxTMS自动生成的capa.py文件不动，自己的代码写到新的py文件，jxTMS在加载模块时会自动把所有的.py【op.py除外】合并为一个py代码文件

• xx.op.2，该管理对象的入口定义

• xx.sql.2，该管理对象的查询语句定义

• xx.web.2，该管理对象的web界面定义

• xx.py.2，该管理对象的处理逻辑。该文件中的所有代码，都是capa.py中capa类的对象函数。所以如果在这些文件中添加自己的代码，需要注意缩进四个空格

.2文件是每个管理对象都有，capa.py只有一个。

codeSource文件中可以同时编写多个管理对象的定义【各个管理对象的定义之间用英文分号进行分隔】。xx就是管理对象的英文名，加.2的后缀是担心老的文件经过了定制修改，然后自动生成功能将其覆盖掉了。

当然，最好是不在自动生成的代码文件中修改任何东东，而是再创建xx_2.web、xx_2.py的文件来写入自己的定制代码。入口和sql的代码量本身就比较少，也不太会变动，所以直接改就好。

注1：后四种文件必须去掉.2的后缀才会被加载

注2：op文件、sql文件、web文件会被直接加载；.py文件则会被拼入capa.py后再加载，所以.py文件中的函数都是capa.py中的capa类的对象函数，所以如果要在.py中增加自己的处理函数，必须注意保持缩进

capa.py文件

自动生成的capa.py文件主要就是勾勒一个模块的基本结构，包括New、module、name、listOP四个基本函数，并创建一个刚定义的功能类以完成该capa的注册。

而这个自动生成的capa.py文件除此之外最主要的功能，就是为自动生成的py代码文件提供代码合并的锚定点：

########auto Code Start########

########auto Code End########

jxTMS在加载一个模块目录中的所有py文件时，会将除capa.py、op.py之外的所有py文件内容都逐一插入到上述两行之间，合并为一个capa类之后再进行加载。

所以呢，再次强调，自动生成的capa.py文件就不要动了，甚至连打开看的必要都没有。修改xx.py.2文件中的代码并改名为xx.py即可。

xx.op.2文件

以.2为后缀的文件相当于临时文件，jxTMS不会加载，所以必须去掉.2的后缀才会被加载。

自动生成代码功能会为管理对象生成四个入口，但其中三个是可选的：

• 快捷栏中的添加入口，是必然会生成的【快捷栏中入口在热机刷新后需要重新登录才能看到】

• 快捷栏中的查询入口，如果指定了条件查询，才会生成的。但一般来说，没有查询入口的管理对象是无法管理的，除非是附属于其它管理对象的子对象

• 管理对象的查看界面中的工具条栏中的禁用入口，如果管理对象的数据类中定义了NoUsed属性，则会生成

• 如果生成了禁用入口，jxTMS会自动将其链接到该对象的查看界面

上面说过，jxTMS会自动生成四个界面：查看、添加、修改、查询。但现在最多只定义了查询和添加界面，查看和修改的入口在哪呢？！

jxTMS在生成查询界面时，会在结果列表中为每一条查询结果自动添加查看和修改入口。

需要注意的是，上述五个入口都没有指定角色，开发者需要自己手动为这些入口指定角色。

注：json.role(‘’.decode(‘utf-8’))只是用来占空的，相当于没有用role函数来指定角色，谁都可以访问

xx.sql.2文件

jxTMS只自动生成了一条sql语句用来配合查询界面使用。开发者一般都需要修改该语句以配合查询条件的设定。

但开发者不可以修改该查询语句的名字。

xx.web.2文件

自动生成代码功能最主要的目的就是简化web文件的编写。所以ROW语句和查看详情界面是严格的一对二关系，即ROW中定义的一个控件【称为：表意格】会被严格翻译为两个控件：文本提示控件、输入输出数据控件。其定义的控件属性会被直接照搬到所生成的相应控件的定义中。

因此，自动生成代码还是需要开发者熟悉web控件的定义，其只是用来提高效率、降低bug率的。

注1：将生成的.2文件取掉.2后缀后，做一次热机刷新，然后退出后重新登录，点击快捷栏【安全管理->添加测试】，会看到自动生成的【添加测试】界面，三行全部没有对齐:( 所以一般都还是需要手动调整一下的

注2：对齐最简单的办法是去掉表的【alone=true】属性设置，即强制要求表中各行按同名列做对齐。但就如【添加测试】界面中的【说明】一样，其本身就要占这么宽，如果和其它列挤在同一列更不舒服。所以这时比较好的办法是在每行的最后，添加一个空白格：

with 表名 row 某行 col cn web n type text text='',width=需要的宽度;

列名叫做cn就不会出现和行中其它列的冲突；text属性设个空值；然后计算本行其它各行的宽度后，用900的总宽减去后的值，就是cn的宽度。其实就是用一个看不见的占位符来调整行中各控件的宽度以实现对齐的效果。

xx.py.2文件

自动生成的该管理对象的代码主要包括：

• initAtLoad函数，主要将DATA中定义的语义词和数据类字段进行关联，以后开发者就不需要再去管数据存放到哪个数据表的哪个字段中了，输入输出都只需要和语义词打交道就可以了，这既大大降低了开发者的记忆量，也大大减少了bug率

• _disp函数，主要用来在显示界面、修改界面中显示管理对象的信息。需要注意的是，不需要使用self.setOutput函数，而是使用self.dispVarFromField，就不需要记忆相应的语义词所对应的数据类的属性了

• _update函数，主要用来在添加界面、修改界面时保存管理对象的信息。同样，使用self.setFieldFromVar函数来简化对数据类属性的记忆

• 然后是四个事件响应函数，分别是查看界面、修改界面的prepareDisp事件的响应函数，主要是调用_disp函数；添加、修改两功能的cmd事件的响应函数，主要是调用_update函数；

• searchCondition函数，主要是查询时的条件设置。开发者在SEARCH字句中，定义了几个查询条件，jxTMS就会为每个查询条件创建相应的三行代码来检查是否输入了响应的查询条件，如果输入了则将其添加到查询语句中

需要注意的是，上述的initAtLoad和searchCondition都和之前的版本有所不同：老版本中的这两个函数都是继承自affairMgr的子函数；而今后都会是被修饰符所修饰的独立函数。

这主要是自动生成代码功能需要将各个py文件拼接为一个py代码文件后再进行整体加载，子函数形式无法适应多个py文件都有自己的initAtLoad和searchCondition的情况。

同样的，新版本的jxTMS还调整了其它两个子函数来适应多py文件拼接的需要：

• searchConditionVar，设置查询时的变量值

• dispAffairInfo，查询结果不是json而是jo时，用来调整输出内容

注：自动生成的py文件中的代码，本质上是要作为capa.py的一部分合并后插入的，而这些py文件中的代码都应该是capy.py文件中所定义的capa类的子函数。所以这些py文件都是自动缩进了4个空格以确保其会作为capa类的子函数

代码定位

在jxTMS设计思想中讲解过：出于安全的考虑，jxTMS在加载用户的定制代码时，会将capa.py文件中的import语句全部删除，然后拼入预置的导入语句。

这些导入语句，共计50行，所以在排错时，需要将系统提示的错误行数减去50才是capa.py文件中的行数。

但现在问题就大了：开发者看到的是分散在各个py文件中的代码，而系统加载的是将分散在多个py文件中的代码合并后的整体代码。报错的行号是这个整体代码加50后的行号，而不是开发者所需要的哪个py的哪行！

为了初步解决此问题，新版本的jxTMS在【自动生成代码】功能之外，还提供了自动计算代码文件行号【快捷栏：运维管理->自动计算代码文件行号】功能，该功能将指定模块目录中除op.py之外的所有py文件按加载顺序计算行数，然后在各文件开头添加了行号关系：

#本文件中的行号加123为实际行号

即当系统报错时，将系统提示的错误所在行号，减去123就是本文件中的行号。

此外，自动计算代码文件行号功能还会将所有py代码文件中的代码合并到【capa_complte】文件，该文件和实际运行的代码只相差了固定的那50个import行。而且在合并后的代码中还会给出下面的代码来自哪个py文件，这就加快了故障定位的速度：只需将实际故障位置减去50就是capa_complte文件中的故障位置，然后根据capa_complte文件中所提示的位于哪个文件中就可以快速的定位故障了。

参考资料：

jxTMS设计思想

jxTMS编程手册

下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能：

如何用jxTMS开发一个功能

下面的系列文章讲述了jxTMS的一些基本开发能力：

jxTMS的HelloWorld