EMP2.2变化及影响

1. 组件工厂与核心模块

1.1. IOC规则支持子标签innerText方式属性注入

? 涉及范围

com.ecc.emp.component.xml.GeneralComponentParser com.ecc.emp.component.xml.ServiceParser

? 更改原因

【新功能】对于某些内容很长的属性，如果采用attrName=”attrValue”的方式写在XML标签中，会使得标签变得很难阅读，对于一些公式或SQL语句还需使用转义符。因此修改了GeneralComponentParser以实现子标签下挂文本节点或CDATA节点方式注入属性的功能。ServiceParser的修改主要是针对在找不到标签对应生成类时会主动抛错而不是返回null供上层调用者处理，导致子标签innerText定义方式不会被识别的问题。 ? 配置示例

若要使用子标签innerText方式注入属性，需要在组件的XML标签下挂一个标签名为属性名的子标签，然后子标签下为属性取值的文本内容。可以使用CDATA区块来定义含有引号、小于号等平时需要转义的字符的文本。以下是配置示例： 该定义会将CDATA中的SQL语句模板注入到DynamicSQLDefine组件的SQLStr属性当中。 ? 注意

1. 属性名子标签不能被识别到任何生成类，即标签本身、classMap、settings.xml以及

Parser中都不能定义该属性名对应的生成类。

2. 该方法只适用于set方法的参数为String型的属性。

3. 如果组件的标签上已经以attrName=”attrValue”的方式定义了某属性，则以子标签

innerText方式定义的同名属性不起作用。

1.2. 允许在开发时对业务逻辑构件的修改即时生效而不重启

应用

? 涉及范围

com.ecc.emp.component.factory.EMPFlowComponentFactory

? 更改原因

【新功能】在实际项目中，业务逻辑构件是开发的重点，而EMP为了保证性能，对业务逻辑构件的定义进行了缓存，这样在开发时对业务逻辑构件进行的修改必须要重启应用才能够生效，会对开发效率造成一定影响。因此在业务逻辑组件工厂上增加了isBizCached属性（默认为true），如果设定其值为false，则每次调用业务逻辑构件时都会重新读取配置文件，使配置文件的修改可以及时反映到运行状态。 ? 功能详细介绍与配置示例

若要打开该功能，在settings.xml中设置parameters.bizCache=false即可。如下： ………… ? 注意 该功能仅限开发时测试使用，在生产环境下应设置parameters.bizCache=true。

1.3. 公共Format的引用方式更改为与Service一致

? 涉及范围

com.ecc.emp.component.xml.ContextParser

com.ecc.emp.core.Context

? 更改原因

【设计变更】EMP原有的公共Format定义无法直接绑定在RootContext下，而需要在具体业务逻辑构件中进行引用，这样要求所有用到公共Format的业务逻辑构件中都引用同样的Format定义。对于广泛使用的报文头之类定义来说这种定义方式既麻烦又存在大量冗余。因此将公共Format的引用方式修改为和Service一致，即只要在RootContext的定义中使用refFormat引用了公共报文，即可通过业务逻辑Context向上寻找到。 ? 配置示例

在contexts.xml中的RootContext定义中使用refFormat标签进行引用：

1.4. 更改EMPBusinessLogicCaller的业务逻辑注入方式

? 涉及范围

com.ecc.emp.component.xml.FlowParser com.ecc.emp.processor.EMPBusinessLogicCaller

? 更改原因

【设计变更】原有EMPBusinessLogicCaller所调用的业务逻辑实例是由FlowParser硬编码的方式注入进去的，现改为由EMPBusinessLogicCaller自行获取，以减少代码中的耦合度和“潜规则”。 ? 配置示例

只是内部实现的更改，对配置文件不会造成影响。

1.5. Http/PortletSessionManager(待补充 广林) 1.6. AccessController(待补充 辑洲) 1.7. DataType数据类型的设计更改

? 涉及范围

com.ecc.emp.datatype包

? 更改原因

【设计变更】原有的数据类型定义方式中，前端的JS代码是放在dataType.xml中，然后通过emp标签将JS代码添加到页面中，这种方式对于JS的编辑以及调试不够友好。修改后将JS代码单独放在JS文件中，当页面需要用到数据类型时，可以在页面中加载该JS文件。同时对于数值的数据类型，使用标准的NumberFormat进行校验和转换，并将dataType作为一种基本的操作元素看待，将其中的属性进行优化，尽量减少需要配置的属性。另外，添加了几种数据类型：DateTimeDataType：对原有的DateTimeType进行修改并舍弃原来的代码；DecimalType：高精度数据类型，包含原有的CurrencyType内容并舍弃原来的代码；IdentityType：身份证号码类型；PatternType：正则表达式类型；PercentType：百分数/千分数类型 ? 配置示例

dataType.xml 整型类型数据 如上，在定义validateJS和convertorJS时不再定义这两个JS的实现内容，只需要定义一

下校验和转换的JS方法名称即可。 ? 注意

为了保证兼容，在原有的应用EMP2.1的项目中，不能更新dataType.xml、dataTypeDefine.xml以及emp.tld文件。对于新的EMP2.1或EMP2.2项目，则可以采用新的配置方式

2. 业务逻辑框架与相关组件

2.1. 数据源以及数据库操作组件的定义方式更改

? 涉及范围

com.ecc.emp.jdbc包

? 更改原因

【设计变更】原有数据库操作组件，在调用一个Action的时候，都要指明其所使用的3个服务：数据源服务、访问服务、定义服务。而对同一个数据源来说，访问服务通常都是统一的，在每个Action中都进行配置会比较麻烦。因此设计了新的定义方式，即将三种访问服务（表操作、SQL执行、存储过程执行）定义为数据源服务的子节点，这样在Action上就不用再定义访问服务，而是直接通过数据源进行获取，减少配置的复杂度。 ? 配置示例 如上，在DataSource下有一个resources节点（实际是一个HashMap），下面可以定义表操作、SQL执行、存储过程执行三种数据库访问服务，其id分别如上所示。这样在Action上只需要指明DataSource，组件就可以自动寻找到所对应的访问服务。 ? 注意

为了向下兼容，也支持以前的定义方式。

2.2. 表操作分页功能的bug修改

? 涉及范围